The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024. It is the first EU-wide law that places legally binding cybersecurity obligations directly on manufacturers, importers, and distributors of hardware and software products.
Unlike GDPR, which protects personal data, the CRA protects the security of digital products themselves — ensuring that connected devices and software are secure by design, and that vulnerabilities are managed throughout the product's lifecycle.
Scope: Who Does the CRA Apply To?
The CRA applies to any product with digital elements (PDE) that is placed on the EU market, regardless of where the manufacturer is located.
A product with digital elements is any hardware or software product that:
- Can connect to another device or network (directly or indirectly)
- Has a digital component that contributes to its function
This includes:
- Consumer IoT devices (smart home, wearables, routers)
- Industrial control systems and OT equipment
- Operating systems, firmware, and applications
- Mobile apps and desktop software
- Cloud-connected products
Who Is Responsible?
The CRA defines three roles:
- Manufacturer — designs, develops, or produces a PDE and places it on the market
- Importer — brings a PDE from outside the EU into the EU market
- Distributor — makes a PDE available on the EU market without modifying it
Manufacturers carry the heaviest obligations. Importers and distributors must verify that manufacturers comply before placing products on the market.
What Is Excluded?
The CRA excludes:
- Products already covered by sector-specific regulation (medical devices, aviation, automotive under type-approval)
- Open-source software developed outside a commercial activity
- National security and defense products
Product Categories
The CRA divides products into three risk classes, each with different conformity assessment paths.
Default Products
Products with limited cybersecurity risk. The vast majority of PDEs fall here.
Compliance path:
- Self-assessment by the manufacturer
- No third-party audit required
Examples: smart home devices, productivity software, consumer routers.
Important Products — Class I
Products whose compromise would have a significant impact on many users or on critical infrastructure.
Compliance path:
- Self-assessment using harmonized standards
- OR third-party audit by a notified body
Examples: identity and access management software, VPNs, firewalls, password managers, network management tools.
Important Products — Class II
Products with higher cybersecurity risk whose failure could have a severe cascading effect.
Compliance path:
- Mandatory third-party audit by a notified body
Examples: hypervisors, industrial firewalls, hardware security modules (HSMs), smartcard readers, microcontrollers with security functions.
Critical Products
A small set of products considered foundational to EU cybersecurity (e.g., hardware security modules, smart meters, root certificate authorities). These may be subject to European cybersecurity certification schemes instead of standard CRA conformity assessment.
Key Requirements
Security by Design
Manufacturers must ensure products are secure from the ground up.
Requirements include:
- No known exploitable vulnerabilities at the time of placing on the market
- A minimal attack surface by default configuration
- Confidentiality and integrity of data stored, transmitted, or processed
- Protection against unauthorized access, including strong authentication where applicable
- Ability to receive security updates and apply them in a timely manner
- Secure update mechanisms that do not break functionality
Vulnerability Management
Manufacturers must actively manage vulnerabilities throughout the product's supported life.
Requirements include:
- Identifying and remediating vulnerabilities in the product and its components
- Maintaining a Software Bill of Materials (SBOM) in machine-readable format
- Applying security patches promptly and making them available to users free of charge
- Defining and communicating the end-of-support date
- Supporting the product for a period proportionate to its expected use (minimum five years where reasonable)
Incident and Vulnerability Reporting
Manufacturers must report to ENISA (the EU Agency for Cybersecurity) and to the relevant national CSIRT.
Reporting obligations:
- Actively exploited vulnerabilities — notify within 24 hours of becoming aware
- Severe incidents — notify within 72 hours of becoming aware
- Final report — submit within 14 days with full details and remediation status
This obligation applies from September 2026, earlier than the rest of the CRA.
Technical Documentation and CE Marking
Manufacturers must produce and maintain technical documentation demonstrating compliance.
Documentation must include:
- Product description and intended use
- Design and development processes
- Risk assessment and security measures applied
- Test and evaluation results
- SBOM
- Declaration of conformity
Compliant products must bear the CE mark, confirming they meet CRA requirements before being placed on the EU market.
User Information and Transparency
Manufacturers must provide clear information to users.
This includes:
- Known vulnerabilities and how they are being addressed
- The product's end-of-support date
- How to report vulnerabilities (a point of contact must be published)
- Instructions for secure configuration and use
How to Comply: Step-by-Step
Step 1 — Classify Your Products
Determine which of your products are PDEs and which risk class each falls into. Check whether any are excluded (e.g., sector-specific regulation, open source).
Step 2 — Perform a Cybersecurity Risk Assessment
For each PDE, conduct a risk assessment covering:
- Intended use and foreseeable misuse
- Known vulnerabilities in components (check CVE databases, NVD)
- Threat scenarios relevant to the product's environment
- Impact of a security failure on users and the supply chain
Document this assessment and update it whenever the product changes or new threats emerge.
Step 3 — Implement Security by Design
Apply security controls at the design and development stage:
- Enable secure defaults — disable unused features, ports, and services out of the box
- Enforce strong authentication; remove hardcoded credentials
- Encrypt sensitive data at rest and in transit
- Implement input validation and memory-safe coding practices where applicable
- Build a secure update mechanism with integrity checking
Step 4 — Generate and Maintain an SBOM
Produce a Software Bill of Materials listing all third-party and open-source components.
The SBOM must:
- Be in a machine-readable format (e.g., SPDX, CycloneDX)
- Include component names, versions, and known vulnerabilities
- Be kept current throughout the product lifecycle
Use the SBOM to monitor for newly disclosed CVEs in your dependencies and trigger patches accordingly.
Step 5 — Establish a Vulnerability Disclosure Program
Set up a public point of contact for reporting vulnerabilities:
- Publish a security.txt file or a dedicated security page
- Define a responsible disclosure policy and timeline
- Assign an internal team to triage and respond to reports
- Track and remediate reported vulnerabilities
Step 6 — Define and Communicate End-of-Support
Every product must have a defined support period during which security updates will be provided.
- State the end-of-support date on packaging, documentation, and your website
- Plan update delivery so users can apply patches without friction
- Do not abandon products before their stated support period ends
Step 7 — Conduct Conformity Assessment
Select the correct conformity assessment path for your product class:
| Class | Assessment Path |
|---|---|
| Default | Self-assessment against harmonized standards |
| Important — Class I | Self-assessment with standards OR notified body audit |
| Important — Class II | Mandatory notified body audit |
Prepare your technical documentation and Declaration of Conformity before affixing the CE mark.
Step 8 — Set Up Reporting Pipelines
Prepare internal processes to meet the 24-hour and 72-hour reporting windows:
- Identify who is responsible for triggering reports to ENISA and national CSIRTs
- Know your relevant national CSIRT (each EU member state has one)
- Automate vulnerability monitoring where possible (dependency scanners, threat intelligence feeds)
- Document your incident response plan and rehearse it
Step 9 — Maintain Ongoing Compliance
CRA compliance is not a one-time activity.
Ongoing obligations include:
- Monitoring newly disclosed CVEs in your product's components
- Releasing patches in a timely manner and informing users
- Updating technical documentation after significant changes
- Reviewing and updating your risk assessment regularly
- Reassessing your conformity class if the product's risk profile changes
Key Deadlines
| Date | Obligation |
|---|---|
| December 2024 | CRA enters into force |
| September 2026 | Vulnerability and incident reporting obligations apply |
| December 2027 | All other CRA requirements fully apply (manufacturers must CE-mark compliant products) |
Penalties for Non-Compliance
Non-compliance with the CRA can result in significant fines.
| Violation | Maximum Fine |
|---|---|
| Non-compliance with essential cybersecurity requirements | €15 million or 2.5% of global annual turnover |
| Non-compliance with other obligations (documentation, reporting) | €10 million or 2% of global annual turnover |
| Providing incorrect or misleading information to authorities | €5 million or 1% of global annual turnover |
The higher of the two values applies, whichever is greater.
National market surveillance authorities are responsible for enforcement and can order products to be withdrawn from the market.
CRA vs. GDPR: Key Differences
| GDPR | CRA | |
|---|---|---|
| Focus | Personal data protection | Product cybersecurity |
| Who it regulates | Data controllers and processors | Manufacturers, importers, distributors |
| Applies to | Organizations processing EU personal data | Products sold on the EU market |
| Core obligation | Protect data of individuals | Secure products throughout their lifecycle |
| Key artifact | Privacy notice, DPA | Technical documentation, SBOM, CE mark |
Both regulations may apply simultaneously to the same organization — for example, a manufacturer of a connected health device must comply with both GDPR (personal health data) and the CRA (device security).
Summary
The EU Cyber Resilience Act is a landmark regulation that makes cybersecurity a legal requirement for any hardware or software product sold in the EU.
It applies globally to any manufacturer, importer, or distributor placing a product with digital elements on the EU market, regardless of where they are based.
The CRA requires security by design, ongoing vulnerability management, a Software Bill of Materials, transparent end-of-support commitments, and fast reporting of exploited vulnerabilities and severe incidents.
Compliance requires a structured approach: classify your products, assess risks, implement security controls, generate an SBOM, establish a disclosure program, run the correct conformity assessment, and maintain compliance throughout the product's lifecycle.
With reporting obligations starting September 2026 and full enforcement from December 2027, organizations need to begin their CRA compliance programs now.