The EU Cyber Resilience Act: What It Requires of a Manufacturer Outside the EU

The Cyber Resilience Act is in force, and its reporting duty already applies

The Cyber Resilience Act is not a future law. It entered into force on 10 December 2024, and one of its central obligations has applied since 11 September 2026. The Act is Regulation (EU) 2024/2847, and as an EU regulation it applies directly in every Member State without national implementing legislation. Under Article 71(2) it applies in full from 11 December 2027, the rules on notified bodies from 11 June 2026, and Article 14 from 11 September 2026.

Article 14 is the duty to report actively exploited vulnerabilities and severe security incidents, and it reaches products already sold. Article 69(2) leaves products placed on the market before 11 December 2027 outside the Act unless they are later substantially modified, but Article 69(3) carves out reporting:

So a device or app already in the hands of European users today is inside the reporting regime now. In the European Commission's view, published with its guidance on the Act in July 2026, that duty also continues after a product's support period has ended, while the vulnerability handling obligations stop at that point.

Which products are caught: hardware, software, apps, and where SaaS stops

The Act covers any hardware or software product, and the remote data processing it depends on, whose intended or reasonably foreseeable use includes a data connection to a device or network. That is the test in Article 2(1), read with the definition of a "product with digital elements" in Article 3(1). It reaches connected devices, routers, desktop programs, mobile apps and components sold for integration, which makes it the central product regime in IP and technology law for business selling into Europe.

The Act applies only to products made available "in the course of a commercial activity". Article 3(13) treats a person as a manufacturer whether it markets the product "for payment, monetisation or free of charge". Recital 15 gives charging for support beyond cost, monetising through a platform, and requiring personal data as a condition of use for reasons other than security, compatibility or interoperability as examples of commercial activity.

Pure software as a service is outside the Act as a product. The Commission's guidance draws the line at where the code runs: "software that executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements", unless it is remote data processing a product needs to work. The guidance is not binding, but it is where market surveillance authorities will start.

• In scope: an installed app or desktop client, device firmware, and the cloud back end a smart device needs to work.
• Outside, as a product: a web application used only in a browser, and a website that does not support a product's functions. SaaS providers may instead be caught by the NIS2 Directive, discussed below.
• Excluded by the Act itself: medical devices and in vitro diagnostics, type-approved motor vehicles, certified aviation products, marine equipment, identical spare parts, and products made exclusively for national security or defence.

For standalone software, the Commission treats a version as placed on the market when it is first offered in the EU, with a later release counting as a new placing only if it is a substantial modification.

Manufacturer, importer or distributor: the role decides the obligations

An Australian company that sells its own branded device or software into the EU is the "manufacturer" under the Act, and nothing in the definition requires it to be established in Europe. Article 3(13) defines a manufacturer as a person who develops or manufactures products with digital elements, or has them made, and markets them under its own name or trademark. Almost every substantive obligation in the Act sits with that person.

An importer is a person established in the Union who places on the market a product bearing the name or trademark of someone outside it; a distributor is anyone else in the chain. Both must check the CE marking and documentation, pass vulnerabilities to the manufacturer and report significant risks to the authorities. The importer must also put its own contact details on the product, or where that is not possible on its packaging or an accompanying document.

The trap for a European partner is Article 21:

A white-label arrangement therefore moves the manufacturer burden onto the European reseller, which will look to the Australian supplier for the documentation and vulnerability handling it cannot produce itself. That allocation belongs in the distribution agreement, before the first shipment.

The Act does not itself require a manufacturer outside the EU to appoint a European representative. Article 18 makes an authorised representative optional, and the core design and vulnerability obligations cannot be delegated to one. Three things usually push the answer towards appointing one all the same.

• Most connected hardware is radio or electrical equipment, and Article 4 of the Market Surveillance Regulation, Regulation (EU) 2019/1020, already requires an economic operator established in the Union for those products. Whether the General Product Safety Regulation also requires one depends on the product.
• The authorised representative's location decides which national authority receives the manufacturer's vulnerability reports, as explained below.
• Under the new Product Liability Directive, the authorised representative of a non-EU manufacturer is itself liable for defective products.

What the essential requirements demand of the product

A product may be sold in the EU only if it meets the cybersecurity requirements in Part I of Annex I and the manufacturer's processes meet the vulnerability handling requirements in Part II. Article 6 states that rule, and Article 13 requires the manufacturer to carry out a documented cybersecurity risk assessment, including of the third-party and open-source components it uses, and apply it from planning through to maintenance. Where a requirement does not apply to the product, the technical documentation must say why.

Part I is drafted as outcomes rather than technologies. On the basis of the risk assessment, and where applicable, a product must:

• be released without known exploitable vulnerabilities;
• have a secure by default configuration, with a way to reset it;
• be capable of receiving security updates, with automatic updates enabled by default, a clear opt-out and the option to postpone them;
• protect against unauthorised access through authentication and access control;
• protect the confidentiality and integrity of data, for example by encryption, and process only the data needed for its intended purpose;
• protect its essential functions, including against denial of service, and limit its impact on other networks;
• limit attack surfaces, use exploit mitigation, and log security-relevant activity with a user opt-out; and
• let users remove all data and settings securely and permanently.

For a tailor-made product, a business customer may agree to depart from the secure default configuration and from free-of-charge security updates. Compliance is assessed on the product being properly installed, maintained and used, with the necessary updates installed.

Support periods, security updates and the software bill of materials

The manufacturer must handle vulnerabilities for a declared support period that reflects how long the product is expected to be used, and that period has a statutory floor. Article 13(8) provides:

Five years is a minimum, not a default: in the Commission's view a product expected to be used for longer needs a longer period. Each substantially modified version of software needs its own declared support period.

The support period then drives several concrete duties. The end date, at least the month and year, must be stated clearly at the time of purchase. Each security update issued must stay available for at least ten years or the rest of the support period, whichever is longer.

The technical documentation and the EU declaration of conformity must be kept for ten years or the support period, whichever is longer. And the duty to correct, withdraw or recall a non-conforming product runs from placing on the market and for the support period.

The software bill of materials must exist, but it does not have to be published. Part II of Annex I requires the manufacturer to identify and document components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. Recital 77 is explicit:

A market surveillance authority can ask for it; sharing it with customers is a commercial choice.

Product classes and conformity assessment: self-assessment or a notified body

Most products can be assessed by the manufacturer itself, but the Act lists categories that need a third party, and for one of them the self-assessment route is not yet available in practice. That third party is a notified body. A notified body is an independent conformity assessment organisation designated by a Member State for this purpose.

Classification turns on a product's core functionality. Annex III lists "important" products in two classes and Annex IV lists "critical" products. The technical description of every category is set out in Implementing Regulation (EU) 2025/2392, which has been in force since 21 December 2025.

Integrating a component that is itself a listed product does not by itself make the host product an important product. A news app with an embedded browser does not become a "browser", although the app as a whole must still meet the essential requirements.

The difficulty for class I is timing. Self-assessment is open only where the manufacturer applies harmonised standards, common specifications or a European certification scheme in full. The Commission issued its standardisation request for the standards in 2025.

As at 9 November 2026 we could find no harmonised standard under the Act whose reference had been published in the Official Journal, no common specification adopted and no European certification scheme designated for the Act's purposes. While that remains the position, a class I product must go through a notified body. Manufacturers launching class I products in 2027 should plan for that cost and lead time now, and check the position again before launch.

The declaration of conformity and CE marking, including for software

Once conformity has been demonstrated, the manufacturer draws up an EU declaration of conformity, takes responsibility for compliance by doing so, and affixes the CE marking before the product is placed on the market. A product covered by several EU laws carries a single declaration. A copy, or a simplified declaration giving the web address of the full one, must accompany the product.

Software has no surface to stamp, and Article 30(1) deals with that directly:

The technical documentation behind the declaration is listed in Annex VII, and the product must carry the manufacturer's contact details and a single point of contact for vulnerability reports that does not rely only on automated tools.

Reporting exploited vulnerabilities and severe incidents through ENISA

A manufacturer that becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting the product's security, must notify it within 24 hours, through the single reporting platform run by ENISA, the EU cybersecurity agency, to ENISA and to the national response team that Article 14(7) designates. For an actively exploited vulnerability, the first step is:

A fuller notification follows within 72 hours, and a final report no later than 14 days after a fix or mitigation is available. For a severe incident, the 24-hour and 72-hour steps are the same, and the final report is due within one month of the 72-hour notification.

An incident is severe if it affects, or could affect, the product's ability to protect sensitive or important data or functions, or could lead to malicious code running in the product or the user's systems. The manufacturer must also inform affected users and tell them how to mitigate the risk.

The clock runs from awareness, which the Commission reads as reasonable certainty after a prompt initial assessment. A vulnerability in a third-party component that is not exploited in the manufacturer's own product is not a mandatory report, though it must still be passed upstream. Exploitation known before 11 September 2026 need not be reported.

The single reporting platform went live on 11 September 2026. Article 14(7) decides which national team receives each report. It is the team of the Member State where the manufacturer's decisions on product cybersecurity are predominantly taken, or failing that where it has the most employees in the EU.

A manufacturer with no EU establishment follows a set order: the Member State of the authorised representative acting for most of its products, then of the importer placing most of them, then of the distributor making most of them available, and finally where most of its users are. A German-parented group whose European entity takes the security decisions reports to that country's team and never reaches the list. Notification does not of itself increase the notifier's liability.

Connected radio equipment: the rules that already apply

For connected hardware with a radio, cybersecurity requirements have applied under the Radio Equipment Directive since 1 August 2025, well before the Cyber Resilience Act takes over. Delegated Regulation (EU) 2022/30 switched on three essential requirements of that Directive: protection of the network, protection of personal data and privacy, and protection against fraud.

The network requirement applies to any radio equipment that can communicate over the internet. The privacy requirement applies to internet-connected equipment, and to childcare, toy and wearable radio equipment whether or not it connects to the internet, where the equipment processes personal, traffic or location data. The fraud requirement applies to internet-connected equipment that lets the user transfer money, monetary value or virtual currency.

Those requirements have their own harmonised standards, the EN 18031 series, cited in the Official Journal with restrictions. They are standards under the radio rules, not under the Cyber Resilience Act, and they give no presumption of conformity under the Act.

The two regimes do not run in parallel for long. The Commission has repealed the radio equipment rules from the day the Act applies in full:

Radio equipment placed on the market between 1 August 2025 and 10 December 2027 remains answerable to the radio rules for that period. For a connected device sold in Europe today, 2027 is not the first deadline.

Penalties and enforcement

Breach of the essential requirements, or of the manufacturer's obligations in Articles 13 and 14, can attract an administrative fine of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Article 64 sets three tiers. Breaches of the obligations of authorised representatives, importers and distributors, and of the rules on the declaration, CE marking, technical documentation and conformity assessment, carry up to EUR 10 million or 2%.

Supplying incorrect, incomplete or misleading information to authorities or notified bodies carries up to EUR 5 million or 1%.

Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning deadlines. A corrigendum of 2 July 2025 made sure the exemption reaches the tier in which the reporting fines sit. Open-source software stewards, bodies that support free software intended for commercial use without being its manufacturer, are not subject to fines at all; a company that monetises its open-source product is a manufacturer.

Fines are imposed nationally, and Member States set the rules within those ceilings. They can be imposed alongside corrective measures up to withdrawal or recall. From 11 December 2027, breaches that harm the collective interests of consumers can also be pursued by representative action.

Product liability, NIS2 and the AI Act

The Cyber Resilience Act sets the security standard; the new Product Liability Directive decides who pays when a product falls short of it. Directive (EU) 2024/2853 expressly includes software in the definition of a product, and applies, as corrected in May 2026, to products placed on the market or put into service after 8 December 2026. In deciding whether a product is defective, a court must take into account:

The usual defence that a defect arose after the product left the manufacturer's hands is unavailable where the defect is due to software, to a related service, or to a lack of software updates needed to maintain safety, so long as these are within the manufacturer's control. A third party exploiting a vulnerability does not reduce the manufacturer's liability.

Where the manufacturer is outside the EU, its importer, its authorised representative and, failing both, its fulfilment service provider are liable as well.

The NIS2 Directive regulates organisations rather than products, and it reaches an Australian business in two ways. First, Article 26(3) of Directive (EU) 2022/2555 requires certain digital service providers not established in the Union but offering services there, including cloud computing, managed service and managed security service providers, to designate a representative in the Union. A SaaS business outside the Cyber Resilience Act may be inside NIS2.

Secondly, and more often, it reaches the supply chain. Essential and important entities must manage supply chain security, including their relationships with direct suppliers. An Australian manufacturer with no EU establishment is not itself an NIS2 entity, but its European subsidiary may be, and its European customers will push security commitments down the contract. Personal data processed by a connected product engages the GDPR separately, which our article on when European privacy law reaches an Australian business covers.

For high-risk AI, compliance with the Cyber Resilience Act counts towards the AI Act. A high-risk AI system that is also a product with digital elements is deemed to meet the cybersecurity requirements of Article 15 of the AI Act where it meets both parts of Annex I and the EU declaration of conformity demonstrates the required level of protection. The AI Act's high-risk obligations now apply from 2 December 2027 and 2 August 2028, after the Digital Omnibus on AI moved them.

What to do now

The reporting duty already applies, and the remaining obligations need product decisions that take longer to make than the time left before 11 December 2027. The sequence below suits most technology and software businesses selling into the EU from outside it:

The broader picture of selling digital products into the EU, including consumer, platform and data rules, is in our overview of which EU laws reach a digital product sold from outside the EU, and when.

Where this article stops

This article states the law as it stood on 9 November 2026. So far as we could establish at that date, no harmonised standard had been cited, no certification scheme designated, no implementing act adopted on the format of the software bill of materials or of notifications, and the Commission's guidance had not been formally adopted in all languages.

It does not deal with sector-specific regimes that displace or add to the Act, such as those for medical devices, vehicles and aviation, with national penalty rules, or with Australian law, which governs much of the contracting with European partners and applies alongside it.