Skip to content

EU Cyber Resilience Act — CRA (Reg. (EU) 2024/2847)

Provenance & licence

Source: EUR-Lex ELI permalink · Last observed: 2026-09-21 · Version: Reg. (EU) 2024/2847 — in force 2024-12-10; Art. 14 reporting applies since 2026-09-11; full application 2027-12-11 · Status: planned · Licence: © European Union (EUR-Lex), Decision 2011/833/EU (open-attribution)

Summary

The Cyber Resilience Act (Regulation (EU) 2024/2847) is a binding EU regulation that makes cybersecurity a condition of market access for products with digital elements — hardware and software whose intended or reasonably foreseeable use includes a direct or indirect data connection. It entered into force on 10 December 2024 and applies in stages: the reporting obligations of manufacturers (Art. 14) since 11 September 2026, the notified-body chapter since 11 June 2026, and everything else — essential cybersecurity requirements, conformity assessment, CE marking, the support period — from 11 December 2027. For an AI risk auditor it matters twice: AI software shipped as a product is in scope like any other software, and Art. 12 ties the CRA directly to the AI Act — a high-risk AI system that is also a product with digital elements meets the AI Act's cybersecurity duty (Art. 15(1)) by meeting the CRA's essential requirements, assessed in one procedure. It is the one instrument in this library whose evidence lives in the code, the build pipeline and the release process rather than in policy documents.

In plain language

Our explanation, not the official text

Plain-language summary in our own words. EU legal text is reusable with attribution (EUR-Lex, Decision 2011/833/EU). Not legal advice.

The CRA is the EU's product-safety law for anything with software in it. If you sell software or connected hardware in the EU — an app, a CMS, a model served as a product, a router, an industrial controller — you must build it securely, keep fixing it for years, and, since 11 September 2026, tell the authorities within 24 hours when you learn that a flaw is being actively exploited or that a serious security incident has hit the product. Reports go through one ENISA-run platform to the national CSIRT where your main EU establishment sits. From December 2027 the product also needs a CE mark that attests to its cybersecurity. Open-source software given away outside a commercial activity is largely out of scope; open-source stewards have their own, lighter duties from December 2027.

Key terms

  • Product with digital elements — software or hardware (incl. remote data-processing solutions) with a direct or indirect data connection to a device or network (Art. 3(1)).
  • Actively exploited vulnerability — a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Art. 3(42)); the reporting trigger, not CVE assignment.
  • Severe incident — an incident that affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive data or functions, or that leads to malicious code being introduced or executed (Art. 14(5)).
  • Single Reporting Platform (SRP) — the ENISA-operated platform with national CSIRT endpoints through which Art. 14 notifications are submitted (Art. 16).
  • Support period — the time during which the manufacturer must handle vulnerabilities; at least five years unless the product's expected use is shorter (Art. 13(8)).
  • Important / critical products — the Annex III (Class I and II) and Annex IV product categories with stricter conformity-assessment routes.
  • Open-source software steward — a legal person that supports the development of free and open-source software intended for commercial use, with a light-touch regime (Art. 24).

In depth: what the CRA is actually for

Reading guide: the boxed “Source text” is the CRA's own wording (verbatim; EU law, reusable under EUR-Lex Decision 2011/833/EU with source acknowledgement). Text marked “In our words” is our explanation.

Source text — CRA, Art. 12(1) (© European Union, EUR-Lex)

Without prejudice to the requirements relating to accuracy and robustness set out in Article 15 of Regulation (EU) 2024/1689, products with digital elements which fall within the scope of this Regulation and which are classified as high-risk AI systems pursuant to Article 6 of that Regulation shall be deemed to comply with the cybersecurity requirements set out in Article 15 of that Regulation where: (a) those products fulfil the essential cybersecurity requirements set out in Part I of Annex I; (b) the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Part II of Annex I; and (c) the achievement of the level of cybersecurity protection required under Article 15 of Regulation (EU) 2024/1689 is demonstrated in the EU declaration of conformity issued under this Regulation.

In our words — the CRA does two jobs. First, it is a horizontal product-security law: every product with digital elements must be designed, developed and maintained under the essential requirements of Annex I — secure-by-default configuration, no known exploitable vulnerabilities at release, a software bill of materials, coordinated vulnerability disclosure, security updates for the whole support period. Second, and this is the part an AI auditor needs, Art. 12 is the missing definition of “cybersecurity” in the AI Act: the AI Act's Art. 15 says a high-risk system must be resilient to attacks but never says what that means in engineering terms; the CRA's Annex I does. For a high-risk AI system that is also a product with digital elements, meeting Annex I — Part I for the product, Part II for the manufacturer's processes — and saying so in the EU declaration of conformity means meeting Art. 15(1) AI Act, and the conformity assessment runs once, under the AI Act's Art. 43 procedure, with the notified body checking the CRA requirements alongside (Art. 12(2)). The exception: important and critical products listed in CRA Annexes III and IV keep the CRA's own conformity routes for the cybersecurity part (Art. 12(3)). Accuracy and robustness stay with the AI Act.

The reporting regime that went live on 11 September 2026 is deliberately narrow: it is triggered by active exploitation or a severe incident, not by every discovered weakness. A finding from an internal code review, a researcher's report or a lab proof-of-concept does not by itself start the 24-hour clock; reliable evidence of malicious use does — and that evidence may come from telemetry, customers, incident responders or a national authority. Supply-chain compromises count: the regulation's own example of a severe incident is malicious code injected into the channel a manufacturer uses to distribute security updates.

Why this page exists in an AI-governance library

Of all the instruments tracked here, the CRA is the one whose evidence an auditor cannot obtain from documentation alone. Whether a product has a current SBOM, whether known vulnerabilities were fixed before release, whether the build and update channel are protected, whether affected versions and EU distribution can be identified inside 24 hours — these are facts of the code base and the release pipeline. That is exactly the audit performed on the source code, not only on the documentation discipline this library supports.

Application timeline (as it stands)

Date What applies
2024-12-10 Entry into force (Art. 71).
2026-06-11 Chapter IV — notification of conformity assessment bodies (Arts. 35–51) — applies, so notified bodies can be designated ahead of full application.
2026-09-11 Art. 14 reporting obligations of manufacturers apply; the ENISA Single Reporting Platform launched the same day.
2027-12-11 Full application: essential requirements (Annex I), manufacturer obligations (Art. 13), conformity assessment (Art. 32) and CE marking (Art. 30), importer and distributor duties, market surveillance and penalties (Art. 64); open-source steward reporting under Art. 24(3).
2028-09-11 Commission assessment of the single reporting platform's effectiveness, after consulting ENISA and the CSIRTs network (Art. 70).

Key Sections

  • Scope and definitions — what a product with digital elements is, and what is carved out (products already covered by sectoral rules such as medical devices, aviation, vehicles; non-commercial open-source software) (Arts. 2–3).
  • Important and critical products — the Annex III Class I/II and Annex IV categories with stricter conformity routes: Class I may stay in internal control only when it fully applies harmonised standards or a certification scheme, Class II and critical products need a notified body or a European cybersecurity certificate (Art. 32(2)–(3)) (Arts. 7–8).
  • High-risk AI systems — the presumption of conformity with AI Act Art. 15(1) and the single conformity procedure (Art. 12).
  • Obligations of manufacturers — cybersecurity risk assessment, essential requirements, vulnerability handling, SBOM, support period of at least five years, technical documentation, user information (Art. 13).
  • Reporting obligations of manufacturers — actively exploited vulnerabilities and severe incidents; 24 h / 72 h / final report; the duty to inform users (Art. 14).
  • Single reporting platform — ENISA-run, with national CSIRT endpoints; rules for withholding sensitive details and for onward dissemination (Art. 16).
  • Open-source software stewards — the light-touch regime (Art. 24).
  • Conformity assessment and CE marking — self-assessment, notified-body routes, harmonised standards and certification schemes (Arts. 27–32).
  • Penalties — up to EUR 15 million or 2.5 % of worldwide annual turnover for breaches of Annex I and Arts. 13–14 (Art. 64).
  • Essential cybersecurity requirements — Part I (product properties) and Part II (vulnerability handling) (Annex I).

Audit-Relevant Anchors

  • Art. 12 (high-risk AI systems) — the bridge to the EU AI Act: for a high-risk AI product, the CRA's Annex I (Part I product properties, Part II vulnerability-handling processes) is the concrete test behind the AI Act's cybersecurity duty, the EU declaration of conformity must say so, and the two assessments are one.
  • Art. 14 (reporting obligations) — the live obligation since 2026-09-11: an auditor checks that the detection-to-submission path works inside 24 hours, not that a policy exists.
  • Art. 14(8) (informing users) — turns the customer and version inventory into compliance evidence: a manufacturer that cannot say who runs which version cannot meet it.
  • Art. 16 (single reporting platform) — where the notification goes, which CSIRT is competent (main EU establishment, Art. 14(7)), and how sensitive details can be withheld for a limited time.
  • Art. 13(8) (support period) + Annex I Part II (vulnerability handling incl. SBOM) — the lifecycle evidence: SBOM, disclosure policy, update channel integrity, the promised support horizon.
  • Annexes III and IV (important and critical products) — whether the product's category forces a notified body or a certificate, which also decides the Art. 12(3) exception for AI products.
  • Art. 64 (penalties) — the exposure a late or missing Art. 14 notification creates from 2026-09-11, and the full manufacturer-obligation exposure from 2027-12-11.
  • Overlapping reporting regimes — the auditor's decision matrix: which duty, to whom, on which clock. See also the DORA and EU AI Act pages.

Auditor Checklist

Evidence-oriented checks for a manufacturer of software or connected products — including AI software shipped as a product — with EU market presence:

  • The product portfolio is classified: in scope / out of scope, Annex III Class I or II, Annex IV, and whether any product is also a high-risk AI system (Art. 12).
  • The main EU establishment — and therefore the coordinator CSIRT — is determined and documented (Art. 14(7)).
  • An operational Art. 14 path exists: agreed criteria for "actively exploited" and "severe incident", authority to submit an early warning on incomplete evidence, SRP account and endpoint verified, tabletop-tested against the 24-hour window.
  • Product, version and EU-distribution records allow affected users and Member States to be identified quickly; user notifications can be issued in human-readable and machine-readable form (Art. 14(8)).
  • Contracts with cloud providers, component suppliers, managed security and vulnerability-research partners deliver exploitation evidence fast enough to support the statutory clock.
  • Parallel duties are mapped per event type: NIS2, DORA, GDPR Art. 33, AI Act Art. 73 — one decision matrix, not four separate procedures.
  • Ahead of 2027-12-11: a documented cybersecurity risk assessment, an SBOM per product, a coordinated vulnerability-disclosure policy, a protected build and update channel, and a stated support period of at least five years (Art. 13, Annex I).
  • For a high-risk AI product: the AI Act Art. 43 conformity file evidences CRA Annex I Parts I and II and the EU declaration of conformity states the Art. 15 protection level, or the Annex III/IV route is followed instead (Art. 12(1)–(3)).

Cross-Framework Mapping

Indicative cross-references, not authoritative equivalences.

CRA EU AI Act NIST (CSF / AI RMF / SSDF) DORA
Art. 12 (high-risk AI systems) Art. 15 (cybersecurity) + Art. 43 (conformity assessment) AI RMF MEASURE —
Art. 13 + Annex I Part I (secure design) Art. 9 (risk management) + Art. 15 SSDF (SP 800-218) · CSF Protect Art. 5–16 (ICT risk management)
Art. 14 (reporting) Art. 73 (serious-incident reporting) CSF Respond Art. 17–23 (incident reporting)
Annex I Part II (vulnerability handling, SBOM) Art. 72 (post-market monitoring) SSDF RV (respond to vulnerabilities) · AI RMF MANAGE Art. 24–27 (resilience testing)
Art. 13(8) (support period) + Art. 24 (OSS stewards) Art. 25 (value-chain responsibilities) AI RMF MAP 4 (supply chain) Art. 28–30 (ICT third-party risk)

Recent Changes (rolling, last 5)

Date Severity What changed
2026-09-21 baseline Initial baseline, added ten days after the Art. 14 reporting obligations became applicable on 2026-09-11 and ENISA launched the Single Reporting Platform with initial operating capability the same day (FAQ, user manuals, factsheet, help desk). Captured: scope, the Art. 12 bridge to the AI Act's Art. 15/43, the staged timeline to full application on 2027-12-11 (open-source steward reporting from that date under Art. 24(3)), penalties, and the overlap with NIS2, DORA, GDPR and AI Act Art. 73 reporting. Commission review of the platform due by 2028-09-11.

Sources

Public web sources only — local/private provenance is kept in a private mirror.