EU Cyber Resilience Act
European Union Agency for Cybersecurity (ENISA) + National Market Surveillance Authorities
October 2024 (entered force); cybersecurity reporting obligations apply December 2025; full product requirements apply October 2027
Status
In Force
Risk Level
High
Jurisdiction
European Union
Enforcement
October 2024 (entered force); cybersecurity reporting obligations apply December 2025; full product requirements apply October 2027
high risk framework
All manufacturers placing products with digital elements on the EU market — including AI software vendors, IoT device makers, cloud software providers, and AI component suppliers — regardless of where they are based.
Overview
The EU Cyber Resilience Act (Regulation 2024/2847) establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market — including AI-enabled software, connected hardware, and AI components embedded in products. Signed into law October 2024, it fills a critical gap alongside the EU AI Act by ensuring AI-powered products meet baseline security-by-design requirements throughout their lifecycle.
Scope
All products with digital elements sold in the EU — including AI software, embedded AI in hardware (IoT, robots, vehicles), and AI-integrated industrial systems. Applies to manufacturers, importers, and distributors globally.
Applicability
Who Is Affected
- Software manufacturers: any company selling software products (including SaaS with downloadable components) in the EU
- AI product developers: companies embedding AI in consumer or industrial products
- IoT manufacturers: connected devices, smart appliances, industrial sensors
- Hardware manufacturers with digital elements: routers, smart cameras, medical devices with software
- Importers and distributors of covered products in the EU
Who Is Exempt
- Open-source software not made commercially available (partial exemption)
- Products already covered by sector-specific regulations with equivalent requirements (some medical devices, automotive under type-approval)
- National security and defence products
- Cloud services not embedded in a product (covered separately under NIS2)
Risk Tier Classification
Default Products
minimalStandard products with digital elements — must meet baseline security-by-design requirements and self-declare conformity.
Examples
- • Consumer software applications
- • Productivity tools
- • Non-critical IoT devices
- • AI chatbot applications
Requirements
- ✓ Self-assessment conformity
- ✓ Security-by-design documentation
- ✓ Vulnerability disclosure policy
- ✓ 5-year security support
Important Products — Class I
limitedProducts with higher cybersecurity risk — browsers, password managers, VPNs, network monitoring tools, AI systems used in critical functions.
Examples
- • Web browsers
- • Password managers
- • VPN software
- • AI-powered identity verification
- • Network management software
Requirements
- ✓ Self-assessment with harmonised standards OR third-party audit
- ✓ Enhanced documentation
- ✓ SBOM required
Important Products — Class II
highHigh-impact products including hypervisors, industrial firewalls, tamper-resistant hardware, and AI integrated in critical infrastructure.
Examples
- • Hypervisors
- • Industrial firewalls
- • Smart meters
- • AI in critical infrastructure control systems
- • Hardware security modules
Requirements
- ✓ Mandatory third-party conformity assessment
- ✓ Full SBOM
- ✓ Notified body certification
Critical Products
prohibitedHighest-risk products — smartcard chips, hardware security modules for critical infrastructure; require European Cybersecurity Certification Scheme.
Examples
- • Smartcard ICs
- • HSMs for critical infrastructure
- • Secure elements in national ID systems
Requirements
- ✓ European Cybersecurity Certification Scheme mandatory
- ✓ Highest level of independent assurance
Key Requirements
- Security-by-design: products must be designed, developed, and produced with appropriate security measures
- Vulnerability management: manufacturers must handle vulnerabilities throughout the product lifecycle
- Security support period: minimum 5 years of security updates for most product categories
- Incident reporting: actively exploited vulnerabilities must be reported to ENISA within 24 hours
- Conformity assessment: CE marking required for all covered products before EU market placement
- Software Bill of Materials (SBOM): documentation of software components required for critical products
- Secure default configurations and minimal attack surface
- Protection of confidentiality, integrity, and availability of data processed by the product
Guardrails & Operational Controls
- Security-by-design: cybersecurity built in from design phase, not retrofitted
- No known exploitable vulnerabilities at time of market placement
- Secure default settings with minimal attack surface
- Protection against unauthorised access, including state-of-the-art authentication
- Data minimisation: products must not collect more data than necessary for function
- 24-hour early warning to ENISA for actively exploited vulnerabilities
- 72-hour notification with full incident details
- Coordinated vulnerability disclosure policy required for all manufacturers
Technical Requirements
- SBOM (Software Bill of Materials): machine-readable inventory of all software components and dependencies
- Secure update mechanism: cryptographically signed updates; automatic security updates enabled by default
- Penetration testing documentation for Class I and II important products
- Vulnerability tracking and CVE assignment process
- Secure boot and integrity verification for firmware-based products
- Encryption of data at rest and in transit where applicable
- AI-specific: AI components in covered products must also meet EU AI Act requirements where applicable
Compliance Roadmap
- 1STEP 1 — Product inventory: Map all products with digital elements sold in EU; classify under Default, Class I, Class II, or Critical categories
- 2STEP 2 — Gap assessment: Assess current security practices against CRA essential requirements (Annex I); identify gaps in vulnerability management, update processes, and documentation
- 3STEP 3 — SBOM implementation: Build capability to generate and maintain Software Bill of Materials for all covered products
- 4STEP 4 — Vulnerability disclosure: Establish coordinated vulnerability disclosure policy and ENISA reporting workflow by December 2025
- 5STEP 5 — Conformity assessment: Determine whether self-assessment or third-party audit is required; engage notified body for Class II products
- 6STEP 6 — Technical hardening: Implement secure-by-design principles, secure defaults, minimal attack surface, and cryptographic update signing
- 7STEP 7 — Documentation package: Prepare technical documentation, EU Declaration of Conformity, and CE marking for all covered products by October 2027
- 8STEP 8 — Post-market monitoring: Establish ongoing vulnerability monitoring, incident response, and ENISA reporting capabilities
Implementation Guidance
- 1Start SBOM implementation now — generating accurate SBOMs for complex AI/software products takes 6–18 months of engineering investment
- 2Implement vulnerability reporting workflow to ENISA by December 2025 — the 24-hour early warning requirement is operationally demanding
- 3Review open-source exemption carefully — if your AI product is built on open-source but sold commercially, the exemption may not apply
- 4Coordinate CRA and EU AI Act compliance — both apply to AI products; a joint compliance programme avoids duplication
- 5Engage a Notified Body early for Class II products — notified body capacity is limited and lead times are growing
- 6Review software support commitments — the 5-year minimum security support period may require changes to product end-of-life policies
Industry Impact
Technology / Software
Every software product sold in the EU with a downloadable component is in scope. US software vendors face significant compliance investment — security-by-design, SBOM, 5-year support commitments, and CE marking all require engineering and legal resources.
AI / Machine Learning
AI products and AI-enabled software must meet CRA requirements alongside EU AI Act obligations. AI companies with EU customers need dual compliance programmes. Open-source AI model providers face nuanced exemption analysis.
IoT / Connected Devices
CRA was primarily designed for IoT security gaps — smart home, industrial IoT, connected vehicles, and medical devices all face mandatory security requirements that most current products do not meet.
Industrial / Manufacturing
AI in Industrial 4.0 and smart manufacturing faces CRA from October 2027. Manufacturers embedding AI in industrial control systems face both CRA and EU AI Act high-risk classification.
Healthcare
Medical devices with software components face CRA alongside MDR/IVDR. The overlap creates complex dual compliance — engage sector regulator early to determine which requirements take precedence.
Financial Services
Banking software and fintech AI products in scope. DORA (Digital Operational Resilience Act) and CRA overlap significantly — a unified compliance programme covering both is most efficient.
Regulatory Timeline
Sep 2022
European Commission published CRA proposal
Oct 2024
CRA entered into force (Regulation 2024/2847 published in Official Journal)
Dec 2025
Vulnerability and incident reporting obligations apply (Article 14)
Jun 2026
Notified body designation obligations apply
Oct 2027
Full CRA product requirements apply — all covered products must have CE marking
Notable Enforcement Cases
- 1CRA entered force October 2024 — no enforcement cases yet; market surveillance authorities beginning product audit programmes
- 2ENISA published first CRA implementation guidance in 2024 covering SBOM standards and vulnerability disclosure expectations
- 3Multiple major US software vendors publicly disclosed CRA compliance programmes and EU market product reviews in 2024–2025
Penalties for Non-Compliance
Up to €15M or 2.5% of global annual turnover (whichever is higher) for non-compliance with essential cybersecurity requirements. Up to €10M or 2% for other violations. Withdrawal from EU market for non-compliant products.
Framework Details
Short Name
EU CRA
Jurisdiction
European Union
Enforcement Date
October 2024 (entered force); cybersecurity reporting obligations apply December 2025; full product requirements apply October 2027
Enforcing Authority
European Union Agency for Cybersecurity (ENISA) + National Market Surveillance Authorities
Status
Risk Level
Affected Organizations
All manufacturers placing products with digital elements on the EU market — including AI software vendors, IoT device makers, cloud software providers, and AI component suppliers — regardless of where they are based.
Exposure Areas
- AI SaaS with downloadable components: CRA applies to downloadable software even if the core service is cloud-based — many AI tools have desktop clients or browser extensions in scope
- AI in IoT: AI-enabled smart devices, robots, and industrial sensors face dual compliance: CRA for cybersecurity and potentially EU AI Act for AI-specific requirements
- Open-source AI models: partially exempt but commercial exploitation of open-source AI may remove the exemption — important for AI companies building on open-source foundations
- US/non-EU software vendors: CRA applies to all products sold in the EU regardless of manufacturer location — US software companies need CRA compliance plans
- Embedded AI in manufacturing: Industry 4.0 AI systems in EU factories face CRA compliance requirements from October 2027
Tags
This is educational guidance only. Always consult qualified legal counsel for compliance decisions affecting your organization.