Cyber Resilience Act: Complete Guide for Product Teams
EU Regulation 2024/2847 — the Cyber Resilience Act — introduces mandatory cybersecurity requirements for all products with digital elements sold on the EU market. Full compliance is required by 11 December 2027. This guide explains everything manufacturers need to know.
Contents
- 1.What is the Cyber Resilience Act?
- 2.Who does it apply to?
- 3.Key deadlines and timeline
- 4.Essential requirements (Annex I)
- 5.Product classification
- 6.SBOM requirements
- 7.Vulnerability management
- 8.Incident reporting (Article 14)
- 9.Conformity assessment and CE marking
- 10.Penalties for non-compliance
- 11.How to prepare
1. What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is landmark EU legislation that introduces mandatory cybersecurity requirements for any product with digital elements (PDE) placed on the EU market. It entered into force on 11 December 2024.
The CRA was driven by a stark reality: most cybersecurity incidents exploit known vulnerabilities in products that were never designed with security in mind. The EU Commission estimated that cybercrime costs the global economy over €5.5 trillion annually, and that a significant proportion of incidents could have been prevented had manufacturers applied basic security hygiene during development.
Unlike previous EU cybersecurity legislation (NIS2, GDPR), the CRA is product law. It attaches obligations directly to products and their manufacturers — not to operators of services. If you make a product with software or network connectivity and sell it in the EU, the CRA applies to you.
Key point: The CRA covers all products with digital elements — hardware with embedded software, standalone software, SaaS products bundled with client software, firmware, mobile apps, and more. The scope is deliberately broad to close gaps left by earlier legislation.
2. Who Does the CRA Apply To?
The CRA applies to any organisation that places a product with digital elements on the EU market. This creates obligations for three types of economic operator:
Manufacturers
Any natural or legal person that develops, designs, manufactures, or has a product designed, developed, or manufactured and markets it under their name or trademark — including software developers, hardware OEMs, and cloud-connected device makers. Manufacturers bear the heaviest obligations.
Importers
Organisations established in the EU that place a product from a manufacturer established outside the EU on the EU market. Importers must verify that the manufacturer has fulfilled their obligations and that CE marking is present.
Distributors
Any person in the supply chain, other than the manufacturer or importer, that makes a product available on the EU market. Distributors must not place non-compliant products on the market.
Geography matters: The CRA applies to any product sold on the EU market, regardless of where the manufacturer is based. A US, UK, or Asian company selling software or hardware into the EU must comply.
What is a "product with digital elements"? The CRA defines this as any software or hardware product — and its remote data processing solutions — that has a direct or indirect logical or physical data connection to another device or network. This captures IoT devices, routers, consumer electronics, industrial control systems, operating systems, applications, firmware, and cloud-connected products.
3. Key Deadlines and Timeline
11 December 2024
CRA entered into force
Regulation 2024/2847 published and entered into force.
11 September 2026
Reporting obligations begin
Articles 14 and 17 apply — manufacturers must begin reporting actively exploited vulnerabilities and security incidents to ENISA.
11 December 2027
Full CRA compliance required
All products with digital elements placed on the EU market must comply in full. CE marking required.
4. Essential Requirements (Annex I)
Annex I of the CRA lists the essential cybersecurity requirements all products must meet. They are split into two parts: Part I covers security properties of the product itself; Part II covers vulnerability handling obligations.
Security by design
Annex I, Part IProducts must be designed and developed to ensure an appropriate level of cybersecurity based on identified risks.
No known exploitable vulnerabilities
Annex I, Part IProducts must be placed on the market without known exploitable vulnerabilities in critical components.
Secure default configuration
Annex I, Part IDefault settings must be secure; unnecessary functions, ports, and services disabled by default.
Access control
Annex I, Part IProducts must protect against unauthorised access through appropriate authentication and authorisation mechanisms.
Data minimisation
Annex I, Part IProducts must process only data adequate and necessary for their intended purpose.
Data confidentiality and integrity
Annex I, Part IData at rest and in transit must be protected with appropriate encryption and integrity checks.
Availability and resilience
Annex I, Part IProducts must be designed to limit the impact of incidents and minimise attack surfaces.
SBOM
Annex I, Part IIManufacturers must identify and document all components via a machine-readable Software Bill of Materials.
Vulnerability handling
Annex I, Part IIManufacturers must have a coordinated vulnerability disclosure policy and handle reported vulnerabilities effectively.
Incident reporting
Article 14Actively exploited vulnerabilities and security incidents must be reported to ENISA within 24 hours of discovery.
5. Product Classification
The CRA divides products into four risk classes. Your class determines which conformity assessment route you must follow.
Default
Most products. Self-assessment (Module A) allowed. Examples: smart appliances, general-purpose software, network cameras.
Important — Class I
Identity management software, browsers, password managers, firewalls, VPNs, MDM. Third-party audit OR harmonised standard required.
Important — Class II
Hypervisors, PKI, industrial control systems. Mandatory third-party conformity assessment by a Notified Body.
Critical
Smart meter gateways, secure elements, hardware security modules, smart cards. Full EUCC certification required.
6. SBOM Requirements
Annex I, Part II requires manufacturers to identify and document components contained in the product with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.
In practice, this means generating a machine-readable SBOM in CycloneDX or SPDX format for every product version. The SBOM must be kept current throughout the product's support lifecycle and must be available to market surveillance authorities on request.
7. Vulnerability Management
The CRA requires manufacturers to handle vulnerabilities proactively throughout the product support period — which must be at least five years for most products. Key obligations include:
- Maintain a public Coordinated Vulnerability Disclosure (CVD) policy under Article 15
- Accept and process vulnerability reports from security researchers
- Remediate vulnerabilities without undue delay and at no cost to users
- Provide security updates separately from functionality updates where technically feasible
- Share information about vulnerabilities with ENISA and relevant CSIRTs
- Publish security advisories in CSAF v2.0 format for significant vulnerabilities
8. Incident Reporting (Article 14)
From 11 September 2026, manufacturers must report to ENISA (via the relevant national CSIRT) within strict deadlines:
24 hours
Early warning
Report any actively exploited vulnerability or security incident with a significant impact on the security of the product.
72 hours
Detailed notification
Provide a detailed notification including a severity assessment, impact scope, and any indicators of compromise.
14 days
Final report
Submit a final report with root cause analysis, mitigations applied, and timeline of events.
9. Conformity Assessment and CE Marking
Before placing a product on the EU market after December 2027, manufacturers must complete a conformity assessment, compile a technical file (Annex VII), draw up an EU Declaration of Conformity, and affix CE marking.
The route depends on your product class. Default-class products can self-certify (Module A) if no harmonised standard applies, or follow the harmonised standard if one exists. Class I and above require third-party involvement. Class II and Critical require Notified Body assessment.
Conformity assessment routes explained10. Penalties for Non-Compliance
The CRA sets significant fines aligned with GDPR-style enforcement. Market surveillance authorities in each EU Member State will have powers to require product withdrawal, issue bans, and impose fines.
Up to €15 million or 2.5% of global turnover
Non-compliance with essential cybersecurity requirements (Annex I) or obligations on manufacturers, importers, and distributors.
Up to €10 million or 2% of global turnover
Non-compliance with obligations on authorised representatives, importers, and distributors.
Up to €5 million or 1% of global turnover
Supplying incorrect, incomplete, or misleading information to market surveillance authorities.
11. How to Prepare
The December 2027 deadline sounds distant, but the work required — especially SBOM generation, CVD policy, and technical file compilation — takes months to implement properly. Start now with these five steps:
Run a CRA applicability assessment
Determine whether the CRA applies to your products and, if so, which risk class they fall into. This drives every subsequent decision.
Take the free assessment →Implement Annex I security requirements
Conduct a gap analysis against the Annex I requirements. Prioritise secure-by-default configuration, access controls, and patch management processes.
View Annex I checklist →Generate and automate SBOMs
Integrate SBOM generation into your CI/CD pipeline. Use Syft or CycloneDX CLI to produce CycloneDX SBOMs on every build.
SBOM implementation guide →Establish a CVD policy
Publish a coordinated vulnerability disclosure policy and a security.txt file. Set up a process to receive, triage, and respond to vulnerability reports.
CVD policy guide →Prepare for incident reporting
Build internal processes for the Article 14 24h/72h/14d reporting timeline before September 2026 when the obligation becomes live.
Incident reporting guide →Related Guides
Ready to start your CRA compliance journey?
Take the free 5-minute CRA applicability assessment to determine your product class and conformity route, then use CRAReady to automate SBOM generation, vulnerability management, and incident reporting.