The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, the first European law to impose horizontal cybersecurity requirements on products with digital elements placed on the Union market. In one sentence: if your company manufactures, imports or distributes connectable hardware or software, the CRA requires you to build in security by design, maintain a SBOM, handle vulnerabilities throughout the support period and report actively exploited vulnerabilities to ENISA. This guide explains what the CRA is, how it differs from NIS2 and DORA, who must comply, the core obligations, the deadlines (11 September 2026 and 11 December 2027) and the penalties, which reach 15 million euros or 2.5 percent of worldwide turnover.
What the Cyber Resilience Act (CRA) is
The Cyber Resilience Act is Regulation (EU) 2024/2847 of the European Parliament and of the Council, published in the Official Journal on 20 November 2024 and in force since 10 December 2024. Because it is a Regulation (and not a Directive like NIS2), it is directly applicable across all 27 Member States with no need for national transposition.
It targets a concrete problem: until now, a router, an IP camera, an industrial firmware image or a software library could be sold in the EU with no minimum cybersecurity requirement and no obligation to patch flaws. The CRA closes that gap by applying the logic of the New Legislative Framework (the same scheme that governs the safety of toys or machinery) to cybersecurity: essential requirements, conformity assessment, CE marking and market surveillance.
The central concept is the product with digital elements: any software or hardware product, and its associated remote data processing solutions, whose logical or physical connection to a device or network is part of its functions. It spans everything from operating systems, browsers and password managers to IoT sensors, microcontrollers and enterprise software.
How it differs from NIS2 and DORA
This is the most common question, and the answer is clear: they regulate different things.
- NIS2 (Directive (EU) 2022/2555) governs the security of networks and information systems of essential and important entities. It obliges the operator (the hospital, the utility, the MSP) to manage its risk.
- DORA (Regulation (EU) 2022/2554) governs the digital operational resilience of the financial sector. It obliges the financial entity to withstand, respond to and recover from ICT incidents.
- CRA governs the product itself. It obliges the manufacturer to make what it sells secure and to keep it secure.
Put another way: NIS2 and DORA look at the organization that uses or operates technology; the CRA looks at the one that builds and sells it. A single company can be subject to all three. A network equipment vendor selling to hospitals complies with the CRA for its product, and if it also runs critical infrastructure it may fall under NIS2 as an entity. To place each framework, we recommend reading DORA vs NIS2: which regulation applies and when.
Who must comply: manufacturers, importers and distributors
The CRA spreads obligations across the economic operators in the chain:
- Manufacturer: carries the bulk of the obligations. It designs, develops and places the product on the market under its own name or trademark. It answers for the essential requirements, the technical documentation, the CE marking and vulnerability handling.
- Importer: may only place products on the market that comply with the CRA and whose manufacturer has carried out the conformity assessment. It must verify the CE marking and the documentation.
- Distributor: acts with due care, checks that the product carries CE marking and instructions, and does not make available products it knows to be non-compliant.
One nuance matters for open source: developers of non-commercial open source software are largely out of scope, while open source stewards who sustain projects used in commercial products take on lighter obligations. Products already covered by sector-specific rules are excluded (medical devices under MDR/IVDR, automotive, aviation), and pure SaaS is excluded except where it is a remote data processing solution integral to the product.
Product categories and conformity assessment
Not every product follows the same route. The CRA defines three levels of criticality:
| Category | Examples | Assessment |
|---|---|---|
| Default (approx. 90 percent) | Office software, games, smart speakers, hard drives | Self-assessment (internal control, Module A) |
| Important Class I (Annex III) | Password managers, VPNs, firewalls, SIEM, network managers | Self-assessment if harmonized standards apply, otherwise third party |
| Important Class II (Annex III) | Hypervisors, industrial firewalls, tamper-resistant microcontrollers | Mandatory notified body assessment |
| Critical (Annex IV) | Smart meter gateways, smart cards, HSMs | May require European EUCC certification |
The practical upshot is that most manufacturers will be able to self-certify, but they must produce and keep the Annex VII technical documentation, issue the EU declaration of conformity and affix the CE marking. Class II and critical products need an accredited third party.
Core obligations
The essential requirements live in Annex I, split into product properties (Part I) and vulnerability handling (Part II).
Security by design
The product must ship secure by default: with no known exploitable vulnerabilities, a minimized attack surface, protection of the confidentiality, integrity and availability of data, robust access control and secure update mechanisms (signed and verifiable). In practice this means threat modeling in the development lifecycle, hardened factory configuration and, where appropriate, an automatic update channel. It is the same approach we apply in secure development and DevSecOps engagements.
Vulnerability handling, SBOM and updates
Part II of Annex I is the most operational and the one that most transforms engineering practice:
- SBOM (Software Bill of Materials): the manufacturer must draw up a component inventory in a machine-readable format covering at least the top-level dependencies. The standard formats are CycloneDX and SPDX, generated with tools such as
syftor fed into an OWASP Dependency-Track. - Remediation without delay: identify and fix vulnerabilities through security updates, cross-checking dependencies against NVD and OSV.
- Support period: deliver free security updates for at least 5 years, or for the expected product lifetime if shorter.
- Signed updates: distribute patches over a secure channel, with a verifiable cryptographic signature (
sigstore,cosign).
This block connects directly to the supply-chain defense discipline we cover in what is a supply chain attack.
Coordinated vulnerability disclosure
The CRA requires a coordinated vulnerability disclosure (CVD) policy and a contact point for researchers to report flaws. Concretely: publish a security.txt file (RFC 9116), align the internal process with ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling), and consider a bug bounty program. We explain the ecosystem in what is a bug bounty program.
Reporting to ENISA: 24h / 72h / 14 days
Here is the change that adds the most operational load. When a manufacturer becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting the security of the product, it must report through the single reporting platform operated by ENISA, routed to the designated coordinating CSIRT:
- Early warning within 24 hours of becoming aware.
- Vulnerability or incident notification within 72 hours, with details and any corrective or mitigating measures taken.
- Final report within 14 days of a corrective measure being available (for exploited vulnerabilities), or within 1 month for severe incidents.
The scheme echoes the NIS2 notification model, but the obliged party is the product manufacturer, not the service operator.
Application timeline
The CRA applies in stages:
| Milestone | Date |
|---|---|
| Publication in the Official Journal | 20 Nov 2024 |
| Entry into force | 10 Dec 2024 |
| Rules on notified bodies apply (Chapter IV) | 11 Jun 2026 |
| ENISA reporting obligations (Article 14) | 11 Sep 2026 |
| Full application of remaining obligations | 11 Dec 2027 |
The strategic reading: the reporting obligations arrive before the rest. From September 2026 you need the 24h/72h/14-day notification workflow in place, even though full product conformity is not enforceable until December 2027.
Penalties
The sanctioning regime in Article 64 is severe and comes in three tiers:
| Non-compliance | Maximum fine |
|---|---|
| Essential requirements (Annex I) and Article 13 and 14 obligations | 15M EUR or 2.5 percent of worldwide annual turnover, whichever is higher |
| Other obligations | 10M EUR or 2 percent |
| Incorrect or misleading information to notified bodies and surveillance authorities | 5M EUR or 1 percent |
As with NIS2, the fine is calculated on the worldwide group turnover, not only on European activity, placing the CRA in the highest sanctioning band of European digital regulation.
Manufacturer compliance checklist
- Determine scope: confirm whether your product is a product with digital elements and classify it (default, important Class I or II, critical).
- Build in security by design: threat modeling, secure default configuration, signed update channel.
- Generate the SBOM: adopt CycloneDX or SPDX and automate generation in the CI/CD pipeline.
- Stand up vulnerability handling: dependency monitoring (NVD, OSV), remediation and updates for at least 5 years.
- Publish the CVD policy:
security.txt, a security contact and a process aligned with ISO/IEC 29147 and 30111. - Prepare the reporting workflow: templates and on-call to meet 24h/72h/14 days on the ENISA platform.
- Close out conformity: technical documentation (Annex VII), EU declaration of conformity, CE marking and, for Class II and critical, a notified body.
- Document user information (Annex II): support period, how to receive updates and how to report vulnerabilities.
Frequently asked questions
What does CRA stand for and what is the Cyber Resilience Act?
CRA stands for Cyber Resilience Act, Regulation (EU) 2024/2847. It is the first European law to set mandatory cybersecurity requirements for products with digital elements (hardware and software) across their entire lifecycle, with CE marking and penalties.
When does the CRA enter into force?
It entered into force on 10 December 2024. The obligations to report exploited vulnerabilities apply from 11 September 2026 and the remaining obligations from 11 December 2027.
Does the CRA apply to open source software?
Open source software developed outside a commercial activity is largely excluded. Open source stewards who sustain projects integrated into commercial products take on lighter obligations, not the full manufacturer regime.
How does the CRA differ from NIS2?
NIS2 obliges organizations (essential and important entities) to manage the security of their networks and systems. The CRA obliges manufacturers to ensure the products they place on the market are secure and kept up to date. They are complementary frameworks that can apply at the same time.
How long must security support be provided?
The manufacturer must provide free security updates for a minimum of 5 years, unless the expected product lifetime is shorter, in which case it aligns with that lifetime.
Prepare your product for the CRA with Secra
At Secra we help manufacturers close the gap with the Cyber Resilience Act: scope analysis and classification, SBOM and vulnerability handling, design of the ENISA reporting workflow and preparation of the conformity assessment.
→ Explore our secure development and DevSecOps service
→ Talk to our GRC consulting team
Related reading
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.