The Cyber Resilience Act, Regulation (EU) 2024/2847, is the EU's answer to a simple, embarrassing fact: for years you could sell software and connected devices in Europe with no baseline security obligations at all. That changes. The CRA entered into force on 10 December 2024, and its main requirements apply from 11 December 2027, with the vulnerability-reporting duties arriving earlier, on 11 September 2026.
What it covers, and what it asks
The CRA applies to products with digital elements, which is a deliberately wide net: hardware and software that can connect to a device or a network, from smart home gadgets to operating systems, firewalls and password managers. If you place such a product on the EU market, you inherit a set of duties. The Commission's CRA pages are the reference.
The core requirements are the sort of thing security people have asked for politely for a decade and are now getting in law. Products have to be secure by design and secure by default. They must ship without known exploitable vulnerabilities. Makers have to run a real vulnerability-handling process, with coordinated disclosure and free security updates across a defined support period. And they have to produce a software bill of materials, an SBOM, so buyers can actually see what is inside the thing they bought.
The SBOM requirement is quietly a big deal for AI. If you are shipping or running a system built from open-source components, model runtimes and libraries, an SBOM forces you to know your own ingredients. That is exactly the kind of supply-chain hygiene that gets skipped when everything is a black-box API you rent by the token.
How it touches AI systems
An AI product is still a product. If it has digital elements and it goes on the market, the CRA's security-by-design and vulnerability-handling duties apply to it like anything else, sitting alongside whatever the AI Act asks. There are carve-outs, notably for non-commercial open-source software and for products already covered by sectoral rules like medical devices, but the general software case is squarely in scope.
There is a reporting edge worth flagging for anyone shipping software. From 11 September 2026, makers have to report actively exploited vulnerabilities and severe incidents to ENISA and national response teams on a tight clock, with an early warning inside 24 hours. That is a real operational obligation, not a paperwork one.
The self-hosting angle
The CRA does not care whether your AI runs in the cloud or on your own metal. Its duties attach to products, not deployment locations. But the philosophy behind it, know what your software is made of, patch it, do not ship known holes, is far easier to honour when you control the stack. When you run an AI system in-house, you can produce a real SBOM, apply updates on your schedule, and account for every component. When your AI capability is a remote API, your supply-chain visibility ends at the vendor's edge, and you are trusting their CRA compliance as much as your own.
Regulators keep circling the same idea from different directions. The EU cybersecurity agency ENISA has documented for years how supply-chain attacks reach customers through their suppliers rather than head-on. The CRA, DORA and NIS2 all push the same way: know your dependencies, shorten your chains, own your risk. Keeping AI on-premise is one concrete way to do all three at once.
This is general information and not legal advice. The CRA's scope, classes and timelines have real nuance, so confirm how it applies to your specific product with a qualified adviser.