What is the Cyber Resilience Act? A plain-language summary
On this page
The Cyber Resilience Act (CRA) is the European Union’s law on the cybersecurity of products that contain software. Its official name is Regulation (EU) 2024/2847. It requires the companies that make hardware and software products sold in the EU to design them securely, to look after their vulnerabilities for as long as the products are supported, and to report actively exploited vulnerabilities and severe incidents to the authorities.
It is a regulation, not a directive: the same text applies directly in every Member State, without national transposition.
Why the EU made it
Two problems, as the Commission put it when it proposed the law in 2022: too many connected products reach the market with weak security, and buyers cannot tell which ones are secure. Security updates were often short-lived or absent. The CRA answers both by making security a condition of selling in the EU, as electrical safety already is, and by adding the CE marking to show it.
What it covers
The CRA applies to products with digital elements: hardware and software, and their components sold separately, that connect directly or indirectly to a device or a network. That includes installable software, mobile apps, firmware, connected devices of every kind, libraries and SDKs sold on their own, and the remote data processing a product needs to work.
It does not cover:
- pure software-as-a-service, unless it is the back end of a product;
- free and open-source software developed or supplied outside a commercial activity;
- products already covered by their own EU rules: medical devices and in vitro diagnostic medical devices, motor vehicles, civil aviation, marine equipment;
- products made only for national security or defence, or to process classified information.
Our guide Does the CRA apply to your product? walks through each test.
Who must do what
Manufacturers carry most of the weight (Article 13). When they place a product on the market, and for its support period, they must:
- assess its cybersecurity risks and design it to meet the essential requirements of Annex I;
- handle its vulnerabilities for the support period, normally at least five years, with free security updates;
- draw up the technical documentation (Annex VII), including a software bill of materials;
- carry out the right conformity assessment, sign an EU declaration of conformity and affix the CE marking;
- give users clear information: a contact point for vulnerabilities, the end date of support, instructions for secure use.
Importers and distributors check that the products they sell meet those obligations, and stop selling them when they do not. An importer or distributor that sells a product under its own name or trademark, or anyone who substantially modifies it, becomes its manufacturer.
Open-source software stewards, the foundations and organisations that support open-source projects meant for commercial use, have a lighter regime of their own: a cybersecurity policy, cooperation with authorities and some reporting duties.
The essential requirements
Annex I is the heart of the regulation. Part I lists the security properties of the product: no known exploitable vulnerabilities at release, a secure default configuration, security updates, access control, encryption, integrity, data minimisation, resilience, a limited attack surface, logging, and a way for users to delete their data. Part II lists the vulnerability handling process: an SBOM, prompt fixes, regular testing, public advisories, a coordinated disclosure policy, a contact address and secure update distribution.
We go through each one in Annex I requirements, one by one.
Classes of products
Most products are in the default category and their maker assesses conformity alone. Products whose failure would have wider effects are listed as important (class I or II, Annex III) or critical (Annex IV): operating systems, browsers, password managers, VPNs, routers, smart locks and security cameras are class I; firewalls, hypervisors and tamper-resistant chips are class II; smartcards and smart meter gateways are critical. The higher the class, the more a third party, a notified body, is involved.
Reporting to ENISA
Since 11 September 2026, manufacturers must report two kinds of events, at the same time to the national CSIRT designated as coordinator and to ENISA, through ENISA’s Single Reporting Platform: actively exploited vulnerabilities in their products and severe incidents affecting their security. The clock is tight: an early warning within 24 hours, a notification within 72 hours, and a final report later. This duty already covers every product on the market, not only new ones. See the reporting clock.
Key dates
- 10 December 2024: the CRA enters into force.
- 11 June 2026: rules on notified bodies apply.
- 11 September 2026: reporting obligations apply.
- 11 December 2027: everything else applies, including the essential requirements and the CE marking.
The full calendar, with the transition rules for products already sold, is in our CRA timeline.
Fines
Each Member State enforces the CRA through its market surveillance authority, which can also order products withdrawn or recalled. The regulation sets the maximum fines:
| Breach | Maximum fine |
|---|---|
| Essential requirements, manufacturer obligations and reporting | €15 million or 2.5% of worldwide annual turnover |
| Other obligations (importers, distributors, CE marking, declaration…) | €10 million or 2% of worldwide annual turnover |
| Incorrect, incomplete or misleading information to notified bodies or market surveillance authorities | €5 million or 1% of worldwide annual turnover |
In each case, the higher amount applies. Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning alone, and open-source software stewards cannot be fined at all.
How the CRA fits with other laws
The CRA is about products. The NIS2 Directive is about the organisations that run essential and important services: it governs how they secure their own networks and report incidents. A company can be under both: the CRA for what it sells, NIS2 for how it operates. Wireless devices already face cybersecurity requirements under a delegated act of the Radio Equipment Directive, applied since August 2025; the Commission is expected to repeal or narrow that act for the products the CRA covers.
Where to start
- List your products and check whether the CRA applies to each one, and in which class.
- Get ready to report now: know your components, watch them for exploited vulnerabilities, rehearse the 24-hour early warning.
- Publish a vulnerability disclosure policy and a security.txt contact point.
- Build the technical file release after release, starting with an SBOM.
How Provetry helps
Provetry builds the SBOM of each release, watches every component for new and exploited vulnerabilities, starts the reporting clock with drafts for ENISA, writes your disclosure policy and keeps the evidence and documentation the CRA asks for.
This guide is general information, not legal advice.
Sources
- Regulation (EU) 2024/2847, the Cyber Resilience Act, Articles 2, 3, 13, 14, 19, 20, 21, 22, 24, 64, 69 and 71, Annexes I, III, IV and VII
- European Commission: Cyber Resilience Act
- ENISA: Single Reporting Platform