EU Cyber Resilience Act (Regulation (EU) 2024/2847)
The Cyber Resilience Act is EU product law for anything with digital elements, hardware, embedded devices, and software placed on the EU market. It works like CE marking for safety, applied to cybersecurity. The manufacturer designs the product against the essential requirements, runs a documented vulnerability handling process for a defined support period, compiles a technical file, carries out a conformity assessment, draws up an EU declaration of conformity, and affixes the CE mark.
It entered into force on 10 December 2024 and applies in full from 11 December 2027, with two earlier milestones. The notified-body rules apply from 11 June 2026, and the obligation to report actively exploited vulnerabilities and severe incidents applies from 11 September 2026. Anyone who places a product on the market under their own name or trademark, or who substantially modifies one, is the manufacturer for these purposes, which catches many companies that consider themselves resellers or integrators. Penalties for breaching the essential requirements reach EUR 15 million or 2.5 percent of worldwide annual turnover.
What the regulation asks for
Every requirement of the Cyber Resilience Act, grouped the way the regulation groups them and tagged with its legal reference. Annex I Part I and Part II are 14 and 8 of them, the security properties and the vulnerability-handling process. The Annex I text is reproduced from Regulation (EU) 2024/2847.
Scope, roles, product classes and dates
5 requirementsWhere the regulation starts. Whether it applies to your product, which class the product falls in, and which economic operator you are.
| Art. 2 | Determine whether your product is in scope |
| Art. 71 | Work to the application dates with a dated readiness plan |
| Annex III / IV | Classify each product across the default, important and critical tiers |
| Chapter II | Establish your economic operator role, including when you become the manufacturer |
| Art. 24 | Open-source stewards and the commercial-activity boundary |
Essential cybersecurity requirements (Annex I, Part I)
14 requirementsThe security properties every in-scope product designs for, on the basis of the Article 13(2) risk assessment.
| I (1) | Appropriate level of cybersecurity based on the risks |
| I (2)(a) | No known exploitable vulnerabilities |
| I (2)(b) | Secure by default |
| I (2)(c) | Security updates |
| I (2)(d) | Protection from unauthorised access |
| I (2)(e) | Confidentiality of data |
| I (2)(f) | Integrity of data |
| I (2)(g) | Data minimisation |
| I (2)(h) | Availability of essential functions |
| I (2)(i) | Minimise impact on other devices |
| I (2)(j) | Limit attack surfaces |
| I (2)(k) | Reduce impact of incidents |
| I (2)(l) | Security-relevant logging |
| I (2)(m) | Secure data deletion / portability |
Vulnerability handling (Annex I, Part II)
8 requirementsThe process obligations that run for the whole support period, always applicable in full.
| II (1) | Identify & document vulnerabilities and components (SBOM) |
| II (2) | Address & remediate without delay |
| II (3) | Regular security testing & reviews |
| II (4) | Public disclosure of fixed vulnerabilities |
| II (5) | Coordinated vulnerability disclosure policy |
| II (6) | Facilitate vulnerability information sharing |
| II (7) | Secure update distribution |
| II (8) | Timely, free security patches |
Third-party and open-source components
2 requirementsWhat you owe for the components you integrate, both before you ship and after a vulnerability surfaces upstream.
| Art. 13 | Due diligence on integrated third-party components |
| Art. 13 | Report vulnerabilities upstream and share your fixes |
Conformity assessment, CE marking and documentation
5 requirementsHow you demonstrate conformity, write it down, and earn the mark that lets the product onto the market.
| Art. 32 | Choose and complete the right conformity assessment procedure |
| Art. 27 | Use harmonised standards for presumption of conformity |
| Art. 31 / Annex VII | Technical documentation, drawn up before placing on the market |
| Art. 28-30 | EU declaration of conformity and CE marking |
| Annex II | Information and instructions for the user |
Reporting exploited vulnerabilities and severe incidents
3 requirementsThe clocks that start the moment something is actively exploited, live from 11 September 2026.
| Art. 14(1)-(2) | Report actively exploited vulnerabilities, 24h then 72h then 14 days |
| Art. 14(3)-(4) | Report severe incidents affecting product security, 24h then 72h then one month |
| Art. 14(8) | Inform your users about the vulnerability or incident |
The documents you end up with, and where the portal produces them
The 16 deliverables the Cyber Resilience Act leaves you holding. The ones marked in-product are produced, hosted or verified inside CVD Portal. Underneath them the platform tracks 36 technical-file artifacts across 7 product areas, so a document is a view over evidence rather than a file you keep in sync by hand.
Product Scope and Classification Record
You authorFor each product you place on the market, whether the CRA applies, which class it falls in, and which economic operator role you hold.
CRA Readiness Plan
In-productA dated plan to the reporting obligations and the main application date, with an owner on every gap.
Product Cybersecurity Risk Assessment
You authorThe Article 13(2) analysis of what can go wrong in real use, which drives every design decision that follows.
Technical Documentation File
In-productThe Annex VII dossier a market surveillance authority can demand, assembled and exportable on request.
Essential Requirements Conformance Matrix
In-productRequirement by requirement, how the product meets each Annex I property and where the evidence for it lives.
Software Bill of Materials
In-productThe machine-readable component list, so a newly disclosed component vulnerability is traced to your product in minutes.
Vulnerability Handling Policy
In-productHow vulnerabilities are found, triaged, fixed and shipped, with security updates free of charge and separate from features.
Coordinated Vulnerability Disclosure Policy
In-productThe public page telling a researcher where to send a finding and what you commit to, plus the contact address you monitor.
Security Advisory Process
In-productHow you publish what was fixed and how severe it was, in machine-readable CSAF, and reach users directly when it is urgent.
Third-Party Component Due Diligence Record
You authorWhat you checked before integrating each third-party or open-source component, and what you do when a maintainer goes quiet.
Support Period Statement
You authorThe end date after which security updates stop, how you arrived at it, and where a buyer can read it before purchase.
Conformity Assessment Record
You authorWhich assessment route the product took, which harmonised standards you relied on, and any notified-body involvement.
EU Declaration of Conformity
In-productThe signed one-page statement that the product meets the regulation, which is what lets the CE mark go on.
Information and Instructions for the User
In-productThe Annex II manual covering secure install and run, the secure defaults, how to reset, and where updates come from.
Vulnerability and Incident Reporting Procedure
In-productThe 24-hour, 72-hour and follow-up clocks for telling your CSIRT and ENISA, and who is allowed to file.
Open-Source Steward Cybersecurity Policy
You authorIf you steward open-source software commercially, how you support secure development and handle vulnerabilities in the project.
The CRA asks for a running vulnerability handling process
Most CRA tools hand you a coordinated disclosure template and a checklist. The regulation asks for a running process. A place a researcher actually reports to, a contact you actually monitor, advisories you actually publish, and a report you actually file when something is exploited. CVD Portal runs that machinery.
- PortalA whitelabel submission portal on your own subdomain where researchers file reports, with an RFC 9116 security.txt advertising the contact you commit to.
- Article 14A reporting engine that runs the 24-hour, 72-hour and 14-day clocks to your CSIRT and ENISA, with the exploitation evidence that tells you whether the actively-exploited trigger has fired.
- AdvisoriesMachine-readable CSAF advisories and a technical file that maps to the draft harmonised EN 40000-1-3 vulnerability-handling clauses.
Bring in a certified CRA consultant
Some manufacturers would rather not work the risk assessment or the conformity route out alone. Independent consultancies in the partner directory deliver CRA work on the platform, and the partner academy certifies them against the same requirements shown above. We are not a consultancy, the partners are.
Take the Cyber Resilience Act from classification to a filed Article 14 report
Classify each product, work the essential requirements, assemble the technical file, and run the vulnerability handling process in one place.