How the EU Cyber Resilience Act (CRA) impacts AI Agents
The CRA asks manufacturers to say what their product is made of, ship it without known holes, and document their diligence on third-party components. Agent stacks have no universal component model — and the first obligations land on 11 September 2026.
A while back we ran our scanner across one developer’s laptop, mostly to see what an agent stack looks like from the outside. It found 57 skills, 1 plugin and 1 hook. Two of those 59 components had a package URL you could query a vulnerability database with.
That number has stuck with me, because it points to something the Cyber Resilience Act (CRA) discourse has not dwelled on. We have spent a lot of time in the past year on securing what an agent does at runtime, but we haven’t spent as much time on the boring question of what the agent is made of. The CRA is about to ask this question, in writing, with a deadline.
The software on that laptop isn’t subject to the CRA. But the same components bundled inside a product you sell into the EU will be, irrespective of where in the world you’re incorporated. The first of those obligations lands on 11 September 2026.
What is the CRA?
The CRA is a product security law that binds manufacturers placing products with digital elements (PDEs) on the EU market. It covers finished products and separately marketed software components: downloadable software, CLIs, SDKs, extensions, on-premises products, and hosted backends without which the downloaded software doesn’t work.
It’s also worth noting what is generally out of scope. Browser-based SaaS sits outside the product regime. So does software you deploy internally for your own employees, because there’s no placing on the market. So does unmonetised open source, which doesn’t meet the commercial activity gate.
Two dates to know. On 11 September 2026 the vulnerability and incident reporting obligations go live. On 11 December 2027 the rest applies. For non-compliance with Annex I or Articles 13–14, fines can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.
One caveat: I’m not a lawyer, so please talk to one if you want precise answers.
What does the CRA require?
There are four things the CRA asks from organizations selling digital products. Know what’s in it. Ship it without known holes. Show your work on the parts you didn’t write. Speak up fast when something in it is being exploited.
1. Know what’s in it
Annex I, Part II(1):
identify and document vulnerabilities and components contained in products with digital elements, 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
In plain terms: produce a machine-readable list of components that your product is made from, and keep it current.
The catch is that “top-level dependency” isn’t defined anywhere in the regulation. For a Python service that doesn’t matter, because the package manager defines it. Agent stacks often span package managers, Git sources, marketplaces, manifests, and configuration files, without a universal component model or lockfile.
An MCP server you bundle or configure by default is code, it’s network connected, and it runs as part of your product. Hard to argue it isn’t a component. Skills are less clear, because they’re typically instructions rather than code, although plenty of skills bundle scripts and scripts are code without question.
2. Ship it without known holes
Annex I, Part I(2)(a):
be made available on the market without known exploitable vulnerabilities
Two things worth understanding about this clause. It is a condition on placing the product on the market. Whatever you do at runtime, this clause judges the state of the thing on the day you shipped it. Second, and more interesting, to assert that a product has no exploitable vulnerabilities you need to enumerate its parts and check them against something.
For the agent ecosystem this is challenging. Go back to the 59 components at the top: only 2 had PURLs suitable for advisory matching. For the other 57 there’s no identifier, no advisory feed, no “known” to verify against.
3. Show your work on dependencies
Article 13(5):
Manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements
That same paragraph extends explicitly to free and open-source components that were never made available on the market in the course of a commercial activity, so pulling something off GitHub doesn’t route you around it. And due diligence isn’t a list of what’s present. It’s a record of what you assessed, against what, by whom, when, and what you concluded.
Article 13(6) rides along with it and requires you to report a vulnerability you find in a component to the upstream maintainer. For a package that’s trivial. For a skill somebody copied out of a GitHub repo, provenance stops being a nice-to-have.
4. Speak up fast when being actively exploited
Article 14 runs two tracks, both keyed to manufacturer awareness. Actively exploited vulnerability, or severe incident: early warning inside 24 hours of becoming aware, notification inside 72, then a final report. Fourteen days after a corrective measure exists on the vulnerability track; one month after notification on the incident track.
What starts the clock is awareness of an actively exploited vulnerability in your product, not an advisory matching one of your dependencies. You can’t establish the first without continuously watching for the second, so continuous monitoring is necessary, but monitoring on its own is not the obligation.
The practical consequence is that you need to scope your SBOM or AI-BOM to a specific release rather than to a filesystem scan. “This component is on a machine somewhere” doesn’t tell you whether it went out in 4.2.
Where we come into this
We build OpenACA. It resolves the identities of the components an agent is built from, MCP servers and skills and plugins and hooks and packages, maps how they’re wired together, and attributes advisories to whichever component actually introduced them. It exports CycloneDX. It’s open.
We’re not the only tool that can enumerate an MCP server. Checkmarx, ZeroPath and Snyk all ship some version of this today. What we’re working on is the layer above the list: tying a component back to the specific skill, hook or config that introduced it, and to the release it shipped in.
Our commercial product, OpenACA Cloud, adds continuous monitoring of component vulnerabilities and release-scoped BOMs across the products you ship.
See what’s in your agent stack
Run a free, local OpenACA scan:
curl -fsSL https://openaca.dev/install.sh | sh
openaca scan repo --target .It identifies agent components in your repository and checks supported identifiers (works with Claude Agent SDK today) against OpenACA advisories. Your configuration and results are not uploaded to OpenACA.
Need release-scoped Agent BOMs and ongoing monitoring across your team? Sign up for OpenACA Cloud and/or reach out to us [email protected].