The Cyber Resilience Act in 60 seconds
Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA) — entered into force on 10 December 2024. If you manufacture, import, or distribute hardware or software products with digital elements for the EU market, it applies to you. Full compliance is required by 11 December 2027, but partial provisions kick in earlier: market surveillance rules from September 2025, vulnerability reporting obligations from December 2026.
The CRA is the most significant product security regulation the EU has ever passed. It creates mandatory baseline cybersecurity requirements for an enormous range of products: IoT devices, consumer electronics, routers, smart home products, operating systems, antivirus software, password managers, industrial control systems, network management tools, and much more.
This article covers what you need to do, who is affected, and how to prioritise the work.
Who does the CRA apply to?
The CRA applies to any manufacturer (legal entity that places a product with digital elements on the EU market under its own name or trademark, or has a product designed or manufactured and markets it under its own name), importer (a legal entity established in the EU that places a product from a non-EU manufacturer on the EU market), or distributor that makes a product with digital elements available on the EU market.
A product with digital elements is defined broadly as any software or hardware product and its remote data processing solution, where absence of cybersecurity would result in direct or cascading impact. In practice, this covers almost every connected device and most software products. Pure SaaS products that process data remotely may fall within scope under the 'remote data processing solution' definition — this is an area of legal debate, but conservative compliance planning assumes in-scope.
Micro and small enterprises (fewer than 50 employees, less than €10M turnover) get some relief: they benefit from simplified conformity assessment routes and phased ENISA reporting obligations. But they are not exempt from the essential requirements.
Product classification: which category is your product?
The CRA creates three product classes with progressively stricter conformity assessment obligations:
Default products (most products)
The vast majority of products with digital elements fall into the 'default' category and require internal control (self-certification via Annex VIII). You carry out your own conformity assessment, prepare Annex VII technical documentation, draw up a Declaration of Conformity (DoC), and affix CE marking. No notified body involvement is required if harmonised standards cover your product and you comply with them.
Important products — Class I (Annex III)
Class I includes: identity management software, stand-alone and embedded browsers, password managers, software that manages privileged access, security information and event management (SIEM), network management tools, boot managers, public key infrastructure and digital certificate services, physical and virtual network interfaces, operating systems for server, desktop, and mobile environments, routers and modems intended for consumer use, and microprocessors with security-relevant functionality.
For Class I products: if you rely on harmonised standards published in the Official Journal, you can use internal control (Annex VIII). If there are no applicable harmonised standards or you choose not to use them, you need EU-type examination by a notified body (Annex IX).
Important products — Class II (Annex III)
Class II is reserved for the highest-risk products: operating systems for desktop, mobile, and server use (when not Class I), hypervisors and container runtime systems, public key infrastructure and digital certificate issuance, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors, secure elements, and hardware security modules (HSMs), smart meters, robots with safety functions, and safety components for industrial automation.
Class II products require conformity based on full quality assurance (Annex X) — this involves a notified body assessing and approving your quality management system. This is analogous to the highest conformity routes under other CE marking directives.
The essential requirements — what Annex I actually demands
Annex I is the heart of the CRA. Part I covers product security requirements; Part II covers vulnerability handling.
Annex I Part I — Product security requirements
Products must meet 12 baseline security attributes:
- No known vulnerabilities at launch: products must be placed on the market without known exploitable vulnerabilities.
- Secure by default: no insecure default configurations. Secure defaults must be restorable (factory reset to secure state).
- Authentication and access controls: appropriate mechanisms, least-privilege access, MFA where warranted by risk.
- Data confidentiality: data at rest and in transit must be encrypted; collection limited to what is necessary.
- Data integrity: software, data, and command integrity must be verifiable (secure boot, code signing).
- Minimal attack surface: unused ports, services, and code disabled or removed.
- DoS resilience: appropriate rate limiting and graceful degradation.
- Security logging: security-relevant events must be logged in a tamper-protected manner.
- Security updateability: products must be able to receive secure updates throughout the declared support period — this is one of the CRA's most distinctive requirements.
Annex I Part II — Vulnerability handling requirements
Manufacturers must:
- Establish a vulnerability identification and remediation process with CVSS-based severity triage and defined remediation timelines.
- Publish a coordinated vulnerability disclosure (CVD) policy — typically via security.txt (RFC 9116). ISO/IEC 29147 is the reference standard.
- Report actively exploited vulnerabilities to ENISA within 24 hours (early warning), 72 hours (notification), and 14 days (final report). This vulnerability-specific reporting cascade is separate from NIS2 incident reporting.
- Provide security updates free of charge for the declared support period. Paid security updates are prohibited.
- Maintain no commercial practices that incentivise delaying patches or withholding vulnerability information.
Technical documentation (Annex VII) and the SBOM requirement
Manufacturers must prepare and retain Annex VII technical documentation for 10 years from market placement. The 7 required documentation categories are:
- General description of the product, its intended use, and its security properties.
- Design, development, and production description including architecture, data flows, and security decisions.
- Cybersecurity risk assessment — using threat modelling (STRIDE, ENISA taxonomy) to identify and treat risks across the product lifecycle.
- Essential requirements compliance matrix — mapping each Annex I requirement to the implemented control.
- Standards applied — harmonised standards from the CEN/CENELEC JTC 13 family, ETSI EN 303 645, IEC 62443-4-1/-4-2.
- EU Declaration of Conformity copy.
- Instructions for use — including security guidance, CVD contact, update instructions, and support period end date.
The Software Bill of Materials (SBOM) is embedded in the Annex VII documentation requirements. ENISA guidance expects SBOMs in SPDX (ISO/IEC 5962:2021) or CycloneDX format, generated automatically as part of the CI/CD pipeline. The SBOM enables CVE scanning against all third-party components — this is particularly important for open-source dependency supply chain security.
Key compliance timelines
| Date | Obligation | Who |
|---|---|---|
| September 2025 | Market surveillance provisions apply (MSA powers active) | All manufacturers |
| December 2026 | Vulnerability reporting to ENISA platform (24h/72h/14d) | All manufacturers |
| December 2027 | Full CRA compliance required — Annex I, Annex VII, DoC, CE marking | All manufacturers / importers |
Three things to do now (before December 2027)
1. Classify your products and start the risk assessment. The cybersecurity risk assessment is the foundation of everything else. Use STRIDE or the ENISA IoT threat taxonomy. Document your threat model. This takes time but enables informed security engineering decisions — don't leave it for 2027.
2. Establish your CVD policy and vulnerability management process. Publish a security.txt file. Set up a dedicated security@ email address or bug bounty programme. Define your CVSS-based severity tiers and remediation SLAs. The 24-hour ENISA reporting obligation goes live December 2026 — you need a process before that date.
3. Integrate SBOM generation into your build pipeline. Tools like Syft, Trivy, or FOSSA can generate SPDX or CycloneDX SBOMs automatically. Once you have an SBOM, you can scan it against NVD/OSV databases to identify known CVEs in your dependencies — and that scan should be part of every release gate.
Penalties
Non-compliance with the essential requirements (Annex I) carries penalties up to €15 million or 2.5% of global annual turnover, whichever is higher. Non-compliance with other CRA obligations (documentation, reporting) carries penalties up to €10 million or 2% of global annual turnover. For micro and small enterprises, penalties are capped at turnover-based amounts. Market surveillance authorities can also order product withdrawal, recall, and prohibition of placing on the market.
Assess your product with our free CRA Compliance Checklist
We've built a free CRA Compliance Checklist covering all Annex I Part I and Part II requirements, Annex VII technical documentation, conformity assessment routes, and CE marking obligations. Answer the checks, get a score, and generate a full CRA compliance assessment report for your product team and legal counsel.
Also relevant: our EU AI Act Compliance Checklist for AI-enabled products (the CRA and EU AI Act have significant overlap for AI-integrated connected products) and our ISO 27001 Gap Assessment for the organisational security management system that underpins CRA product security practices.