Cyber Resilience Act
The EU's first horizontal cybersecurity regulation for products with digital elements — software, firmware, hardware with connected components. Entered into force December 11, 2024. Manufacturers, importers, and distributors face mandatory security-by-design obligations, vulnerability reporting, and minimum 5-year support periods.
Regulation
EU 2024/2847
In force
11 Dec 2024
Full enforcement
11 Dec 2027
ENISA reporting
11 Sep 2026
Who does the CRA apply to?
In scope
- • Software products placed on the EU market
- • Hardware products with digital elements (IoT devices, connected hardware)
- • AI systems that are products with digital elements
- • Manufacturers, importers, and distributors of the above
- • Open source commercial stewards (with obligations)
Out of scope
- • Products covered by sector-specific rules (medical devices, aviation, vehicles)
- • Products for national security or military purposes
- • Services (covered by NIS2 instead)
- • Non-commercial open source software
Structure
| Section | Coverage | Articles |
|---|---|---|
| Chapter I | General Provisions | Art. 1–9 |
| Chapter II | Obligations of Economic Operators | Art. 10–24 |
| Chapter III | Conformity of Products | Art. 25–36 |
| Chapter IV | Notification of CABs | Art. 37–56 |
| Chapter V | Market Surveillance & Enforcement | Art. 57–71 |
| Annex I | Essential Cybersecurity Requirements | Parts I–II |
| Annex II | Information & Instructions to Users | — |
| Annex III | Important Products (Class I & II) | — |
Art. 13 + Annex I
Essential Cybersecurity Requirements
Plain English
Annex I is the core technical requirement. Every product with digital elements must meet eight security properties by design — not as an add-on. These are: (1) no known vulnerabilities at launch, (2) secure defaults with reset capability, (3) proper access control/authentication, (4) data encryption at rest and in transit, (5) data integrity protection, (6) data minimisation, (7) minimal attack surface, (8) DoS resilience. Additionally, manufacturers must handle vulnerabilities throughout the product lifetime (Annex I, Part II), including disclosing to ENISA within 24 hours of a known actively-exploited vulnerability.
Official Text (EUR-Lex)
Products with digital elements shall be designed, developed, and produced in a manner ensuring an appropriate level of cybersecurity based on the risks (Art. 13). Annex I, Part I — Security requirements relating to the properties of products with digital elements: (1) Products shall be delivered without any known exploitable vulnerabilities; (2) Products shall be delivered with a secure by default configuration, including the possibility to reset the product to its original state; (3) Products shall ensure protection from unauthorised access by appropriate control mechanisms, including authentication, identity or access management systems; (4) Products shall protect the confidentiality of stored, transmitted or otherwise processed data by encrypting relevant data at rest and in transit using state-of-the-art mechanisms; (5) Products shall protect the integrity of stored, transmitted or otherwise processed data from manipulation or unauthorised modification; (6) Products shall process only data that are adequate, relevant and limited to what is necessary for the intended purpose ('minimisation of attack surface'); (7) Products shall be designed and developed with limited attack surfaces, including external interfaces; (8) Products shall be resilient against denial of service attacks.
Key obligations
- 1Design products with no known exploitable vulnerabilities at time of placement on market
- 2Implement secure default configurations — security must be on by default
- 3Use state-of-the-art encryption for data at rest and in transit
- 4Implement proper authentication and access control mechanisms
- 5Minimise the attack surface — collect only necessary data, limit external interfaces
- 6Ensure resilience against denial of service attacks
- 7Establish a vulnerability handling process before market placement
- 8Apply security patches and updates for at least 5 years after product placement
Tools for this article
Related articles
Source
Official text from EUR-Lex — Regulation (EU) 2024/1689 (EU AI Act). This text is in the public domain.
Annex I — The 8 Security Requirements in Detail
Annex I Part I lists 8 mandatory security properties every product with digital elements must have by design. These are minimum requirements — the state of the art may demand more. Here is what each requirement means in practice.
No known exploitable vulnerabilities at market placement
Products must not be placed on the market containing known exploitable vulnerabilities. This includes known CVEs, unpatched dependencies, and supply chain weaknesses.
Implementation steps
- →Conduct a full vulnerability scan (SAST, DAST, SCA) before each release
- →Subscribe to vulnerability databases (NVD, MITRE CVE) for your components
- →Implement a software bill of materials (SBOM) to track all dependencies
- →Patch all critical and high-severity CVEs before shipping
Secure by default configuration
Products must ship with security enabled by default. Secure configurations should not require user action to activate. The product must also be resettable to its original secure state.
Implementation steps
- →Disable all unnecessary services and ports in default builds
- →Require password change on first use (no universal default passwords)
- →Implement factory reset functionality that restores original secure configuration
- →Document and justify any default setting that deviates from maximum security
Unauthorised access protection
Products must use appropriate authentication, identity management, and access control mechanisms to prevent unauthorised access.
Implementation steps
- →Implement multi-factor authentication (MFA) for privileged access
- →Use role-based access control (RBAC) — principle of least privilege
- →Enforce strong password policies or certificate-based authentication
- →Implement session management with appropriate timeouts
Data encryption at rest and in transit
Products must protect data confidentiality using state-of-the-art encryption for data stored on the device and data transmitted over networks.
Implementation steps
- →Use TLS 1.3 (minimum TLS 1.2) for all network communications
- →Encrypt sensitive data at rest using AES-256 or equivalent
- →Implement proper key management — never hardcode encryption keys
- →Use HTTPS-only, implement HSTS, ensure certificate validation
Data integrity protection
Products must protect data integrity — preventing unauthorised modification or manipulation of stored or transmitted data.
Implementation steps
- →Use cryptographic signatures or MACs to verify data integrity
- →Implement write-protection or checksums on firmware and critical files
- →Use secure boot to verify the integrity of the software at startup
- →Log all data modification events for audit trail
Data minimisation (minimal attack surface from data perspective)
Products must process only data that is adequate, relevant, and limited to what is necessary — minimising what is collected, stored, and transmitted.
Implementation steps
- →Audit all data flows and remove unnecessary data collection
- →Implement data retention policies — delete data when no longer needed
- →Use anonymisation or pseudonymisation where full identification is not required
- →This overlaps with GDPR data minimisation (Art. 5(1)(c)) if personal data is involved
Minimal attack surface
Products must limit their attack surface by minimising exposed external interfaces, disabling unnecessary services, and using minimal permissions.
Implementation steps
- →Close all unused ports and disable unnecessary network services
- →Remove all unused software components, libraries, and SDKs
- →Use application whitelisting where appropriate
- →Implement network segmentation for IoT devices
Resilience against denial of service (DoS) attacks
Products must be resilient against attacks that aim to make them unavailable — including network-based DoS and resource exhaustion attacks.
Implementation steps
- →Implement rate limiting on all APIs and network interfaces
- →Design for graceful degradation under high load
- →Test DoS resilience as part of your security testing programme
- →For network-facing products: implement traffic filtering and anomaly detection
Art. 14
Vulnerability Handling & ENISA Reporting
Plain English
The CRA imposes strict vulnerability reporting timelines. When a manufacturer learns of an actively exploited vulnerability in their product, they must notify ENISA (the EU cybersecurity agency) within 24 hours. A full vulnerability report is due within 72 hours. A final report must follow within 14 days. Manufacturers must also have a coordinated vulnerability disclosure policy, a publicly accessible contact point for security researchers, and continue patching products for a minimum 5-year support period.
Official Text (EUR-Lex)
1. Manufacturers shall handle vulnerabilities in products with digital elements effectively. They shall address and remediate vulnerabilities in a timely manner including by providing security updates. 3. For the purposes of paragraph 1, manufacturers shall: (a) put in place policies and procedures to ensure effective handling of vulnerabilities in products with digital elements, including the coordinated vulnerability disclosure policy; (b) provide contact information to enable the reporting of vulnerabilities; 4. Without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of a product with digital elements, the manufacturer shall notify ENISA of: (a) any actively exploited vulnerability contained in the product with digital elements; (b) any severe incident having an impact on the security of the product.
Key obligations
- 1Establish a coordinated vulnerability disclosure policy before going to market
- 2Provide a public contact point for security researchers to report vulnerabilities
- 3Notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability
- 4Submit a full vulnerability report to ENISA within 72 hours
- 5Submit a final report to ENISA within 14 days with full details and mitigations
- 6Provide security updates for at least 5 years after market placement
- 7Inform users about vulnerabilities promptly and provide patches free of charge
Tools for this article
Related articles
Source
Official text from EUR-Lex — Regulation (EU) 2024/1689 (EU AI Act). This text is in the public domain.
Art. 32 + Annex III
Important Products — Class I and Class II
Plain English
Most products with digital elements can self-certify compliance with the CRA (standard conformity assessment). However, products listed in Annex III as 'important' face stricter rules. Class I products (e.g. password managers, firewalls, routers) must use harmonised standards or European cybersecurity schemes to demonstrate conformity — a more structured self-assessment. Class II products (e.g. OS for servers, industrial control systems, PKI) must go to a third-party conformity assessment body. Critical infrastructure software is therefore subject to the most rigorous CRA requirements.
Official Text (EUR-Lex)
Products listed in Annex III are considered 'important products with digital elements' and face stricter conformity assessment requirements. Class I products (self-assessment with harmonised standards permitted) include: — Identity management software and hardware, password managers, biometric readers — Browsers, hypervisors, container runtimes, firewalls, network monitoring tools — Routers, modems, smart home devices, wearables with security functions Class II products (third-party conformity assessment required) include: — Operating systems for servers, desktops, and mobile devices — Hypervisors and container runtimes used in critical infrastructure — Public key infrastructure and certificate authorities — Industrial automation and control systems
Key obligations
- 1Identify whether your product is a standard product, Class I important, or Class II important
- 2For Class I: conduct conformity assessment using harmonised cybersecurity standards
- 3For Class II: engage a notified/conformity assessment body for third-party assessment
- 4Prepare technical documentation per Art. 31 before market placement
- 5Affix CE marking to the product once conformity is confirmed
- 6Issue EU declaration of conformity (Art. 28)
Tools for this article
Related articles
Source
Official text from EUR-Lex — Regulation (EU) 2024/1689 (EU AI Act). This text is in the public domain.
Art. 64
CRA Penalties
€15 million
or 2.5% of global annual turnover
Non-compliance with essential requirements (Annex I)
€10 million
or 2% of global annual turnover
Other obligations (documentation, marking, reporting)
€5 million
or 1% of global annual turnover
Supplying incorrect or misleading information
CRA and EU AI Act — Interaction
AI systems that are also “products with digital elements” are subject to both the EU AI Act and the CRA. Article 15 of the EU AI Act requires high-risk AI systems to be “resilient against attempts by unauthorised third parties to alter their use, outputs or performance” — this directly overlaps with CRA Annex I cybersecurity requirements.
Key overlapping obligations
- • Cybersecurity risk assessment (AI Act Art. 9 + CRA Art. 13)
- • Technical documentation (AI Act Annex IV + CRA Art. 31)
- • Post-market monitoring (AI Act Art. 72 + CRA Art. 14)
- • Incident reporting to authorities
Compliance strategy
- • Design a single integrated security risk assessment
- • Create shared technical documentation covering both
- • Align monitoring and incident response procedures
- • Plan for both Aug 2026 (AI Act) and Dec 2027 (CRA) deadlines
Check your CRA & AI Act deadlines
Use the Timeline Calculator to see all enforcement dates side by side.
View enforcement timeline →