--- title: "EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock" source: "https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/" description: "The EU Cyber Resilience Act's 24-hour reporting clock has been running since 11th September 2026, and it applies to AI agents. What the CRA asks of agent infrastructure." --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 05, 2026 • 18 min read **In short**, the EU Cyber Resilience Act (CRA) puts binding cybersecurity requirements on any software sold as a product in the EU, and it does not carve out AI agents. Since 11th September 2026, any company that sells software with digital elements into the EU has 24 hours from learning that a vulnerability is being exploited to file an early warning with a national CSIRT and ENISA, 72 hours to describe it, and 14 days to report what it did about it. From December 2027 the product itself must be secure by design: least privilege, access control, data minimisation, a small attack surface, and a record of what it did. Agents, MCP servers, and AI gateways shipped to European customers are software with digital elements. This post maps the CRA’s clock and its secure-by-design list onto what agent infrastructure has to provide, then says what a governance layer like Tigera Lynx can and cannot do about it. It is written for the platform and security leaders who will be asked to file the report. On 2nd September 2026, CISA added seven vulnerabilities to its Known Exploited Vulnerabilities catalog. Three were in AI infrastructure, and one of them sat in the Model Context Protocol endpoint of an AI gateway. [CVE-2026-59822](https://github.com/advisories/GHSA-7488-6r32-c95q) in LiteLLM, a popular open source AI gateway, let anyone with a made-up Bearer token open an authenticated MCP session: list the configured tools, call them, and reach whatever internal systems those tools reached. Wiz, which found the bug, [watched attackers exploit it in honeypots](https://www.wiz.io/blog/ai-infrastructure-honeypot) over the summer, probing with a Bearer token of a single character and walking the model list. The patch had shipped in May. The [seven additions](https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html) came with reverse shells, crypto miners, and a workflow engine running attacker commands as root. Nine days later, on 11th September, the [reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) of the EU Cyber Resilience Act became mandatory. The Commission’s [one-line summary](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) of what the law does is that it “introduces mandatory cybersecurity requirements for manufacturers, covering the planning, design, development and maintenance” of digital products. Secure by design, in other words, as a legal duty rather than a slogan. Read that against the LiteLLM story. A gateway whose authentication fell back to an empty identity when the key check failed is the opposite of secure by default, and it was being exploited in the wild for weeks before it reached anyone’s must-patch list. Had the calendar run the other way, with the CRA in force first and the exploitation discovered after, the question for every company that shipped that gateway to a European customer would not have been “do we patch.” It would have been: which of our products contain it, which customers in which member states run it, what did the attackers touch, and can we say all of that to a regulator by this time tomorrow. Most AI agent fleets could not answer that in 24 days, let alone 24 hours. ## Does the Cyber Resilience Act apply to AI agents? Yes, and it needs no AI chapter to do it: the law attaches to the thing, not to the technology inside it. [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) covers every “product with digital elements” made available on the EU market, which Article 3 defines as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” An agent you sell, an MCP server you ship, a gateway your customers install, a Helm chart with a support contract: each is a software product with a data connection, and that is the whole test. The Commission’s [guidance of 27 July 2026](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) runs to 67 worked examples and mentions AI twice in passing, once to cite the AI Act and once about AI-powered services. Agents, MCP and language models do not appear at all. There is no agent exemption to look for, because none was written. Three boundaries matter, and they are the ones people get wrong: **Software as a service is mostly out, until it is part of a product.** A purely hosted service that customers reach through a browser is regulated by NIS2, not the CRA. But the CRA pulls in “remote data processing” that a product depends on: processing at a distance “designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions.” An agent your customer installs that cannot run without your hosted planning service is one product, and the hosted half comes with it. [DLA Piper’s reading](https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-the-fine-line-between-saas-and-digital-products) of the boundary is that the decisive question is whether it is placed on the market as a product rather than a service, not which technology it uses. **Open source is out unless it is commercial.** Free software developed outside a commercial activity is excluded. Once you monetize it, support it under contract, or embed it in something you sell, the manufacturer obligations are yours, including due diligence on every component you pulled in. Foundations and companies that steward open source projects on a sustained basis get a lighter regime as “open-source software stewards,” with a cybersecurity policy, cooperation duties, reporting from December 2027, and no fines. OpenSSF’s [CRA resources](https://openssf.org/public-policy/eu-cyber-resilience-act/), including its guide for developers and its stewards playbook, are the clearest map of that seam. For most companies reading this, the relevant fact is simpler: the LiteLLM in your product is your problem, not LiteLLM’s. **Using agents internally is not manufacturing.** The CRA regulates the party that places the product on the market. An enterprise running agents for its own staff is a user, not a manufacturer, unless it sells the result. But users are not outside the story. Article 14 requires manufacturers to inform impacted users of exploited vulnerabilities and, where necessary, of the mitigations. When that notice lands, the question moves to you: which of your agents run the affected component, and what did they have access to. Same inventory problem, other side of the table. The dates, from the [Commission’s summary](https://digital-strategy.ec.europa.eu/en/policies/cra-summary): in force since 10 December 2024, reporting mandatory since 11th September 2026, and the full product requirements from 11 December 2027, applying to products already on the market as well as new ones. The fines top out at EUR 15 million or 2.5% of worldwide turnover for failing the essential requirements or the reporting duties. Article 12 adds one more link that matters for this audience: a product that is also a high-risk AI system under the AI Act is deemed to meet that law’s cybersecurity requirement when it meets the CRA’s, so for the agents that fall under both, the CRA’s Annex I is the list you build to. ## What does the 24-hour clock actually require? Article 14 gives a manufacturer three deadlines, twice over: once for an actively exploited vulnerability, once for a severe incident. An actively exploited vulnerability is one for which there is “reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” A severe incident is one that “negatively affects” the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions, or lets malicious code in. **Deadline** **Exploited vulnerability** **Severe incident** 24 hours from awareness Early warning: that exploitation is happening, and in which member states the product is available Early warning: that an incident has occurred, and whether unlawful or malicious acts are suspected 72 hours The product affected, the general nature of the exploit and the vulnerability, and any corrective or mitigating measures taken or available The nature of the incident, an initial assessment, and measures taken Final Within 14 days of a fix being available: the vulnerability, its severity and impact, and the security update Within one month of the 72-hour notice: a detailed description, severity, impact, root cause, and mitigations All of it goes through ENISA’s [Single Reporting Platform](https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched), which went live the same day, to the CSIRT of the member state where you have your main establishment, and from there to every member state where the product is sold. And separately, under paragraph 8, to your users. ![Timeline: the Cyber Resilience Act's reporting clock, from reliable evidence of exploitation at hour 0 to an early warning at 24 hours, a notification at 72 hours, and a final report at 14 days](https://www.tigera.io/app/uploads/2026/10/EU-Cyber-Resilience-Act-AI-Agents-1.png)Figure 1: Article 14's three filings. The clock starts on evidence of exploitation, not on the patch, and the first filing needs answers most fleets keep in people's heads. Now translate the 24-hour column into questions an engineering team has to answer before lunch tomorrow: - **Which of our products contain the affected component, at which versions?** The CRA expects this to be a lookup, not an investigation. Annex I Part II requires a software bill of materials “covering at the very least the top-level dependencies.” An agent’s dependencies include its framework, its MCP servers, its gateway, and the model endpoints it is wired to. - **Which customers, in which countries, run it?** The early warning must name the member states. A product you cannot enumerate deployments of is a product you cannot file for. - **Is it exploited, or merely vulnerable?** The clock starts on reliable evidence of exploitation. Evidence means a record of what the component did that it should not have. If the only log is the one the compromised component wrote about itself, you have a story, not evidence. - **What could it reach?** The LiteLLM flaw was serious because a gateway holds the keys to everything behind it. Whether a severe incident occurred, and how severe, depends on what the compromised piece was authorized to touch. If the answer is “the service account had access to everything,” the incident report writes itself, and not in your favor. One agent makes each of these an afternoon’s work. Ten agents make it a spreadsheet. Two hundred agents, built by different teams on different frameworks, some in a vendor’s visual builder and some in a notebook that got promoted to production, make it a project that does not fit in 24 hours. Fewer agents would solve it, and nobody is going to do that. The realistic version is infrastructure that keeps the answers current while the fleet grows. ## What does “secure by design” mean for an AI agent? The reporting clock is the part in force today. The larger obligation lands in December 2027, and it is the secure-by-design half of the law. Annex I Part I of the regulation is the definition of secure by design that European regulators will hold products to, and reading it with agents in mind is uncomfortable, because it describes the agent stack most teams do not have. **Annex I asks** **With agents, that means** **So the infrastructure must provide** Secure by default configuration, point (b) An agent, MCP server, or gateway that denies by default and needs no hardening step the customer might skip Default-deny authorization that is the starting state, not a policy someone adds later Protection from unauthorised access by “authentication, identity or access management,” and reporting of possible unauthorised access, point (d) Every agent and tool has a verifiable identity, and every call is checked against it. A fabricated Bearer token opens nothing Workload identity issued by infrastructure, not a shared API key in an environment variable, with failed attempts recorded Data minimisation, point (g) An agent processes only what its current task needs, not everything its credentials allow Per-request authorization scoped to the task, with credentials held outside the agent Limit attack surfaces, including external interfaces, point (j) An agent can reach only the tools, models, and peers it was registered to reach Explicit allow lists of agent-to-agent, agent-to-tool, and agent-to-model paths, enforced in the data path Reduce the impact of an incident with exploitation mitigation, point (k) A compromised agent cannot escalate: its token works at one destination, and it can be stopped without stopping the cluster Per-hop, short-lived credentials, and a way to quarantine one workload Record and monitor “relevant internal activity, including the access to or modification of data, services or functions,” point (l) Every access attributed to a specific agent, acting for a specific person, through a specific tool and model An audit trail written by the enforcement point, across every hop, that the agent cannot edit Identify and document components, with an SBOM, Part II point (1) You know which agents run which framework, gateway, and MCP server versions, including the ones nobody registered Continuous discovery of agent workloads, not an annual questionnaire ![Diagram: one agent request from user to agent, AI gateway, MCP server and internal system, with an enforcement point at every hop, five Annex I tiles below, and an unregistered agent reaching the internal system on a dashed path](https://www.tigera.io/app/uploads/2026/10/EU-Cyber-Resilience-Act-AI-Agents-2.png)Figure 2: The same table drawn as one request. The five tiles are Annex I Part I points (b), (d), (g) and (l) and Part II point (1), and the dashed path is the agent nobody registered. Read column three again. Nothing in it is paperwork, and none of it is something the agent can do for itself. Every row is infrastructure that sits around the agent and does not trust it, because [controls the agent can override are not controls](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/). A model that has been talked into calling `export_customer_list` will do so with perfectly valid credentials and a plausible explanation. Point (d) does not ask whether the agent meant well. It asks whether the access was authorized. Notice, too, that the LiteLLM flaw fails four rows of that table at once. The default was not secure (b). Authentication fell through to an empty identity (d). The gateway’s interfaces exposed every tool behind it (j). And the blast radius was the gateway’s entire set of upstream keys (k). None of that is unique to LiteLLM. In April, OX Security disclosed that the stdio transport in the official MCP SDKs for Python, TypeScript, Java, and Rust [passed configuration straight to the operating system shell](https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled/), a default inherited by an estimated 200,000 instances across more than 150 million package downloads. Insecure defaults are how the ecosystem was built. The CRA makes them the manufacturer’s liability. The [five pillars of AI agent accountability](https://www.tigera.io/blog/the-five-pillars-of-ai-agent-accountability-a-diagnostic-framework-for-engineering-leaders/) we published earlier this year, traceability, authorization provenance, identity and ownership, policy at scale, and human oversight, were written before we read Annex I closely. Lay them over the table and each pillar answers one or two rows. Annex I got there first, and with fines attached. ## What happens when it is done properly? Here is what a governance layer like [Tigera Lynx](https://www.tigera.io/blog/why-we-built-lynx-bringing-control-to-the-age-of-ai-agents/) does for the table above, and what it leaves to you. Both halves matter. Done properly, every agent, MCP server, and LLM provider in the cluster is registered and carries a verifiable identity, so “which workloads run the affected gateway, and who owns them” is a query rather than a Slack thread. Authorization runs at a gateway the agent does not control: default deny, evaluated on every request, with the caller’s identity, the target, and the operation as context, so a compromised agent’s reach is exactly what its policy allowed and nothing more. Provider credentials live at the gateway, not in the agent, and each token the gateway mints is addressed to one destination, so a stolen token is worthless one hop later. Workloads that never registered, the experiment nobody decommissioned, are detected from the node itself by watching for connections to model endpoints and inspecting running processes. A workload that should not be there can be quarantined at the gateway and in the kernel. And every request lands in an audit trail written by the enforcement plane, with the caller, the human authority, the tool, the policy decision, and the model that served it. That is your 24-hour evidence, your Annex I point (l) record, and your incident-scoping data in one place. Now the other half. None of that is automatic. Someone has to register the agents and decide what each one may call, and a policy that allows everything is a policy that proves nothing. Someone has to maintain the software bill of materials for the agents themselves. A gateway can tell you which workloads talked to which endpoints, not which version of a Python package is inside a container. The detector finds unregistered agents, but a person decides whether each one is sanctioned. And Lynx does not file the report. Article 14 is a process your organization runs, with a named owner, an account on ENISA’s platform, and a rehearsed path from “we have reliable evidence” to “the early warning is submitted,” which you should run as a drill before you need it. What the infrastructure provides is the layer that process quietly assumes exists: the ability to say, with evidence, which agents you have, what each one could touch, and what each one did. Put in properly, that turns the 24-hour question from a forensic project into a lookup. Put in badly, it is one more dashboard nobody trusts. The difference is the work you do in the first month, not the software you install. ## Frequently asked questions - **Does the EU Cyber Resilience Act apply to AI agents?** Yes. The CRA applies to any software or hardware product with a data connection that is made available on the EU market, including components sold separately and the remote processing a product depends on. Agents, MCP servers, AI gateways, and their charts and operators are software products. The Commission’s 2026 guidance never mentions agents or language models, because there is no exemption to explain. - **When do the CRA obligations start?** Reporting of actively exploited vulnerabilities and severe incidents has been mandatory since 11th September 2026, for products already on the market as well as new ones. The essential cybersecurity requirements in Annex I, and the conformity assessment and CE marking, apply from 11 December 2027. - **Who reports, the vendor or the customer?** The manufacturer, meaning whoever places the product on the market under their name. A company using agents internally is a user, and is owed notification by its vendors under Article 14(8). If you build agents and sell them, or embed third-party agent components in a product you sell, you are the manufacturer for the whole product, including the open source inside it. - **Is a hosted AI agent covered by the CRA?** A purely hosted service is regulated by NIS2 rather than the CRA. Hosted processing becomes part of a CRA product when the product cannot perform one of its functions without it and the manufacturer built it. Many agent products, with an installed component and a required cloud backend, will fall on the CRA side of that line. Get a legal opinion on your own architecture. - **What must the 24-hour early warning contain?** For an exploited vulnerability: that it is being exploited, and where applicable the member states in which the product has been made available. For a severe incident: that it occurred, and whether unlawful or malicious acts are suspected. It goes through ENISA’s Single Reporting Platform to the CSIRT of the member state where you have your main establishment. The 72-hour notice and the final report add the detail. - **Does the CRA require logging for AI agents?** Annex I Part I point (l) requires products to provide security-related information by “recording and monitoring relevant internal activity, including the access to or modification of data, services or functions.” For an agent, that means an attributable record of which agent, on whose behalf, accessed which tool or data, and it needs to come from an enforcement point the agent cannot edit. Awareness of exploitation, which starts the 24-hour clock, depends on the same record. - **What are the penalties under the CRA?** Up to EUR 15 million or 2.5% of worldwide annual turnover for failing the essential cybersecurity requirements or the reporting duties, up to EUR 10 million or 2% for other obligations, and up to EUR 5 million or 1% for supplying incorrect or misleading information to authorities. ## The regulator’s question The people who wrote the CRA were thinking about routers, smart meters, and the software inside them. They were not thinking about a language model with a tool belt. But the law they wrote asks the questions that agent fleets are worst at answering: what is running, what can it reach, what did it do, and how fast can you say so. LiteLLM’s bug was exploited in honeypots for weeks before it reached CISA’s list. Under the CRA, the clock would have started the day the honeypot lit up, and the first report would have been due the next day. Meeting that has less to do with how good the incident response team is than with whether the infrastructure already holds the answers. So ask the question now, while it is cheap. If a component in your agent stack showed up on an exploited list tomorrow morning, which of your agents run it, what could each one reach, and what did they do last night? If the answer starts with “we would need to check,” the check is what to build. Secure by design used to be a principle. In Europe, it now has a filing deadline. *Lynx is Tigera’s security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read [How Lynx Works](https://www.tigera.io/blog/how-lynx-works-a-technical-walkthrough/) or request early access at [tigera.io/demo/?product=lynx](https://www.tigera.io/demo/?product=lynx).* [Best Practices](https://www.tigera.io/tags/best-practices/)[Observability](https://www.tigera.io/tags/observability/)[AI Agent Security](https://www.tigera.io/tags/ai-agent-security/)[Announcements](https://www.tigera.io/tags/announcements/) ## Related posts [![HIPAA Wasn’t Written for AI Agents. It Applies to Them Anyway](https://www.tigera.io/app/uploads/2026/09/HIPAA-Wasnt-Written-for-AI-Agents-featured.png)](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/) #### [HIPAA Wasn’t Written for AI Agents. It Applies to Them Anyway](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 2, 2026 In short, healthcare is adopting AI agents faster than almost any other industry. More than 85% of Epic’s customers already use Epic AI, Epic’s Agent Factory will let every health system build agents of its... [Read more](https://www.tigera.io/blog/hipaa-wasnt-written-for-ai-agents-it-applies-to-them-anyway/) [![Managing Claude Code Sessions Through Lynx](https://www.tigera.io/app/uploads/2026/09/Managing-Claude-Code-Sessions-Through-Lynx-featured.png)](https://www.tigera.io/blog/managing-claude-code-sessions-through-lynx/) #### [Managing Claude Code Sessions Through Lynx](https://www.tigera.io/blog/managing-claude-code-sessions-through-lynx/) By [Peter Kelly](https://www.tigera.io/blog/author/peter-kelly/) on Sep 30, 2026 At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts. Coding agents create an interesting problem because, in most organizations,... [Read more](https://www.tigera.io/blog/managing-claude-code-sessions-through-lynx/) [![The Clearinghouse For AI Agents Has A Blind Spot](https://www.tigera.io/app/uploads/2026/09/Lynx-Clearinghouse-Blog.png)](https://www.tigera.io/blog/clearinghouse/) #### [The Clearinghouse For AI Agents Has A Blind Spot](https://www.tigera.io/blog/clearinghouse/) By [Dillon Barry](https://www.tigera.io/blog/author/dillon-barry/) on Sep 23, 2026 Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple... [Read more](https://www.tigera.io/blog/clearinghouse/)