Regulation (EU) 2024/2847, and the Article 12 Trap
The one-paragraph answer
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s product cybersecurity law. It applies to almost any hardware or software with a data connection placed on the EU market. Vulnerability and incident reporting bites on 11 September 2026, and it reaches products already on the market. Full obligations follow on 11 December 2027. Penalties run to €15 million or 2.5 percent of worldwide turnover. And it contains a provision, Article 12, that offers high-risk AI systems a route to deemed compliance with the EU AI Act’s Article 15. That route is narrower than nearly every summary of it admits, and misreading it is an expensive mistake.
Two dates, and almost every organisation is planning for the wrong one.
Ask a product security team when the EU Cyber Resilience Act lands and they will say December 2027. That is the date in the headlines, the date on the slide, the date the roadmap is built around. It is thirty-six months of transition and it feels comfortably distant.
The date that actually bites first is 11 September 2026. From that day, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. And here is the part that catches people: that duty reaches products already on the EU market. Not just what you ship after the date. What you shipped before it, and is still out there.
An organisation that cannot enumerate its products, identify their components, and detect exploitation inside a 24-hour window does not have a 2027 problem. It has a right-now problem, and the runway is measured in weeks.
The EU Cyber Resilience Act is product law, not AI law, and that framing matters. It entered into force on 10 December 2024 as the first horizontal EU regulation imposing binding cybersecurity requirements on “products with digital elements” across the whole lifecycle, from design through decommissioning.
A “product with digital elements” is, in practice, almost any hardware or software that connects directly or indirectly to a device or a network. If it contains software or firmware and it talks to something, assume it is in scope until you have written down why it is not. Sector-specific carve-outs exist (medical devices, vehicles, aviation), and open-source software developed outside a commercial activity is excluded, though a new “open-source software steward” category carries a lighter regime. The moment a company integrates open source into a product it places on the market, it becomes the manufacturer and inherits the obligations for what it ships.
Default products self-assess. Important products (Annex III, Class I and Class II) need harmonised standards or a notified body. Critical products (Annex IV) require mandatory certification. Classification follows the product’s core function, and where more than one class fits, the stricter one applies. Commission Implementing Regulation (EU) 2025/2392, adopted 28 November 2025, supplies the technical descriptions of the important and critical categories.
Meet the essential cybersecurity requirements in Annex I Part I (the product) and Part II (the manufacturer’s vulnerability-handling processes). Run a conformity assessment, issue an EU declaration of conformity, and apply CE marking. Maintain a vulnerability handling process for the support period. Produce a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies, held in technical documentation retained for at least ten years.
10 December 2024. In force. The clock starts; no manufacturer obligations yet.
11 June 2026. Chapter IV applies. Member States designate notifying authorities and conformity assessment bodies stand up.
11 September 2026. Article 14 reporting applies. Actively exploited vulnerabilities and severe incidents must be reported to ENISA and national CSIRTs through the Single Reporting Platform. 24 hours for early warning, 72 hours for the fuller notification, 14 days for the final report. Applies to products already on the market.
11 December 2027. Full application. Essential requirements, conformity assessment, and CE marking apply to products placed on the market from this date.
Penalties reach €15 million or 2.5 percent of total worldwide annual turnover, whichever is higher, for breaches of the essential requirements or the manufacturer obligations. Microenterprises and small enterprises cannot be fined for missing the 24-hour reporting deadline, and open-source stewards are not subject to administrative fines at all.
This is the part of the EU Cyber Resilience Act that matters most to anyone running an AI programme, and it is the part most consistently reported wrong.
Article 12(1) offers a high-risk AI system that is also a product with digital elements a route to deemed compliance with Article 15 of the EU AI Act, provided it meets CRA Annex I Part I, its manufacturer processes meet Annex I Part II, and the required level of protection is demonstrated in the EU declaration of conformity issued under the CRA. Article 12(2) then applies the AI Act’s Article 43 conformity assessment procedure. Article 12(4) lets those manufacturers into the AI regulatory sandboxes under Article 57 of the AI Act.
Read casually, that sounds like one assessment discharging another. It is not. Here is the actual opening of Article 12(1):
“Without prejudice to the requirements relating to accuracy and robustness set out in Article 15 of Regulation (EU) 2024/1689... shall be deemed to comply with the cybersecurity requirements set out in Article 15 of that Regulation.”
Article 15 of the EU AI Act has three limbs: accuracy, robustness, and cybersecurity. The deeming reaches one of them.
Accuracy and robustness remain live obligations, evidenced independently, and nothing in the CRA declaration touches them. A security leader who reads “deemed compliant with Article 15” in a summary and stands down the adversarial testing programme on the strength of it has discharged one third of the article and kept the other two thirds without realising it. That is not a technicality. Robustness is where adversarial resilience lives, and adversarial resilience is precisely what an AI system needs and a conventional product security assessment does not test.
There is a second thing the summaries skip. CRA Recital 51 requires the cybersecurity assessment of a high-risk AI system to account for AI-specific vectors: data poisoning, adversarial attacks, and third-party attempts to alter the system’s use, behaviour, or performance.
That is an AI threat model, written into EU product law. Which means the CRA route is not a lighter standard dressed as a shortcut. The underlying evidence base is largely the same work. What changes is which declaration it is filed under, not how much work it takes. Organisations choosing the CRA route to reduce effort have misjudged what they are choosing.
Article 12(3) carves out important products (Annex III) and critical products (Annex IV) that are also high-risk AI systems and would otherwise have used the AI Act’s internal-control conformity route. Those go through the CRA’s own conformity procedures for the cybersecurity requirements. The higher the criticality, the less the shortcut applies.
If your company places anything with software and a network connection on the EU market, it is in scope, wherever you are headquartered. The same extraterritorial logic as the EU AI Act and GDPR.
Past 11 December 2027, non-compliant products cannot be sold in the EU. But the commercial pressure arrives before the legal one: enterprise buyers will expect CRA-compliant products, and buyers subject to NIS2 will be effectively required to source from compliant manufacturers. The market will enforce this before a regulator does.
And for AI specifically, the CRA is where AI security stops being a governance conversation and becomes a product conformity obligation with CE marking attached. That is a different kind of pressure, and it lands on a different executive.
The CRA's two headline demands, a machine-readable SBOM and a 24-hour exploitation report, look like paperwork until you look at what the literature says about where vulnerabilities actually come from.
“99% of vulnerabilities in client programs are caused by their dependencies”
That is the entire argument for the SBOM in one sentence. If almost every vulnerability you will ever have to report arrives through a component you did not write, then an inventory of components is not a compliance artifact. It is the only thing that makes the 24-hour clock survivable.
“recent years have shown almost exponential growth in attackers leveraging these software artifacts”
SolarWinds, Log4j, and xz utils are the names everyone knows. The EU Cyber Resilience Act is the EU's legislative answer to them, and it is why the obligation runs to the manufacturer rather than the user. When AI components enter that same supply chain, they inherit every one of these properties and add adversarial manipulation on top.
The first deadline is a reporting duty, not a design duty, which means the work that matters first is inventory and process, not engineering.
If you place products with digital elements on the EU market, yes. Manufacturer location is irrelevant; market placement is what counts. Importers and distributors carry their own obligations.
Software as a service is generally outside the CRA as a service, but remote data processing solutions that are integral to a product with digital elements are pulled in. The boundary is genuinely contested in edge cases. Document your determination and its reasoning.
No. This is the single most important misunderstanding on this page. CRA Article 12(1) deems compliance with the cybersecurity requirements of AI Act Article 15 only. Accuracy and robustness remain fully live and must be evidenced independently. Any advice suggesting otherwise has dropped the opening clause of the article.
Rarely. Recital 51 requires the cybersecurity assessment to consider data poisoning, adversarial attacks, and third-party attempts to alter behaviour or performance. The evidence base largely overlaps. What changes is which declaration it is filed under, not the volume of work.
Build the product inventory, and build it before 11 September 2026. New and legacy products, hardware and software, embedded components, remote data processing solutions, supported and unsupported versions still in use. You cannot report on a 24-hour clock about a product you cannot name.
Volume V of The Operating Discipline for AI Library™, The AI IT Security Audit™, addresses the CRA route in the Assembly Phase and carries it into the Regulatory Crosswalk. The AI Vendor Tier Map and the AI Data Flow Map produce the product and component inventory the CRA reporting duty depends on. The AI IT Security Audit engagement builds that inventory as a matter of course.
The authoritative texts behind this summary. This page exists because the secondary summaries of Article 12 are consistently wrong, so read the source. Anything concerning the EU Cyber Resilience Act that carries legal consequence should be confirmed against the Official Journal text, not against a secondary summary, including this one.
The AI Business Enablement Audit™ measures your organization against every framework in this library, including EU Cyber Resilience Act, and delivers a defensible governance dossier. Start or finish your audit below.
Start or finish your AI Audit →