The Cyber Resilience Act is the EU’s answer to products that ship with known vulnerabilities and no updates. It applies to almost anything with a network connection, it applies to software on its own, and for high-risk AI systems it does something unusual: it lets compliance with its requirements carry across into the AI Act.
What falls in scope
Regulation (EU) 2024/2847 was adopted on 23 October 2024, published on 20 November 2024 and entered into force on 10 December 2024. It applies to products with digital elements — hardware and software — whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. The text is at EUR-Lex, ELI reg/2024/2847.
For AI, the practical scope test is uncomfortable for anyone hoping to be out: a model shipped as software, an application that calls one, a device with an on-board model that phones home, and the SDK in between are all products with digital elements. Article 2 carves out products already covered by comparable regimes — medical devices under the MDR and IVDR, motor vehicles under Regulation (EU) 2019/2144, civil aviation under Regulation (EU) 2018/1139, marine equipment — and the regulation treats free and open-source software supplied outside a commercial activity separately, with a lighter set of duties for open-source software stewards.
Note what is not excluded: a hosted service is outside the CRA as a service, but the software you distribute to reach it is not, and remote data processing solutions integral to a product’s functions are pulled in with the product.
Scope, product classification and the applicable conformity assessment route are questions to settle on the specific product with advice. This page describes the regulation and is not legal advice.
The essential requirements
Annex I has two parts and the split matters. Part I is about the product’s properties: delivered without known exploitable vulnerabilities, with a secure-by-default configuration, protection of confidentiality and integrity of stored and transmitted data, data minimisation to what is necessary, resilience against denial of service, minimisation of attack surface, and the ability to receive security updates — including, where technically feasible, automatic updates that can be turned off.
Part II is about process, and it is where most engineering effort actually goes. It requires identifying and documenting vulnerabilities and components, including a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies; addressing vulnerabilities without delay through security updates; regular testing; a coordinated vulnerability disclosure policy with a contact address; and distributing updates free of charge and without delay. An SBOM entry is not a document you write once:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{
"type": "library",
"name": "onnxruntime",
"version": "1.20.1",
"purl": "pkg:pypi/[email protected]"
},
{
"type": "machine-learning-model",
"name": "intent-classifier",
"version": "2026-03-11"
}
]
}
Article 13 also requires the manufacturer to determine and state a support period during which vulnerabilities are handled, which must reflect how long the product is reasonably expected to be in use and must be at least five years unless the product’s lifetime is shorter. For an AI-enabled consumer device this is the obligation with the largest long-term cost attached, and it is the one most often absent from a product plan.
The bridge to AI Act Article 15
Article 15 of the AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and to be resilient against attempts to alter their use, outputs or performance by exploiting vulnerabilities — including data poisoning, model poisoning, adversarial examples and confidentiality attacks. It says almost nothing about how.
The CRA supplies the how, and Article 12 of the CRA makes the connection explicit: products with digital elements that are classified as high-risk AI systems under the AI Act and which meet the essential cybersecurity requirements in Annex I Part I are deemed to comply with the AI Act’s cybersecurity requirements, to the extent those requirements are covered by the EU declaration of conformity. Such products follow the AI Act’s conformity assessment procedure rather than running two in parallel.
That is a genuine simplification and it is also narrow. It covers cybersecurity only — the accuracy and robustness limbs of Article 15 are untouched, and adversarial robustness of a model is not the same property as the product-security properties in Annex I Part I. A team that reads the presumption as covering Article 15 entirely will find the gap at assessment. See Article 15 in detail for what remains to be demonstrated separately.
Two timelines, and the gap between them
The CRA applies in stages. The provisions on notification of conformity assessment bodies apply from 11 June 2026. The reporting obligations in Article 14 — notifying actively exploited vulnerabilities and severe incidents affecting the security of the product to the relevant CSIRT and to ENISA, with an early warning within 24 hours — apply from 11 September 2026. Everything else, including the essential requirements and CE marking, applies from 11 December 2027.
The AI Act runs on its own clock: prohibitions and AI literacy from 2 February 2025, GPAI obligations and penalties from 2 August 2025, the Annex III high-risk regime from 2 August 2026, and high-risk systems that are safety components of products under sectoral legislation from 2 August 2027.
Set those side by side and the consequence is concrete: an Annex III high-risk system must satisfy AI Act Article 15 from August 2026, more than a year before the CRA requirements it can be presumed to satisfy them through are themselves applicable. The presumption route is not available in that window, so the cybersecurity case has to be made directly against Article 15 and whatever harmonised standards exist by then.
What this means before 2027
The work that is due first is not the CE marking, it is the reporting capability. From September 2026 a manufacturer must be able to detect that a vulnerability in its product is being actively exploited and to notify within 24 hours. That requires monitoring, an owner, and a route to a CSIRT identified in advance — none of which can be assembled after the incident starts.
The second is the bill of materials, because it is the input to everything else and it is worst to build retroactively. For AI products the uncomfortable question is whether model weights, datasets and fine-tuned checkpoints appear in it at all; the regulation requires at minimum top-level dependencies, and a product whose behaviour is determined by a checkpoint nobody versioned has a dependency it cannot report. The overlapping obligations for infrastructure and service providers run through a different instrument — NIS2 for AI infrastructure providers — and the two sets of incident reporting duties are not identical, which is the next thing to reconcile once both apply.
Top comments (0)