The Cyber Resilience Act (Regulation (EU) 2024/2847) turns cybersecurity into a precondition for selling connected products in the EU. For the first time, a product with digital elements cannot carry the CE marking, and therefore cannot be placed on the EU market, unless it meets binding cybersecurity requirements across its whole lifecycle.
What the CRA is, and why it changes the game
The CRA entered into force on 10 December 2024 and applies horizontally to almost any "product with digital elements": software and hardware whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That sweeps in operating systems, applications, network equipment, industrial control systems, smart home devices, connected toys, wearables, and the many components embedded inside them.
A few carve-outs exist for products already covered by sector-specific EU cybersecurity rules, including certain medical devices, motor vehicles, and civil aviation and marine equipment. Software-as-a-service is generally outside scope, except where a remote data-processing solution is integral to a product's function. For most manufacturers of connected products, though, the default assumption should be that the CRA applies.
The obligation lands primarily on the manufacturer: whoever develops or manufactures a product, or has it designed, developed, or manufactured, and markets it under their own name or trademark. Importers and distributors carry their own downstream duties, but the substantive engineering and documentation burden sits with the manufacturer.
What the CRA requires
The regulation is built around a small number of demanding ideas. The essential requirements live in Annex I and split into two parts: how the product must be secured, and how the manufacturer must handle vulnerabilities over time.
Essential cybersecurity requirements. Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks. In practice that means shipping with a secure default configuration, protecting confidentiality and integrity of data, minimising attack surfaces, and being made available without known exploitable vulnerabilities. Security by design and security by default stop being aspirations and become legal obligations that a market surveillance authority can test against.
Vulnerability handling across the lifecycle. The CRA's second pillar is ongoing. Manufacturers must identify and document vulnerabilities, address and remediate them without delay, and provide security updates for the duration of a defined support period. That support period must reflect how long the product is reasonably expected to be in use, and in most cases is expected to be at least five years. Free security updates, coordinated vulnerability disclosure policies, and a documented process for handling reports are all part of the baseline.
Software Bill of Materials (SBOM). Manufacturers must draw up a software bill of materials, in a commonly used and machine-readable format, covering at least the top-level dependencies of the product. The SBOM is part of the technical documentation that has to be maintained and kept current. It underpins vulnerability handling: you cannot patch what you cannot see, and regulators increasingly expect manufacturers to know exactly what components ship inside their products.
Reporting obligations. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. Notifications go to the manufacturer's designated national CSIRT and to ENISA through a single reporting platform, on a tight schedule: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report once the matter is resolved. These reporting duties are the first substantive obligations to bite, well ahead of the rest of the regime.
Product classes and the conformity route
Not every product carries the same risk, so the CRA sorts products into tiers that determine how rigorously conformity has to be demonstrated. The class decides whether a manufacturer can self-assess or must involve an independent notified body.
| Product tier | Examples | Conformity route |
|---|---|---|
| Default | Most connected products: photo editors, smart speakers, games, general-purpose apps | Self-assessment (internal control) |
| Important, class I | Password managers, VPNs, network management tools, physical and virtual network interfaces, boot managers | Self-assessment if harmonised standards are fully applied, otherwise a third-party route |
| Important, class II | Operating systems, hypervisors, firewalls, tamper-resistant microprocessors and microcontrollers, industrial firewalls | Mandatory third-party assessment by a notified body |
| Critical | Hardware devices with security boxes, smart meter gateways, smartcards and secure elements | Third-party assessment, potentially via a mandatory European cybersecurity certification scheme |
The default category covers the majority of products, and here a manufacturer may self-assess using an internal control procedure. Moving up the tiers raises the bar: for important products, applying the relevant harmonised standards (once published) lets class I manufacturers keep self-assessing, but class II always requires a notified body. Critical products sit at the top, where the Commission can require certification under a dedicated European scheme.
Two practical points follow. First, classification is a design-time decision with real cost consequences, so it should be settled early rather than discovered late. Second, the availability of harmonised standards matters enormously: much of the self-assessment path for important products depends on standards that are still being developed, and manufacturers should track that work rather than assume it is finished.
Conformity assessment and CE marking
Whichever route applies, the destination is the same. The manufacturer performs (or commissions) a conformity assessment against the essential requirements, compiles technical documentation that includes the SBOM and evidence of the vulnerability-handling process, draws up an EU declaration of conformity, and then affixes the CE marking. The CE marking on a product with digital elements now asserts cybersecurity conformity alongside the safety and other attributes it already signalled.
This is the structural shift worth internalising. Cybersecurity moves from a voluntary differentiator into the same New Legislative Framework machinery that governs product safety across the single market. A missing or unjustified CE marking is not a documentation footnote; it is a barrier to placing the product on the EU market, and it exposes the manufacturer to market surveillance action, including orders to withdraw or recall non-compliant products and administrative fines.
The phased timeline
The CRA does not switch on all at once. It arrives in stages, and the earliest deadlines are closer than the headline "full application" date suggests.
| Date | What applies |
|---|---|
| 10 December 2024 | Regulation enters into force |
| 11 June 2026 | Rules on notified bodies (conformity assessment infrastructure) begin to apply |
| 11 September 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents apply (Article 14) |
| 11 December 2027 | Full application: essential requirements, conformity assessment, CE marking, and technical documentation |
The sequencing is deliberate. From 11 June 2026, the provisions governing notified bodies take effect, so the conformity-assessment infrastructure exists before manufacturers need it. From 11 September 2026, the reporting duties under Article 14 apply, meaning that well before the product requirements are fully enforceable, manufacturers must already be able to detect and report actively exploited vulnerabilities and severe incidents within the 24-hour and 72-hour windows. Then, from 11 December 2027, the CRA applies in full: from that date, products with digital elements placed on the market must meet the essential requirements and carry a CE marking backed by a valid conformity assessment.
Read plainly, the incident-reporting machinery is a 2026 problem, and the product-conformity machinery is a 2027 problem. Manufacturers who plan only against the 2027 date risk being caught unprepared by the reporting obligations more than a year earlier.
A manufacturer's action plan
CRA compliance is an engineering and governance programme, not a single certification event. A pragmatic sequence looks like this:
- Build a product inventory and classify each one. List every product with digital elements you place on the EU market and assign each to a tier (default, important class I or II, or critical). Classification drives everything downstream, including whether you need a notified body.
- Stand up a vulnerability-handling process now. Establish coordinated disclosure, a way to receive and triage reports, and a patch pipeline that can ship free security updates across the declared support period. This is also what the September 2026 reporting duties depend on.
- Generate and maintain an SBOM. Adopt a machine-readable format and wire SBOM generation into your build so it stays current rather than becoming a stale artefact. Use it to drive dependency monitoring and faster patching.
- Define support periods per product. Decide, document, and communicate how long each product will receive security updates, reflecting realistic expected use.
- Assemble technical documentation and pick a conformity route. Map each product's evidence against Annex I, and for important class II and critical products, engage a notified body early given expected demand.
- Wire up incident and vulnerability reporting. Ensure you can meet the 24-hour early warning and 72-hour notification deadlines to your national CSIRT and ENISA before 11 September 2026.
- Track harmonised standards and delegated acts. The self-assessment path for important products, and the precise scope of classes, will be shaped by standards and Commission acts that are still emerging. Treat this as continuous monitoring, not a one-off read.