The Cyber Resilience Act is the European Union's first law to put binding cybersecurity requirements on the products people and businesses buy, rather than on the organisations that run networks. It covers hardware and software placed on the EU market, from industrial sensors and smart appliances to mobile apps and operating systems. Most of its obligations apply from 11 December 2027, but the first one is already in force: since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities and severe incidents on a clock measured in hours. This guide sets out what the CRA covers, what it asks for, and the dates that matter.
Who and what the CRA covers
The CRA applies to "products with digital elements": any hardware or software product, and the remote data processing solutions built for it, placed on the EU market. The decisive test is the data connection, not the form factor. If a product's intended or reasonably foreseeable use includes a direct or indirect connection to another device or network, it is very likely in scope. A sensor that only talks to a local gateway still counts if that gateway reaches the internet.
The obligations fall on economic operators. Manufacturers carry the heaviest load, with lighter duties for importers and distributors. The reach is extraterritorial: a company outside the EU that sells a connected product into the EU market is bound by the same rules as one inside it.
Some products sit outside the CRA because other law already governs them, including medical devices, civil aviation equipment and motor vehicles. Free and open-source software has a lighter, separate regime for "stewards", though a company that puts open-source software on the market in the course of a commercial activity can still be treated as a manufacturer with the full set of obligations.
Pure software-as-a-service is generally outside the CRA and covered instead by the NIS2 Directive. A cloud service is pulled in only when it is a "remote data processing solution": the manufacturer is responsible for it, and the product cannot perform one of its functions without it. The companion backend a smart device needs to work is in scope; a standalone web application you simply sign into is not.
How the CRA sorts products by risk
Not every product faces the same conformity route. The CRA places products into tiers by risk.
Default products, the large majority, can self-assess and affix the CE marking on that basis. Important products, listed in Annex III as Class I or Class II, face stricter routes: Class I can rely on harmonised standards to self-assess, while Class II generally requires a notified body to be involved. Critical products, listed in Annex IV, require mandatory third-party certification.
Classification follows the product's core function, and where more than one category could fit, the stricter one applies. The CE marking is the visible outcome: once the CRA is fully applicable, a product with digital elements cannot be placed on the EU market without it.
What the CRA requires manufacturers to do
The substantive requirements sit in Annex I of Regulation (EU) 2024/2847, and they split into two halves.
The first half is about the product itself. It must be designed, developed and produced to be secure, delivered with a secure default configuration, and free of known exploitable vulnerabilities at the point of release. It must protect the confidentiality and integrity of the data it handles, minimise its own attack surface, and allow security updates, ideally automatic ones where appropriate.
The second half is about handling vulnerabilities across the product's life. Manufacturers must identify and document the components a product contains, including by producing a software bill of materials (SBOM) in a commonly used, machine-readable format. They must address and remediate vulnerabilities without delay, provide free security updates across a support period that reflects how long the product is reasonably expected to be in use, and run a coordinated vulnerability disclosure policy so that researchers have a clear way to report problems.
On top of this sits the evidence that proves it: technical documentation, an EU declaration of conformity, and the conformity assessment appropriate to the product's risk tier.
The reporting obligation that is already live
Article 14 is the part of the CRA that already bites. Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting the product's security, must report it on a fixed clock: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available for a vulnerability, or within one month of the 72-hour notification for a severe incident.
"Actively exploited" has a precise meaning here: there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission. Finding a bug in an audit, or scoring it as high severity, does not by itself meet that bar. The two initial clocks both start from the moment the manufacturer becomes aware, and they run in parallel; the 72 hours do not begin once the first 24 have elapsed.
Reporting goes through a single channel. ENISA's Single Reporting Platform, which opened on 11 September 2026, takes one submission and routes it to the national CSIRT designated as coordinator, determined by where the manufacturer has its main establishment, and to ENISA. One point catches teams out: the duty covers products already on the market, not only those shipped after full application in 2027. Waiting for the next release does not remove it.
The CRA timeline: what applies, and when
The CRA entered into force on 10 December 2024 and applies in stages. On 11 June 2026, the rules on notifying conformity assessment bodies began to apply. On 11 September 2026, the Article 14 reporting obligations began to apply and ENISA's Single Reporting Platform opened. On 11 December 2027, the main body of obligations, the essential requirements, conformity assessment and CE marking, becomes fully applicable.
The Commission published practical guidance on 27 July 2026 to help manufacturers and developers prepare, and further implementing and delegated acts are filling in the detail. The staging is deliberate: it front-loads the duty to tell authorities when a product is being exploited, well before the wider design and documentation rules take hold.
How the CRA fits with NIS2, DORA and GDPR
The CRA does not replace the other EU cybersecurity rules. It sits alongside them and covers a different layer. The CRA regulates products: the security of the hardware and software a company makes and sells. NIS2 regulates organisations: the cybersecurity and incident-reporting duties of "essential" and "important" entities in defined sectors. DORA regulates the financial sector: the operational resilience of financial entities and their critical ICT providers. The GDPR regulates personal data.
A single event can trigger more than one of these regimes at once, which is why coordinating incident response across them matters. There is also a link to the AI Act: where a product is a high-risk AI system, the cybersecurity and vulnerability-handling work done for Annex I of the CRA can help demonstrate compliance with the AI Act's own security requirements. A company that already runs ISO 27001 and ENS as a single programme or meets NIS2 has much of the governance, risk and vulnerability-handling machinery the CRA assumes, and can reuse it rather than build it twice. For a sister EU regulation with a similar structure, see DORA: the five pillars, explained.
What happens if you don't comply
The CRA carries real penalties. Breaching the essential cybersecurity requirements or the core manufacturer obligations can attract fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other breaches carry lower ceilings. Member states set the detailed enforcement arrangements through their market-surveillance authorities, which can order a non-compliant product to be brought into conformity, withdrawn or recalled.
The commercial consequence can bite before any fine does. Once the CRA is fully applicable, no CE marking means the product cannot be placed on the EU market at all. For a company that sells into Europe, conformity is not a compliance nicety; it is the condition of market access.
How to get ready
The work divides into a short list, and the reporting clock makes some of it urgent. Inventory the products with digital elements you place on the EU market, and confirm your role for each: manufacturer, importer or distributor. Classify them as default, important or critical, since that decides the conformity route. Build and maintain an SBOM, so you know what is inside each product and can act quickly when a component turns out to be vulnerable. Stand up a vulnerability-handling process and a coordinated disclosure policy, with clear internal ownership of the decision to report.
Make sure you can actually detect and report inside the 24-hour and 72-hour windows: you cannot report what you cannot see, and the platform submission needs an EU Login account with multi-factor authentication set up in advance. Finally, reuse what you have. If an existing security programme already gives you what a licence alone misses, map it across rather than starting again, and make sure you have real visibility of what you are exposing online.
