The EU Cyber Resilience Act and AI Agent Products

The EU Cyber Resilience Act (CRA) regulates "products with digital elements" placed on the EU market, and commercial AI agent software — software that processes data and typically maintains a remote connection to a model provider or backend service — falls within that definition in the way most SaaS and packaged software products do. Its core duties are security by design, a documented vulnerability handling process, defined security-update support, and reporting of actively exploited vulnerabilities to the relevant EU authority. This post covers what those duties mean specifically for a team building and selling an AI agent product into the EU.

For the related EU obligations that often apply to the same product, see the EU AI Act explained for engineering teams and DORA and AI vendors for the parallel ICT third-party risk regime in financial services.

What the CRA covers, and why AI agent products are in scope

The CRA's definition of a "product with digital elements" is broad by design: hardware and software products whose intended use includes a direct or indirect logical or data connection to a device or network. It excludes a narrow list of categories already covered by other product-specific EU regimes (like medical devices and certain aviation and automotive systems) and treats software-as-a-service delivered purely as a remote service somewhat differently from a product placed on the market — but an AI agent platform sold as licensed software, an on-premises deployment, or a product with a client component generally falls squarely within scope.

The practical takeaway: if you sell AI agent software into the EU market as a product rather than purely as a hosted service you operate entirely on your own infrastructure, assume the CRA applies and work backward from there, rather than assuming an AI-specific exemption exists. None does.

The core obligations

The reporting duty deserves particular attention for AI agent products specifically: an actively exploited vulnerability in an agent's tool-calling layer, its credential handling, or a dependency it ships with is exactly the kind of event the CRA's early-warning reporting duty is built around, and the clock starts from when you become aware of active exploitation, not from when you finish investigating it.

Timeline: what applies when

The CRA's key dates are settled and public:

• 10 December 2024 — the CRA entered into force.
• 11 September 2026 — Article 14 reporting obligations become legally binding: manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT, on the 24-hour early-warning / 72-hour notification / 14-day-or-one-month final-report cadence described above.
• 11 December 2027 — the full set of obligations applies, including the essential security-by-design requirements, SBOM, conformity assessment, and CE marking.

This post publishes on 2026-09-06, which puts the Article 14 reporting duty five days away. If your AI agent product is already on the EU market, that reporting obligation reaches products already shipped, not just new releases — it is not limited to products first placed on the market after the date. If you do not yet have a working process for detecting active exploitation and reporting it on this clock, that is the most time-sensitive gap in this checklist, ahead of the longer runway to the 2027 conformity deadline. Verify implementing-guidance detail (exact CSIRT routing, report templates) against the current official timeline, since that is the layer still being refined.

The SBOM as a concrete AI-agent-specific deliverable

Of everything the CRA requires, the software bill of materials is the most immediately actionable for an AI agent product, because it forces a level of dependency transparency that agent architectures often lack by default. An agent product's SBOM needs to represent not just its own codebase but:

• The model providers or model-serving components it depends on, to the extent they are part of the shipped product rather than an external API the customer configures separately.
• The MCP servers and third-party tool integrations bundled with or recommended as part of the product.
• Open-source libraries used for orchestration, guardrail evaluation, or agent framework functionality.

If your product's dependency graph has never been fully enumerated — a common state for products that accumulated integrations over time — building an accurate SBOM is worth doing before a customer's procurement process asks for one, not after. See securing the agent supply chain and MCP server security checklist for the discovery and vetting patterns that feed into an accurate SBOM.

Open source components and the CRA's narrower carve-out

The CRA treats free and open-source software developed and supplied outside the course of a commercial activity differently from a commercial product — a narrower set of obligations applies to genuinely non-commercial open-source projects. This matters for AI agent products built substantially on open-source frameworks or models: your product, as a commercial offering, carries the full set of CRA obligations even if significant components of it are open source, while the upstream open-source project itself may sit in the narrower carve-out. Do not assume that because a critical dependency is "just an open-source library," its open-source status insulates your product from the CRA's requirements.

The control checklist

1. Confirm your product classification — is it a "product with digital elements" under the CRA, and if so, what conformity assessment category (default, important, or critical) applies based on its function and risk.
2. Build an accurate SBOM covering your own code, bundled model or tool integrations, and open-source dependencies, and keep it current as the product changes. See securing the agent supply chain.
3. Publish a coordinated vulnerability disclosure policy so external researchers have a clear reporting path.
4. Establish a vulnerability handling process with a defined remediation workflow and a way to push security updates to customers.
5. Build the capability to detect and report active exploitation quickly — this depends on the same agent-aware monitoring and audit trail infrastructure that other regimes in this series require. See audit trails that hold up under regulatory scrutiny.
6. Define your support period for security updates and communicate it clearly to customers as part of your product documentation.
7. Review third-party and MCP server integrations bundled with your product for their own security posture, since their vulnerabilities become part of your product's exposure. See MCP server security checklist.

What good looks like

• You have a documented conformity-assessment classification for your product under the CRA, reviewed as the product's functionality changes.
• Your SBOM accurately reflects the product's full dependency graph, including bundled model integrations and third-party tools.
• You can detect active exploitation of a vulnerability in your product and report it within the applicable window without a manual reconstruction effort.
• Your vulnerability disclosure policy is published and actually monitored.
• Your support-period commitment for security updates is documented and communicated to customers.

This is not legal advice; confirm current requirements, phase-in dates, and your product's specific classification with counsel before finalizing a CRA compliance program.

Common questions

Does the CRA apply if we only sell our AI agent product as a hosted SaaS service? This is a genuinely fact-specific determination under the CRA's product-versus-service distinction, and it depends on how your service is delivered and what components, if any, are placed on the market as a product. Do not assume a hosted delivery model automatically exempts you; get a specific read against the current text.

How does the CRA relate to the EU's operational cybersecurity directives? They are complementary but distinct: the CRA regulates the product itself — its security-by-design properties, vulnerability handling, and updates — while directives governing operational network and information security regulate the entity running the systems the product is deployed into. A company that both builds an AI agent product and operates it as a platform for customers may need to satisfy both a product-level regime and an operational-entity regime simultaneously, and should map each obligation to the correct one rather than assuming one compliance program covers both.

What is the single most useful thing to build first? An accurate, maintained SBOM. It is the most concrete, immediately actionable CRA deliverable, it is something customers increasingly ask for in procurement regardless of CRA enforcement status, and it is a prerequisite for meeting the vulnerability handling and reporting obligations that depend on knowing exactly what is in your product.

Do open-source AI agent frameworks we depend on need to comply with the CRA themselves? Genuinely non-commercial open-source projects have narrower obligations under the CRA than commercial products, but your own commercial product does not inherit an exemption just because it depends on open-source components. Confirm the compliance posture of any component you redistribute or bundle as part of a commercial offering, since your product's classification is what matters for your obligations.