The Cyber Resilience Act (CRA) is the EU's first cybersecurity law for products. From 11 December 2027, anything you sell into the EU that runs software or has a chip must ship with security built in, an SBOM, an EU Declaration of Conformity, and a vulnerability handling process that runs throughout the support period. This page explains what the law requires, when it bites, and what happens if you ignore it.
Summary
- The CRA is in force, but you have time. Regulation (EU) 2024/2847 entered into force on 10 December 2024 and applies in full from 11 December 2027.
- Reporting starts 15 months earlier. From 11 September 2026 manufacturers must report severe incidents and actively exploited vulnerabilities to ENISA and their CSIRT.
- Compliance produces four artefacts. An SBOM, an EU Declaration of Conformity, a technical file, and a documented vulnerability handling process. That set is what "CRA-ready" looks like.
- Fines are real. Up to EUR 15 000 000 or 2.5% of worldwide annual turnover, whichever is higher, for the worst breaches.
- It is not GDPR and not NIS2. The CRA regulates the cybersecurity of the product itself, not personal data and not the operational security of essential entities.
- Your obligations depend on your role and product class. Manufacturer, importer, distributor, or open-source steward; default, important Class I or II, or critical. The Who must comply page works this out step by step.
The four numbers that define the CRA: when it applies, when reporting starts, the maximum fine, and the minimum support period for security updates.
What the Cyber Resilience Act regulates
The Cyber Resilience Act, or CRA, is Regulation (EU) 2024/2847. It introduces mandatory cybersecurity requirements for products with digital elements placed on the EU market and applies to both hardware and software. Manufacturers must show their products are designed and built securely, ship with an SBOM and an EU Declaration of Conformity, and operate a vulnerability handling process throughout the support period.
The CRA is also horizontal. It cuts across product categories rather than sitting inside a single sector. Where a product is already covered by a sector-specific cybersecurity regime (medical devices, motor vehicles, civil aviation, marine equipment, or defence), the CRA carves out the overlap so the same product is not regulated twice for the same risk.
In practice, the CRA does four things:
- Rules for placing products with digital elements on the EU market
- Essential cybersecurity requirements for design, development, and production
- Vulnerability handling for as long as the product is supported
- Market surveillance and enforcement of the rules
When the CRA applies: the key dates
- Past milestone
- Upcoming enforcement
- Final deadline
- Ecosystem milestone
| Date | What applies |
|---|---|
| 10 December 2024 | The Regulation enters into force, 20 days after publication in the EU Official Journal |
| 11 June 2026 | Rules for notifying conformity assessment bodies start to apply |
| 11 September 2026 | Reporting starts. Manufacturers must report severe incidents and actively exploited vulnerabilities, including for products already on the market |
| 11 December 2027 | The Regulation applies in full to every product with digital elements placed on the EU market |
Products placed on the EU market before 11 December 2027 are not subject to the full Regulation unless, from that date, they undergo a substantial modification. The reporting duty, however, applies to all in-scope products on the market from 11 September 2026 regardless of when they were placed.
What CRA compliance looks like
Four artefacts together make a product CRA-ready. Which ones you owe depends on your role and the product's conformity class; see Who must comply with the CRA.
| Artefact | Plain-English answer |
|---|---|
| SBOM | A list of what's inside your product, in CycloneDX or SPDX, kept up to date for the support period. |
| EU Declaration of Conformity | Your signed "this product meets the rules" statement, naming the conformity route used. One per product, kept for at least ten years, or the support period if that is longer. |
| Technical file | The folder of evidence behind the Declaration: risk assessment, design and development info, vulnerability handling process, and conformity-assessment proof. |
| Vulnerability handling process | How you find, fix, and ship security updates across the whole support period: disclosure policy, triage, remediation, and free patches. |
CRA penalties and enforcement
Penalties fall into three brackets. For undertakings, the percentage-of-turnover amount applies if it is higher than the fixed EUR cap.
| Tier | Triggering breach | Maximum fine |
|---|---|---|
| Tier 1 | Non-compliance with the essential cybersecurity requirements, or with the manufacturer and reporting obligations | EUR 15 000 000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher |
| Tier 2 | Breaches of other operator and conformity duties: importer and distributor checks, CE and documentation obligations, cooperation with authorities, and notified-body rules | EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher |
| Tier 3 | Supplying incorrect, incomplete, or misleading information to notified bodies and market surveillance authorities | EUR 5 000 000 or 1% of total worldwide annual turnover, whichever is higher |
When setting the fine, market surveillance authorities must consider the nature, gravity, and duration of the infringement, repeat offences, and the operator's size, including whether it is a microenterprise, SME, or start-up. Open-source software stewards are exempt from the Tier 2 and Tier 3 fines. Beyond fines, market surveillance authorities can also order corrective action, restrict sales, recall non-compliant products, and prohibit further availability on the EU market.
For the detailed enforcement view, see CRA penalties and enforcement.
What the CRA is not
The CRA sits next to several other EU laws that also touch on cybersecurity. Three common mix-ups:
- The CRA is not GDPR. GDPR (Regulation 2016/679) protects personal data. The CRA protects the cybersecurity of the product. A product can be GDPR-relevant, CRA-relevant, both, or neither.
- The CRA is not NIS2. NIS2 (Directive 2022/2555) regulates the operational cybersecurity of essential and important entities. The CRA regulates the design and lifecycle cybersecurity of the products those entities buy and use.
- The CRA does not replace sector laws. Medical devices (MDR, IVDR), motor vehicles (Reg. 2019/2144), aviation (Reg. 2018/1139), and marine equipment (Dir. 2014/90/EU) keep their cybersecurity regimes; the CRA carves them out. The Machinery Regulation 2023/1230 and the Radio Equipment Directive overlap with the CRA in narrow ways explained in the CRA and Machinery Regulation overlap guide.
Frequently Asked Questions
When does the CRA actually apply to my product?
It depends on when the product is placed on the EU market. The full Regulation applies to any product with digital elements placed on the market from 11 December 2027 onward. Products placed before that date are not retroactively in scope unless they undergo a substantial modification after 11 December 2027, in which case they count as a new product.
What changes on 11 September 2026, before the full regime applies?
Reporting starts. From that date, manufacturers of in-scope products must report severe incidents and actively exploited vulnerabilities to ENISA and the relevant CSIRT, even for products already on the market. The rest of the Regulation does not apply yet, but the reporting duty does.
Is the CRA the same as GDPR or NIS2?
No. GDPR protects personal data. NIS2 regulates the operational security of essential and important entities (energy operators, hospitals, cloud providers, and so on). The CRA regulates the cybersecurity of the product itself: how it is designed, what vulnerabilities it ships with, and how the manufacturer handles vulnerabilities over the support period. The same company can be subject to all three at once, but the obligations sit on different objects: data, organisations, and products.
Does the CRA apply to free and open-source software?
Only when it is supplied in the course of a commercial activity. Pure non-commercial open-source projects are out of scope. Where a project is monetised (paid support, commercial distribution, embedded in a product placed on the market), the CRA applies. A lighter regime applies to open-source software stewards (foundations and similar entities that maintain open-source projects on a sustained basis), which carries some governance duties but not the full manufacturer obligations, and exempts stewards from the Tier 2 and Tier 3 fines.
What happens to products already on the market on 11 December 2027?
They keep their existing market access and are not retroactively forced through the CRA conformity assessment. A pre-existing product is only pulled into the full Regulation if, after 11 December 2027, it undergoes a substantial modification, in which case it is treated as a new product placed on the market. The reporting duty does apply to those legacy products from 11 September 2026, and security updates owed under any existing support commitment continue.
Who enforces the CRA and where do the fines come from?
Each Member State designates one or more market surveillance authorities, coordinated through the Administrative Cooperation Group (ADCO) and supported by ENISA. Authorities can request technical documentation, demand corrective action, restrict or recall non-compliant products, and impose fines. The Commission can act for products with EU-wide impact. ENISA runs the single reporting platform for severe incidents and exploited vulnerabilities.