)
Does the Cyber Resilience Act apply to AI applications, and what does CRA compliance actually require? Yes. If your AI product has digital elements and reaches the EU market, it falls under the Cyber Resilience Act (Regulation EU 2024/2847). But the regulation is written in legal language, not technical specifications. It tells you to handle vulnerabilities, protect against unauthorized access, and log security events. It does not tell you how to do any of that for a system that can be hijacked by a sentence buried in a document. This guide translates the CRA's essential requirements into the concrete security controls AI and agentic systems actually need.
TL;DR
- The CRA (Regulation EU 2024/2847) is the first EU law to make secure-by-design a legal obligation for any product with digital elements. AI applications and AI agents are in scope.
- Two dates decide your roadmap: reporting obligations under Article 14 apply from 11 September 2026, and the main provisions apply from 11 December 2027.
- The September 2026 reporting duty applies even to products already on the market, with an early warning required within 24 hours of becoming aware of an actively exploited vulnerability.
- The CRA is deliberately technology-neutral. It never names prompt injection, tool abuse, or MCP servers, yet its requirements clearly imply controls for all of them when your product is an AI system.
- Penalties reach up to €15 million or 2.5% of worldwide annual turnover.
- CRA compliance for AI is an engineering effort, not paperwork: AI red teaming, runtime monitoring, least-privilege tool execution, supply chain validation, and immutable logging that can feed a 24-hour report.
The Cyber Resilience Act is ready. Most AI products are not.
Most teams building AI applications assume they have until the end of 2027 to worry about the Cyber Resilience Act. That assumption is expensive. The CRA reporting obligations bite on 11 September 2026, and they apply to products already shipped, not just new ones. From that date, if an attacker is actively exploiting a vulnerability in your system, you have 24 hours to file an early warning with ENISA and the relevant national CSIRT.
)
Here is the uncomfortable question for anyone running an LLM-based product in production today: if someone weaponized an indirect prompt injection against your agent right now, would you even know? And if you knew, could you produce a report in 24 hours that says what happened, which component was affected, and what you did about it?
For most AI applications, the honest answer is no. Not because teams are careless, but because the CRA was written with deterministic software in mind, and AI systems break several of its quiet assumptions.
What the Cyber Resilience Act actually requires
The CRA sets out its essential requirements in Annex I, split into two parts. Part I covers properties the product must have. Part II covers processes the manufacturer must run throughout the support period.
On the product side, in-scope products must be made available on the market without known exploitable vulnerabilities and with a secure-by-default configuration. They must ensure protection from unauthorized access by appropriate control mechanisms, including authentication, identity, or access management systems. They must protect the confidentiality and integrity of data, minimize the attack surface, and provide security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services, or functions.
On the process side, manufacturers must identify and document components, address and remediate vulnerabilities without delay, apply effective and regular tests and reviews of the security of the product, and enforce a policy on coordinated vulnerability disclosure.
Notice what is missing. The text never names a single AI threat. That is by design. The CRA is intentionally technology-neutral: it defines security outcomes and lifecycle obligations rather than prescribing particular tools or techniques. Which means the burden of translation falls on you. "Protect against unauthorized access" is one sentence in the regulation. For an autonomous agent with access to tools, memory, and external systems, it is a whole architecture.
Why AI systems break the CRA's assumptions
Traditional software has a clean boundary between code and data. Instructions come from the developer; everything else is input to be processed. The CRA's framework leans on that boundary.
AI systems erase it. In an LLM, a sentence inside a user message, a retrieved document, or a tool response can become an instruction the model follows. The OWASP Top 10 for LLM Applications (2025) ranks prompt injection as the number one risk precisely because models process instructions and data in the same channel, with no reliable separation between the two. That single property dismantles several conventional controls:
- Untrusted input becomes executable. Prompt injection means the attack surface is every piece of text your system ingests, not just its API parameters.
- Behavior is non-deterministic. The same input can produce different outputs. "Known exploitable vulnerability" gets fuzzy when the vulnerability is a probabilistic tendency rather than a fixed flaw in a line of code.
- The supply chain is new and opaque. Your dependencies now include model weights, training data, fine-tunes, MCP servers, and third-party tools. An SBOM that only lists Python packages misses most of the real risk surface.
- Agents act in the world. When a model can call tools, send emails, or move money, a successful injection is no longer an information leak. It is unauthorized action with real consequences, what OWASP calls excessive agency.
A CRA program built only on classic AppSec practices will tick boxes while leaving these gaps wide open. The requirements still apply. The implementation has to be rethought.
Mapping CRA requirements to AI security controls
This is where the regulation becomes an engineering roadmap. Each essential requirement in Annex I maps to specific, buildable controls for AI systems.
| CRA essential requirement (Annex I) | Technical implementation for AI |
|---|---|
| Secure by design | AI threat modeling (STRIDE plus OWASP GenAI Top 10), secure SDLC, policy enforcement at the gateway |
| Secure by default | Least-privilege tool scopes, conservative model configuration, no unrestricted system access out of the box |
| Protection from unauthorized access | Identity for agents and workloads, scoped tool permissions, mTLS between services |
| Confidentiality and integrity of data | Secret and PII leakage prevention, memory protection, context isolation between sessions |
| Minimize attack surface | An AI gateway as a single chokepoint, input and output guardrails, restricted tool catalog |
| Vulnerability handling | AI red teaming, a disclosure process that covers model-level findings, managed model updates |
| Logging and monitoring | Immutable audit logs, runtime monitoring, behavioral anomaly detection |
| Secure updates | Signed model and prompt updates, rollback capability, change tracking |
| Supply chain security | Model provenance checks, MCP server validation, an SBOM extended to AI components |
Three of these deserve a closer look, because they are where AI departs most sharply from the regulation's original mental model.
Vulnerability handling, redefined. For an LLM application, what counts as a vulnerability? A jailbreak that bypasses your safety policy. A prompt injection pattern that exfiltrates system instructions. A tool-calling sequence that escalates privileges. None of these will appear in a CVE database, yet each is a genuine exploitable weakness the CRA expects you to find, fix, and disclose. This is why AI red teaming is not optional polish. It is how you satisfy the requirement to test and remediate, applied to a system whose failure modes are linguistic rather than syntactic. At NeuralTrust we treat continuous AI red teaming as the discovery layer for exactly this kind of model-level vulnerability.
Runtime monitoring for agents. The CRA requires recording and monitoring relevant internal activity. For a deterministic app, that is request logging. For an agent, it means watching the actual decisions: which tools were called, with what arguments, in response to which inputs, and whether that pattern looks like the agent's intended behavior or like something steering it off course. Without behavioral monitoring at runtime, you cannot detect an active exploit, and if you cannot detect it, you cannot meet the 24-hour reporting window.
Supply chain you can no longer ignore. The regulation expects you to identify and document the components in your product. For AI, that inventory has to reach the model you call, where it came from, the MCP servers your agent connects to, and the tools it can invoke. Each is an entry point. An unvetted MCP server is, functionally, a third-party component with write access to your agent's behavior.
)
CRA and AI agents: the harder case
Single-shot LLM calls are difficult enough. Autonomous agents raise the stakes considerably, and this is where the gap between the CRA's text and operational reality is widest.
Agents introduce threats the regulation never anticipated by name: indirect prompt injection through retrieved content, tool abuse where a legitimate capability is turned to a malicious end, agent-to-agent communication that propagates a compromise, and memory or context poisoning that corrupts future decisions long after the initial attack.
Map these back to the CRA and the controls become clear. "Protection from unauthorized access" becomes a real tool permission model, where an agent can only invoke what its task requires and nothing more. "Integrity of data and commands" becomes secure tool execution and validation of what flows into the agent's memory. "Monitoring relevant internal activity" becomes continuous behavioral monitoring of the agent's action stream. This is the layer an AI gateway is built to enforce: a single control point where policy, identity, and inspection apply to every model call and every tool invocation.
To be precise: none of these controls are named in the CRA. They are concrete technical measures that contribute to satisfying its general requirements, adapted to the reality of agentic systems. The regulation gives you the obligation. Engineering gives you the implementation. That translation is the entire job.
A practical CRA-readiness checklist for AI
If you build AI applications, this is what CRA readiness looks like in practice:
- ✅ Tool permissioning with least privilege enforced per agent and per task
- ✅ Runtime monitoring of agent actions, not just request logs
- ✅ Prompt injection detection on inputs, retrieved content, and tool responses
- ✅ Secret and PII leakage prevention on model outputs
- ✅ Supply chain validation for models, fine-tunes, libraries, and tools
- ✅ Secure MCP connections with vetted, scoped servers
- ✅ Immutable logging that can reconstruct an incident after the fact
- ✅ AI red teaming run regularly, not once before launch
- ✅ Incident response capable of producing a report inside 24 hours
If you cannot tick most of these today, you do not have a documentation problem. You have an engineering backlog, and the clock is running.
The CRA deadlines that decide your roadmap
The Cyber Resilience Act phases in, and each date should drive a specific technical decision.
By 11 September 2026, the Article 14 reporting obligations apply, including to products already on the market. To meet a 24-hour early warning window, you need detection and logging live in production well before then. You cannot build an incident response process during the incident.
By 11 December 2027, the full set of essential requirements applies, and CE marking becomes a precondition for placing new products on the EU market. That covers secure-by-design, vulnerability handling across the support period, and the extended SBOM.
Worth noting for AI builders specifically: the CRA and the EU AI Act are designed to interlock. Products with digital elements considered high-risk AI systems under the AI Act will be deemed compliant with its cybersecurity requirements if they meet the CRA's requirements. Getting CRA security controls right does double duty.
The takeaway is simple. The Cyber Resilience Act is not a legal exercise to be handed to counsel and forgotten. It is a security engineering problem for anyone building AI, and the systems that need protecting are already in production.
FAQs
Does the Cyber Resilience Act apply to AI applications and agents? Yes. The CRA covers products with digital elements placed on the EU market, and AI applications qualify. The regulation does not carve out AI; it applies the same essential cybersecurity requirements, which you then have to implement for the specific risks AI introduces, such as prompt injection and tool abuse.
What is the first CRA deadline I need to worry about? 11 September 2026, when the Article 14 reporting obligations take effect. These apply even to products already on the market, and they require an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident. Full compliance with the essential requirements follows on 11 December 2027.
Does the CRA specifically mention prompt injection or other AI threats? No. The CRA is technology-neutral and defines security outcomes rather than techniques. Prompt injection, tool abuse, and MCP security are not named, but the regulation's requirements for access control, data integrity, and monitoring clearly imply controls for them in AI systems.
What counts as a vulnerability in an LLM application under the CRA? Anything that constitutes an exploitable weakness: jailbreaks that bypass safety policy, injection patterns that leak system prompts, or tool-calling sequences that escalate privileges. These will not appear in a CVE database, but they still fall under the CRA's vulnerability handling obligations and should be surfaced through AI red teaming.
Do I need an SBOM for AI components? Effectively, yes. The CRA requires you to identify and document the components in your product. For AI systems that inventory should reach models, fine-tunes, MCP servers, and tools, not just traditional software dependencies.
What are the penalties for CRA non-compliance? Up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for non-compliance with the essential requirements. Products that fail conformity assessment can also lose access to the EU market.
Does meeting the CRA help with EU AI Act compliance? For high-risk AI systems, yes. Meeting the CRA's cybersecurity requirements can satisfy the corresponding cybersecurity obligations under the AI Act, so the work is not duplicated.
Key Takeaways
- The Cyber Resilience Act applies to AI applications and agents. There is no AI exemption.
- The real first deadline is 11 September 2026 for reporting, not December 2027, and it applies to products already in production.
- The regulation is technology-neutral, so the burden of translating legal requirements into AI-specific controls falls on the builder.
- AI breaks the CRA's core assumption that code and data are separate, which is why prompt injection makes every input part of the attack surface.
- CRA compliance for AI is an engineering effort: red teaming, runtime monitoring, least-privilege tool execution, supply chain validation, and immutable logging.
- Agentic systems raise the stakes, turning a successful injection from an information leak into unauthorized action.
- Getting CRA controls right also advances EU AI Act compliance for high-risk systems.
About the Author
Alessandro Pignati is Lead AI Security Researcher at NeuralTrust, where he leads research on AI and agentic security, advancing techniques to evaluate and secure large language models and autonomous AI systems. He specializes in adversarial machine learning, AI red teaming, LLM security, and AI safety, contributing to the development of secure and trustworthy AI.
NeuralTrust is an AI agent security platform, recognized in the Gartner 2025 Market Guide for Guardian Agents. Headquartered in Barcelona with ISO 27001 certification.
)
)
)
)