Understanding the EU Cyber Resilience Act
The Cyber Resilience Act (CRA) is EU legislation establishing mandatory cybersecurity requirements for products with digital elements. This guide explains what it means for manufacturers.
What is the CRA?
The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU regulation that:
- Sets horizontal cybersecurity requirements for all products with digital elements
- Requires manufacturers to address security throughout the product lifecycle
- Mandates vulnerability handling and incident reporting
- Requires CE marking to demonstrate conformity
The CRA aims to reduce the number of vulnerabilities in products with digital elements, ensure manufacturers maintain security throughout the product lifecycle, and improve transparency for users.
Timeline and key dates
| Date | Milestone | What it means |
|---|---|---|
| 10 December 2024 | Entry into force | CRA becomes law |
| 11 September 2026 | Reporting obligations | ENISA vulnerability notifications begin |
| 11 June 2027 | Conformity bodies | notified bodies must be designated |
| 11 December 2027 | Full enforcement | All CRA requirements apply |
Warning: Full enforcement is December 2027, but preparing now is essential. Products designed today must comply when they enter the market.
Who does the CRA apply to?
Covered products
The CRA applies to products with digital elements (PDEs) placed on the EU market:
Software products: Operating systems, mobile applications, desktop software, software libraries, firmware
Hardware products: IoT devices, network equipment, industrial controllers, smart devices, embedded systems
Connected products: Cloud-connected devices, API-enabled products, remote-managed systems, network-attached devices
Exclusions
| Category | Reason |
|---|---|
| Medical devices | Covered by MDR (2017/745) |
| Motor vehicles | Covered by vehicle type-approval |
| Aviation products | Covered by aviation safety regulations |
| SaaS (pure cloud) | Not a "product with digital elements". Note Art. 3(2): remote data processing integral to the product's function may bring SaaS components into scope |
| Open source (non-commercial) | Community projects excluded under conditions |
Core requirements
Annex I Part I: security requirements
Products must be designed and developed to ensure:
| Requirement | Description |
|---|---|
| No known exploitable vulnerabilities | Products must not be placed on the market with known exploitable vulnerabilities. Manufacturers must monitor and patch. |
| Secure by default | Ship with secure configuration: no default passwords, unnecessary ports closed, minimal attack surface out of the box |
| Data protection | Protect confidentiality, integrity, and availability of data through encryption, access controls, and integrity checks |
| Access control | Implement authentication and authorisation mechanisms to prevent unauthorised access to functions and data |
| Minimum attack surface | Disable unnecessary services, ports, and protocols. Remove debug interfaces and test accounts from production |
| Incident mitigation | Design containment boundaries and provide mechanisms for detection, forensic analysis, and recovery |
| Secure updates | Implement a signed, verifiable update mechanism that cannot be exploited to install tampered packages |
| Vulnerability disclosure | Provide a public contact point (security.txt, CVD policy) for receiving and processing vulnerability reports |
Annex I Part II: vulnerability handling
Manufacturers must:
- Identify and document vulnerabilities in their products
- Address vulnerabilities without delay
- Provide security updates free of charge for support period
- Share information about fixed vulnerabilities
- Maintain an SBOM (software bill of materials)
Annex II: information requirements
Manufacturers must provide users with:
- Contact point for security issues
- Expected product support period
- Instructions for secure installation and use
- How to report vulnerabilities
- SBOM or link to SBOM
Product categories
The CRA classifies products based on cybersecurity criticality:
Default products
Most products fall into this category. If your product is NOT listed in Annex III or IV, it is a default product.
- Assessment: internal (self-assessment)
- Module: A (internal production control)
- Examples: consumer apps, simple IoT devices, utilities
Important products (Annex III)
Products with higher cybersecurity relevance, divided into two classes:
Class I
| Product Type | Examples |
|---|---|
| Identity management | SSO systems, directory services |
| Browsers | Web browsers (standalone) |
| Password managers | Enterprise and consumer |
| VPN products | VPN clients and servers |
| Network management | SNMP managers, configuration tools |
| SIEM systems | Security monitoring platforms |
| Update management | Patch management systems |
| Remote access | Privileged access management |
| Boot managers | UEFI implementations |
Assessment: self-assessment using harmonised standards OR third-party
Note: This table shows selected examples only. The full Annex III Part I list contains 19 product categories. Check the classification guide for the complete list.
Class II
| Product Type | Examples |
|---|---|
| Hypervisors | VMware, KVM, Hyper-V |
| Container runtimes | Docker, containerd, CRI-O |
| Firewalls, intrusion detection/prevention systems | Enterprise/industrial firewalls, IDS/IPS appliances |
| Tamper-resistant microprocessors | Security-focused CPUs |
| Tamper-resistant microcontrollers | Secure microcontrollers |
Assessment: third-party required (Module B+C or H)
Critical products (Annex IV)
Highest criticality products requiring EU-type examination:
| Product type | Examples |
|---|---|
| Hardware devices with security boxes | HSMs, key management hardware with security enclosures |
| Smart meter gateways (Directive (EU) 2019/944) and devices for advanced security purposes | Smart metering infrastructure, secure cryptoprocessing devices |
| Smartcards or similar devices, including secure elements | Banking cards, ID cards, SIM cards, TPMs |
Assessment: EU-type examination required (Module B+C or H with additional requirements)
Detailed conformity assessment guide
Vulnerability handling requirements
ENISA notification obligations
When you discover an actively exploited vulnerability in your product:
Vulnerability notification flow:
| Step | Deadline | Action |
|---|---|---|
| 1 | 24 hours | Early warning notification to ENISA |
| 2 | 72 hours | Complete vulnerability notification with technical details |
| 3 | 14 days | Final report (vulnerabilities) or progress update |
| 4 | On fix | Final report with patch information and remediation guidance |
What triggers notification?
You must notify ENISA when:
- Actively exploited vulnerability discovered (by you or reported)
- Severe security incident impacting product security
- Third-party disclosure of vulnerability before you can patch
Documentation requirements
Technical file (Annex VII)
You must maintain a technical file containing:
| Document | Description |
|---|---|
| General description | What the product is and does |
| Design documentation | How security was implemented |
| Risk assessment | Cybersecurity risk analysis |
| Standards applied | List of harmonised standards used |
| SBOM | Software bill of materials |
| Test reports | Evidence of security testing |
| Vulnerability handling | Procedures and processes |
| EU declaration of conformity | Statement of conformity |
Retention period
Important: Technical documentation must be kept for 10 years after the last product unit is placed on the market OR until end of support, whichever is longer.
Support period
The CRA requires manufacturers to determine and publicly commit to a support period: the duration during which they will provide security updates for the product.
Article 13(8): determining the support period
Under Article 13(8), manufacturers must:
- Determine the support period before placing the product on the market
- Ensure the support period reflects the expected product lifetime and user expectations
- Communicate the support period to users at the point of sale and in the product documentation (Annex II requirement)
The support period must be documented in your user manual and stated in your EU declaration of conformity.
The five-year minimum rule
Important: The CRA requires the support period to be at least five years, unless the expected lifetime of the product is shorter. A manufacturer cannot unilaterally decide on a shorter support period simply for cost reasons. A shorter period must be justified by the nature of the product.
The five-year minimum is a floor, not a target. Consider:
| Product type | Typical justifiable support period |
|---|---|
| Consumer IoT devices (smart home, wearables) | 5 years (minimum) |
| Enterprise networking equipment | 7 to 10 years |
| Industrial control systems and PLCs | 10 to 20+ years |
| Medical devices with digital elements | Per MDR lifecycle, often 10+ years |
| Promotional / single-use devices | May justify shorter if expected lifetime demonstrably less than 5 years |
| Mobile applications | 5 years from last major version typically expected |
Warning: Even for low-cost or promotional products, the five-year minimum applies unless you can objectively demonstrate that users expect the device to be discarded sooner. Regulators will apply scrutiny to manufacturers claiming short lifetimes to avoid update obligations.
Article 13(9): update availability after issuance
Providing a security update is not sufficient by itself. Under Article 13(9):
- Security updates must remain available for download for at least 10 years after the date of issuance, OR for the remainder of the support period, whichever is longer
- This means even after a product reaches end-of-support, previously issued security updates must remain accessible
Info: If you issue a patch in year 3 of a 5-year support period, that patch must remain downloadable until at least year 13. Plan your update distribution infrastructure (CDN, update server, app store presence) for long-term availability.
Free-of-charge requirement
Security updates must be provided free of charge to users during the support period. Manufacturers may not:
- Charge separately for security patches
- Gate security updates behind paid support tiers
- Require a subscription renewal to receive security-only updates
This applies to all product categories, including enterprise software with tiered licensing.
End-of-support communication
When the support period is nearing its end, manufacturers must ensure users are informed. Best practices (and likely ADCO guidance when published):
- Notify users at least 12 months before end-of-support
- Communicate end-of-support date at point of sale (packaging, product listing, online store)
- Include end-of-support date in the user manual and on the manufacturer's website
- Where technically feasible, display an in-product notification as end-of-support approaches
Info: The Administrative Cooperation Group (ADCO) for the CRA is expected to publish indicative guidance for specific product categories on appropriate support period lengths. This guidance, while not legally binding, will reflect regulator expectations. Monitor ENISA and the European Commission for updates.
Penalties
Non-compliance with CRA can result in significant penalties:
| Violation | Maximum Fine |
|---|---|
| Essential requirements breach | €15 million or 2.5% of global turnover |
| Other obligations breach | €10 million or 2% of global turnover |
| Incorrect/misleading info | €5 million or 1% of global turnover |
Warning: In addition to fines, market surveillance authorities can order product withdrawal from the EU market.
Next steps
- Annex I requirements. Detailed checklist of essential cybersecurity requirements.
- Conformity assessment. Understand your assessment obligations.
- Incident reporting. How to handle ENISA vulnerability notifications.
Official resources
Help us improve. What was missing or unclear?