CRA
CRA — Regulation (EU) 2024/2847
The Cyber Resilience Act binds anyone placing software or connected hardware on the EU market: an SBOM, a declared support period, actively exploited vulnerabilities reported within 24 hours, and CE marking.
- Who it applies to
- Manufacturers, importers and distributors placing or making available on the Union market products with digital elements — any software or hardware product whose intended use includes a direct or indirect data connection to a device or network. Conformity assessment obligations vary depending on whether the product is default, important (Annex III, classes I and II) or critical (Annex IV). Products already covered by specific sectoral law, and free and open-source software developed outside a commercial activity, are among the exclusions.
- Deadline
- Fully applicable from 11 December 2027. Article 14, which imposes reporting of actively exploited vulnerabilities and severe incidents, applies earlier: from 11 September 2026. Chapter IV, on notified bodies, from 11 June 2026.
- Official reference
- Regulation (EU) 2024/2847 of 23 October 2024
Why the CRA looks more like CE marking than like NIS2
Regulation (EU) 2024/2847 does not regulate how you protect your organisation; it regulates what you are allowed to sell. It is product legislation, of the same lineage as the rules that put a CE mark on a toy or a washing machine. The practical consequence is that non-compliance is not paid only in fines: it is paid in the market surveillance authority pulling your product.
That changes who owns the project internally. Under NIS2 or DORA the file sits with security or compliance. Under the CRA it sits with product engineering, because nearly every obligation resolves inside the development cycle: SBOM, vulnerability handling, signed updates, disclosure policy.
The staggered timetable matters more than it looks
The regulation entered into force on 10 December 2024 but applies in tranches. Chapter IV, governing notified bodies, from 11 June 2026. Article 14, imposing reporting of actively exploited vulnerabilities and severe incidents, from 11 September 2026. Everything else from 11 December 2027.
That order is deliberate and has an operational reading: the first obligation to reach you is not to build better, it is to tell people what happened to you. Before anyone demands a complete technical file, you already need to be able to detect active exploitation and report it within 24 hours through a formal channel.
Three product categories, three levels of proof
Annex III lists important products in two classes — password managers, antivirus, VPNs, operating systems, microprocessors with security-related functionality and several dozen more — and Annex IV lists critical products. The higher up that ladder, the less room for self-assessment and the more weight an independent third party carries. Working out which category your product falls into is the first decision of the project, because it changes the cost and the timeline of conformity entirely.
What non-compliance costs
Article 64(2) sets administrative fines of up to EUR 15 million or, for an undertaking, up to 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher, for breaching the essential requirements in Annex I and the obligations in Articles 13 and 14. Other breaches drop to EUR 10 million or 2 %, and supplying incorrect, incomplete or misleading information to a notified body or market surveillance authority to EUR 5 million or 1 %. Article 64(10) moderates how the fines apply to microenterprises and small enterprises in certain cases.
Obligations
-
Design to the essential requirements in Annex I
Article 13(1) requires the product to have been designed, developed and produced in accordance with the essential cybersecurity requirements in Part I of Annex I. This is not a checklist you satisfy at the end: the obligation attaches to the development process, which is why the evidence looks backwards, at design decisions already taken.
Evidence required
The Annex VII technical documentation setting out, requirement by requirement, how each is implemented and — where one does not apply — the clear justification for why it does not, as Article 13(4) demands.
-
Document a cybersecurity risk assessment and keep it alive
Article 13(2) to (4) requires a cybersecurity risk assessment of the product, taken into account across planning, design, development, production, delivery and maintenance, documented, updated throughout the support period, and included in the technical documentation. The assessment must state whether the security requirements in Part I, point (2) of Annex I apply and how they are implemented.
Evidence required
The assessment document with version, date and author, tied to the specific product version, plus the history showing it was updated after material changes and not only at first release.
-
Maintain a machine-readable SBOM
Point 1 of Part II of Annex I requires identifying and documenting the vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies. Article 13(25) additionally allows market surveillance authorities to request the SBOM as part of Union-wide dependency assessments.
Evidence required
The SBOM file in a commonly used format, with a generation date and unambiguous traceability to the shipped product version. An SBOM hand-assembled in a spreadsheet does not satisfy the machine-readable requirement.
-
Exercise due diligence on third-party components and report upstream
Article 13(5) requires due diligence when integrating third-party components, including free and open-source components not made available on the market. Article 13(6) adds a less well-known duty: on identifying a vulnerability in an integrated component, the manufacturer must report it to the person or entity manufacturing or maintaining that component, remediate it in its own product, and — where it has developed a modification that fixes it — share the relevant code or documentation with the maintainer, where appropriate in machine-readable form.
Evidence required
A record of communications to the component maintainer with date and content — a public issue, an archived email or a pull request — alongside the documented due diligence criterion applied before integrating the component.
-
Publish a coordinated vulnerability disclosure policy and a single point of contact
Points 5 and 6 of Part II of Annex I require putting in place and enforcing a coordinated vulnerability disclosure policy and providing a contact address for reporting vulnerabilities. Article 13(17) requires designating a single point of contact allowing users to communicate directly and rapidly with the manufacturer, and Annex II requires that contact to appear in the information accompanying the product.
Evidence required
The policy published at a stable URL, with a version date and committed response times, and the intake record proving the channel is alive: date received, acknowledgement, and resolution date for each report.
-
Report actively exploited vulnerabilities and severe incidents
Article 14 imposes two parallel sequences to the CSIRT designated as coordinator and to ENISA, through the single reporting platform in Article 16. For an actively exploited vulnerability: early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident affecting the security of the product: early warning within 24 hours, incident notification within 72 hours, and a final report within one month of that notification. The CSIRT may also request intermediate reports.
Evidence required
Time-stamped acknowledgements from the single reporting platform for each milestone, plus the internal record of the moment of "becoming aware" and — for a vulnerability — of the date the fix became available, which is what opens the 14-day window.
-
Determine, justify and publish the support period
Article 13(8) requires determining a support period reflecting how long the product is expected to be in use, with a floor of five years unless the expected use time is shorter. The information used to determine it goes into the technical documentation. Article 13(19) requires the end date of the support period, at least month and year, to be clearly and accessibly specified at the time of purchase. Article 13(9) requires each security update to remain available for at least 10 years after it was issued, or for the remainder of the support period if that is longer.
Evidence required
Documentary proof of where the end-of-support date appears at point of sale, on packaging or by digital means, together with the file justifying how the period was calculated against the criteria in Article 13(8).
-
Follow the conformity assessment route for your product class
Article 32 grades the burden. A default product may use internal production control (module A). An important product in Annex III class I may self-assess only if it fully applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least 'substantial'; otherwise it moves to EU-type examination (modules B and C) or full quality assurance (module H). A class II important product must use a notified body route or a European scheme at assurance level at least 'substantial'. Critical products in Annex IV require a European certification scheme where the conditions in Article 8(1) are met.
Evidence required
The EU declaration of conformity and, where the route requires it, the notified body or European scheme certificate, with the product scope and version identified. If you rely on harmonised standards to avoid a notified body, the evidence is the analysis showing you applied them in full.