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 (Article 71(2)).
- Reporting starts 15 months earlier. From 11 September 2026 manufacturers must report severe incidents and actively exploited vulnerabilities to ENISA and their CSIRT (Article 14).
- Compliance produces four artefacts. An SBOM, an EU Declaration of Conformity, an Annex VII 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 (Article 64(2)).
- 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 next page sorts that.
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 CRA is Regulation (EU) 2024/2847. Article 1 covers four areas:
| What the CRA covers | Where it lives in the Regulation |
|---|---|
| Rules for placing products with digital elements on the EU market | Chapter I, Articles 1 to 7 |
| Essential cybersecurity requirements for design, development, and production | Annex I Part I, with manufacturer obligations in Article 13 |
| Vulnerability handling for as long as the product is supported | Annex I Part II, Article 13(8), and Article 14 |
| Market surveillance and enforcement of the rules | Chapter VII, Articles 52 to 66 |
In practice, the CRA introduces a CE-marking regime for cybersecurity. A product with digital elements (hardware, software, or a remote data-processing component supplied by the manufacturer) cannot be placed on the EU market unless the manufacturer can show it meets Annex I and runs a vulnerability handling process for the full support period.
The CRA is 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), Article 2 carves out the overlap so the same product is not regulated twice for the same risk.
When the CRA applies: the key dates
| Date | What applies | Source |
|---|---|---|
| 10 December 2024 | Regulation enters into force (twentieth day after OJ publication) | Article 71(1) |
| 11 June 2026 | Chapter IV (Articles 35 to 51) on notification of conformity assessment bodies applies | Article 71(2) |
| 11 September 2026 | Article 14 reporting obligations apply to severe incidents and actively exploited vulnerabilities, including for products already on the market | Articles 71(2) and 69(3) |
| 11 December 2027 | Regulation applies in full to all products with digital elements placed on the EU market from this date | Article 71(2) |
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 (Article 69(2)). The Article 14 reporting duty, however, applies to all in-scope products on the market from 11 September 2026 regardless of when they were placed (Article 69(3)).
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 | Where it's required |
|---|---|---|
| SBOM (details) | A list of what's inside your product, in CycloneDX or SPDX, kept up to date for the support period. | Annex I Part I |
| EU Declaration of Conformity (details) | Your signed "this product meets the rules" statement, naming the conformity route used. One per product, kept for ten years. | Article 28, Annex V |
| Annex VII technical file (details) | The folder of evidence behind the Declaration: risk assessment, design and development info, vulnerability handling process, and conformity-assessment proof. | Annex VII |
| Vulnerability handling process (details) | How you find, fix, and ship security updates across the whole support period: disclosure policy, triage, remediation, and free patches. | Annex I Part II |
Penalties under Article 64
Article 64 sets three fine brackets. The higher of the absolute cap or the percentage of worldwide turnover applies.
| Tier | Triggering breach | Maximum fine |
|---|---|---|
| Tier 1 | Non-compliance with the Annex I essential cybersecurity requirements, or with the obligations in Articles 13 and 14 | EUR 15 000 000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher |
| Tier 2 | Non-compliance with the obligations in Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3), 33(5), 39, 41, 47, 49, and 53 | 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 |
Market surveillance authorities take into account the nature, gravity, and duration of the infringement, repeat offences, and the size of the operator, and apply lighter scrutiny to microenterprises, small enterprises, and start-ups (Article 64(5) and 64(10)). Open-source software stewards are exempt from the Tier 2 and Tier 3 fines (Article 64(10)(b)). Beyond fines, market surveillance authorities can also order corrective action, restrict sales, recall non-compliant products, and prohibit further availability on the EU market (Article 54).
Official sources
For the regulation text and the European Commission's policy page, see:
- Full text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- European Commission CRA policy page: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
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. 2018/858), aviation (Reg. 2018/1139), and marine equipment (Dir. 2014/90/EU) keep their cybersecurity regimes; the CRA carves them out at Article 2. 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 (Articles 71(2) and 69(2)).
What changes on 11 September 2026, before the full regime applies?
Article 14 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 (Article 69(3)).
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. Article 24 creates a lighter regime for 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 (Articles 2(2) and 24; fine exemption at Article 64(10)(b)).
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 (Article 69(2); reporting duty at Article 69(3)).
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 the Article 64 fines. The Commission can act for products with EU-wide impact. ENISA runs the single reporting platform for Article 14 incidents and vulnerabilities.