CRA compliance caught a lot of AI providers unprepared. Most AI software providers have spent two years preparing for the EU AI Act. Very few have registered that the Cyber Resilience Act applies to them as well, on almost the same timeline, with its own conformity assessment, its own documentation, its own reporting channel, and its own penalty ceiling.
CRA compliance is not tomorrow’s problem. CRA applies to products with digital elements placed on the EU market. An AI SaaS product, a model served through an API, an on-premise inference deployment, or an AI feature inside a larger software product all meet that test. There is no AI carve-out.
Three things make this harder for AI products than for conventional software.
The support period requirement assumes products are maintained on a stable version line. AI models are deprecated on cycles considerably shorter than the CRA’s expected minimum support period, and nobody has yet explained how those two facts are meant to coexist.
The SBOM requirement was written with software dependencies in mind. Whether model weights, training frameworks, and inference runtimes are components for SBOM purposes is not settled, and the safest reading is the most expensive one.
The vulnerability reporting obligation turns on the concept of an actively exploited vulnerability. AI-specific attack classes including prompt injection and model extraction do not map cleanly onto that concept, and the 24-hour clock started on 11 September 2026 regardless.
Full CRA application is 11 December 2027. The AI Act Annex III high-risk deadline is 2 December 2027. Nine days apart, for the same products, under different authorities.
Key Definitions for CRA Compliance
| Term | Definition |
|---|---|
| CRA | Cyber Resilience Act, Regulation (EU) 2024/2847 |
| Product with digital elements | Any software or hardware product, and its remote data processing solutions, placed on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection |
| Remote data processing solution | Data processing at a distance where the software is designed and developed by the manufacturer and its absence would prevent the product performing its functions |
| Manufacturer | The entity that develops a product with digital elements and places it on the EU market under its own name or trademark |
| SBOM | Software bill of materials. A machine-readable component inventory required under CRA Annex I |
| Support period | The period during which a manufacturer must provide security updates. Expected to be at least five years as a rule |
| Actively exploited vulnerability | A vulnerability for which there is reliable evidence of malicious execution against a system without the owner’s permission |
| SRP | Single Reporting Platform. ENISA’s exclusive CRA reporting channel, live since 11 September 2026 |
| Important Class I and II | CRA product classifications requiring harmonised standards or notified body assessment |
| AI Act Annex III | The eight high-risk AI use case domains under Article 6(2) of the EU AI Act |
Is Your AI Product in Scope?
The CRA scope test is broad and the AI-specific questions arise at the edges rather than the centre.
The Core Test for CRA Compliance
A product with digital elements is any software or hardware product, and its remote data processing solutions, placed on the EU market in the course of a commercial activity, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.
An AI product almost always satisfies this. It is software, it is placed on the market commercially, and it connects.
| AI product | In CRA scope |
|---|---|
| AI SaaS platform sold to EU customers | Yes |
| Foundation model served through a commercial API | Yes |
| On-premise AI software deployed at customer sites | Yes |
| AI feature embedded in a larger software product | Yes, as part of that product |
| AI-enabled connected hardware | Yes |
| Internal AI tool never placed on the market | No |
| Open source model released outside commercial activity | No, though the steward category may apply |
| AI in a medical device under MDR | No, MDR governs |
CRA Compliance: The SaaS Boundary
The hardest scope question for AI providers is pure SaaS with no downloadable component.
The CRA covers remote data processing solutions where the data processing is integral to the product and its absence would prevent the product performing its functions. Where a product has a client component and a server component, the server side is in scope as a remote data processing solution.
Where there is no client component at all, only a hosted service accessed through a browser or API, the position is less settled. The Commission’s implementation FAQs published in December 2025 and the draft guidance published in March 2026 address the boundary, and the general direction is that pure cloud services without a product element fall to NIS2 rather than the CRA.
Two practical points follow.
First, most AI products are not pure SaaS in the relevant sense. An SDK, a client library, a desktop application, a browser extension, or a downloadable agent pulls the whole offering into CRA scope as a product with digital elements plus its remote data processing solution.
Second, the boundary determination should be documented. If you conclude you are outside CRA scope as a pure cloud service, that reasoning needs to exist in writing before a market surveillance authority asks for it.
CRA Compliance: Two Deadlines
| Date | Obligation | Framework |
|---|---|---|
| 2 August 2025 | GPAI model obligations, authorised representative for non-EU GPAI providers | AI Act |
| 11 June 2026 | Member states designate notifying authorities and notified bodies | CRA |
| 2 August 2026 | AI Office enforcement powers operational | AI Act |
| 11 September 2026 | CRA reporting obligations, SRP live | CRA |
| 2 December 2026 | Article 50(2) machine-readable marking for existing systems | AI Act |
| 2 December 2027 | Annex III high-risk AI obligations | AI Act |
| 11 December 2027 | CRA full application: Annex I, SBOM, CE marking, conformity assessment | CRA |
| 2 August 2028 | Annex I product-embedded high-risk AI obligations | AI Act |
For an AI SaaS product in an Annex III domain, December 2027 requires two complete conformity exercises, two documentation sets, and two sets of CE-adjacent formalities within a nine-day window.
The notified body capacity problem compounds this. Both frameworks route certain products through notified bodies, and both will see demand concentrate in 2027. AI providers needing assessment under both should be engaging now, not in 2027.
The Support Period Problem
This is the structural collision in CRA compliance that nobody has addressed, and it is the one most likely to cause real difficulty for AI providers.
What the CRA Requires
Manufacturers must determine a support period reflecting the expected product lifetime, during which they provide security updates. The Commission’s position is that this should be at least five years as a rule, with a shorter period justifiable only where the product’s expected lifetime is genuinely shorter. The support period must be communicated to purchasers at the point of sale.
What AI Providers Actually Do
Foundation model providers deprecate model versions on cycles of roughly twelve to eighteen months. Customers are migrated to successor models. Older model versions are retired from serving infrastructure. This is standard industry practice and it is not obviously compatible with a five-year security update obligation on the version the customer bought.
The question is what the product is.
| Reading | Product boundary | Support period consequence |
|---|---|---|
| The platform is the product | Model versions are components within a continuously supported platform | Five-year support attaches to the platform, model rotation is maintenance |
| The model version is the product | Each version is separately placed on the market | Five-year support attaches to each version, deprecation breaches it |
The first reading is the commercially viable one and is probably correct for most AI SaaS architectures. It is not obviously correct for a model served under a version-specific API endpoint that customers integrate against directly and that is retired on a published schedule.
What to Do About It
Define the product boundary explicitly and document the reasoning. This determination drives the support period, the SBOM scope, the conformity assessment unit, and the technical documentation structure. Leaving it implicit means four downstream decisions rest on an assumption nobody wrote down.
State the support period at the point of sale. The CRA requires it to be visible to purchasers. For AI products this will interact awkwardly with model deprecation notices, and the two should be drafted together rather than by different teams.
If model versions are separately placed on the market, price the support obligation. Maintaining security updates on deprecated model versions for five years is a real cost. It belongs in the commercial model, not in a compliance exception nobody has funded.
SBOM for AI Products
CRA Annex I requires manufacturers to identify and document components, including by drawing up a software bill of materials in a commonly used machine-readable format covering at least top-level dependencies.
The obligation is enforceable from 11 December 2027. It is operationally necessary from 11 September 2026, because determining within 24 hours whether a newly published vulnerability affects your product requires knowing what is in it.
The AI-Specific Question
The SBOM concept was developed for software dependency trees. AI products contain things that are not obviously software dependencies.
| Component type | Clearly in SBOM | Assessment |
|---|---|---|
| Inference runtime and serving frameworks | Yes | Conventional software dependencies |
| ML libraries and their transitive tree | Yes | Conventional software dependencies |
| Vector databases, embedding libraries | Yes | Conventional software dependencies |
| Third-party model weights | Contested | A binary artefact with known vulnerabilities and a supply chain. Arguments both ways |
| Fine-tuned models derived from a base model | Contested | The base model is a dependency in every meaningful sense |
| Training data | No | Not a component of the deployed product |
| Prompts and system instructions | No | Configuration, not component |
| External API dependencies on third-party models | Contested | Not shipped, but the product cannot function without them |
Neither SPDX nor CycloneDX had mature AI component profiles when the CRA was drafted. Both have been developing them. CycloneDX has moved further, with machine learning component types that accommodate models and datasets.
The Practical Position
Include model artefacts in the SBOM. The arguments for excluding them are technically respectable and the consequences of being wrong are asymmetric. A model with a known supply chain compromise is exactly the case the SBOM obligation exists to catch, and an SBOM that omits it will be difficult to defend.
Use CycloneDX where model components are significant, for its ML component support. SPDX is acceptable and ISO-standardised, and generating both costs little once the pipeline exists.
Cover the full transitive tree, not just top-level dependencies. Top-level is the CRA floor. Most exploited vulnerabilities arrive transitively, and the 24-hour clock does not accommodate manual dependency investigation.
The Vulnerability Question for AI Systems
CRA Article 14 has required reporting of actively exploited vulnerabilities since 11 September 2026. For AI products, the threshold question is what counts as a vulnerability.
AI-Specific Attack Classes
| Attack class | Vulnerability under CRA | Assessment |
|---|---|---|
| Prompt injection | Contested | Arguably a design characteristic rather than a defect. Arguably a security flaw enabling unauthorised behaviour |
| Indirect prompt injection via retrieved content | Likely yes | Closer to conventional injection: untrusted input reaching a privileged execution path |
| Training data poisoning | Yes if exploited | A supply chain compromise producing unauthorised behaviour |
| Model extraction | Likely yes | Unauthorised access to protected assets |
| Jailbreaks producing policy-violating output | Probably not | Content policy failure, not a security vulnerability, unless it enables unauthorised system access |
| Adversarial inputs degrading accuracy | Contested | May be Article 15 AI Act accuracy rather than CRA security |
| Agent privilege escalation | Yes | Unauthorised access through an exploitable flaw |
The uncertainty is genuine and the Commission has not resolved it. That does not help you at hour three of a live incident.
What to Do Given the Uncertainty
Decide in advance. Write the classification criteria into your incident procedure now, with a named person authorised to apply them. Deciding whether prompt injection is a reportable vulnerability during a live incident guarantees the 24-hour clock runs out first.
Over-report when genuinely uncertain. The CRA does not penalise reasonable over-reporting. Where you cannot determine within the window whether something is an actively exploited vulnerability, the early warning is the safer filing. Honest interpretation is treated differently from concealment.
Watch the agentic case specifically. An AI agent with system access and tool-calling privileges is a conventional attack surface wearing new clothing. Privilege escalation through an agent is a vulnerability under any reading, and the reporting clock applies.
CRA Compliance: Product Classification
Classification determines the conformity assessment route from December 2027. It does not change the substantive requirements.
| Class | Route | AI products likely affected |
|---|---|---|
| Default, around 90% of the market | Manufacturer self-assessment and EU declaration of conformity | Most AI SaaS, most AI features in general software |
| Important Class I | Harmonised standards, or third-party assessment where standards not applied | AI in identity management, network management, or security tooling |
| Important Class II | Notified body assessment mandatory | AI embedded in firewalls, intrusion detection, hypervisors |
| Critical | European cybersecurity certification | Rare for AI software |
Most AI products sit in the default tier. The exceptions are AI systems built into security and infrastructure products, where the underlying product class governs.
CRA classification and AI Act risk classification are independent. A product can be CRA default tier and AI Act high-risk, or CRA Important Class II and AI Act minimal risk. Neither can be inferred from the other.
GPAI Models Under the CRA
A foundation model placed on the EU market as a commercial product is a product with digital elements. The CRA applies alongside Chapter V of the AI Act.
| Obligation | AI Act Chapter V | CRA |
|---|---|---|
| Technical documentation | Article 53(1)(a), Annex XI | Annex VII |
| Training data transparency | Article 53(1)(d), public summary | Not required |
| Copyright policy | Article 53(1)(c) | Not required |
| Downstream provider information | Article 53(1)(d) | Not required |
| SBOM | Not required | Annex I |
| Vulnerability handling process | Not required | Annex I, Part II |
| Support period | Not required | Annex I, Part II |
| Security updates | Not required | Annex I, Part II |
| Adversarial testing | Article 55(1)(a), systemic risk models only | Annex I security testing |
| Incident reporting | Article 55(1)(b), to AI Office | Article 14, to CSIRT and ENISA via SRP |
The adversarial testing row is where consolidation is possible. A systemic risk GPAI provider already conducting Article 55 adversarial testing has work that substantially covers the CRA’s security testing expectations, provided the testing addresses security outcomes and not only safety and alignment outcomes.
The reporting rows do not consolidate. Article 55 reports go to the AI Office. Article 14 reports go to the coordinating CSIRT and ENISA through the SRP. A single incident affecting a systemic risk GPAI model can require both.
Open Source Models
Open source software developed and supplied outside the course of a commercial activity is outside CRA scope. Where an open source model is monetised, supported commercially, or shipped inside a commercial product, the manufacturer of that product carries CRA obligations for it.
The CRA’s open source software steward category applies to foundations and organisations sustaining open source development without direct monetisation, with lighter security policy and cooperation obligations rather than the full manufacturer burden.
The AI Act’s Article 53(2) open source exemption is a different instrument with different conditions and does not affect CRA scope.
Non-EU AI Providers: Do They Need to Worry about CRA Compliance?
The CRA applies to any manufacturer placing a product with digital elements on the EU market, regardless of establishment. UK, US, Swiss, Canadian, and other non-EU AI companies selling into the EU are manufacturers.
Two representative requirements exist and they are separate instruments.
| Requirement | Framework | Mandatory |
|---|---|---|
| EU authorised representative | CRA Article 17 | Permitted, not universally mandated, but practically necessary without an EU establishment |
| EU authorised representative | AI Act Articles 22 and 54 | Mandatory for non-EU providers of high-risk AI systems and GPAI models |
A UK-established entity does not qualify under either. The same EU entity can hold both mandates if structured for it.
The CRA representative determines your coordinating CSIRT for Article 14 reporting. Without one, and without an EU establishment, the coordinating CSIRT determination is unresolved, which is a problem you do not want to discover at hour one of an incident.
What to Do Now: CRA Compliance Checklist
Immediately, because reporting is already live
The Article 14 obligation has applied since 11 September 2026 and covers products already on the EU market, not only new releases.
| Action | Detail |
|---|---|
| Create EU Login accounts | For the primary filer and a deputy. Required for SRP access |
| Identify your coordinating CSIRT | By main establishment, or by authorised representative for non-EU providers |
| Name two Assigned Representatives | Primary and Secondary SRP seats, both having used the interface |
| Define who starts the 24-hour clock | Awareness has to be declared by someone with authority to declare it |
| Write the AI vulnerability classification criteria | Decide now whether prompt injection is reportable, not during an incident |
| Build the SBOM | Not legally required until December 2027, operationally required now |
Through 2027
| Action | Detail |
|---|---|
| Determine the product boundary | Platform or model version. This drives support period, SBOM scope, and assessment unit |
| Set and publish the support period | Visible at point of sale, reconciled with model deprecation schedules |
| Classify under both frameworks | CRA product class and AI Act risk tier, independently |
| Engage a notified body if required | Capacity will concentrate in 2027 and non-EU providers get no priority |
| Build the vulnerability handling process | Annex I Part II, covering AI-specific classes |
| Prepare both documentation sets | CRA Annex VII and AI Act Annex IV, from one underlying record |
| Push requirements into supplier contracts | SBOM provision, patching commitments, vulnerability notification, including from model providers |
Building for Both, Not Twice
The CRA and the AI Act ask different questions about the same product. What overlaps and what does not is predictable enough to design around.
Build once. Security architecture to CRA Annex I, with AI-specific threat classes mapped in, covers AI Act Article 15. The SBOM serves CRA Annex I and supports AI Act Annex IV architecture documentation. Product description, architecture, development methodology, and testing records feed both documentation sets.
Build separately. AI Act Article 9 risk management addresses health, safety, and fundamental rights, not cybersecurity risk. Article 10 data governance and Article 14 human oversight have no CRA equivalent. CRA vulnerability handling, support period, and security update delivery have no AI Act equivalent.
Cannot consolidate. Reporting. Different triggers, clocks, recipients, and channels, under different authorities.
This is the problem Grecta is built for. One system inventory, one evidence base, and framework mappings across the CRA, the EU AI Act, NIS2, DORA, GDPR, the Data Act, and US state AI laws. When a framework changes, the mapping updates rather than the record being rebuilt.
For AI products specifically, the compliance properties that matter are architectural: whether the SBOM exists and is current, whether logging is independent of the system generating it, whether the support period is deliverable given the deprecation schedule. Those are design decisions, not documentation exercises, and addressing them at audit time means rework the roadmap will not absorb.
Contact Grecta to discuss multi-framework compliance infrastructure for AI products.
FAQ
Does the Cyber Resilience Act apply to AI software?
Yes. The CRA applies to products with digital elements placed on the EU market, and AI software meets that test. There is no AI carve-out. Sector carve-outs exist for medical devices, motor vehicles, and civil aviation, where sector cybersecurity regimes govern instead.
Does the CRA apply to AI SaaS?
It applies to remote data processing solutions where the processing is integral to the product and its absence would prevent the product functioning. Most AI SaaS products have a client component, an SDK, or a downloadable element that brings the whole offering into scope. Pure cloud services with no product element fall closer to NIS2. Document the boundary determination either way.
When does CRA compliance apply to AI products?
Reporting obligations under Article 14 have applied since 11 September 2026 and cover products already on the market. Full application, including Annex I essential requirements, SBOM, CE marking, and conformity assessment, applies from 11 December 2027.
Do we need an SBOM for our AI model?
The SBOM obligation applies to your product from December 2027. Whether model weights are components for SBOM purposes is not settled. The safer position is to include them: a compromised model is exactly the case the obligation exists to catch, and an SBOM omitting it will be hard to defend. CycloneDX has more developed machine learning component support than SPDX.
Is prompt injection a reportable vulnerability under the CRA?
It depends. Direct prompt injection is arguably a design characteristic of language models rather than a defect. Indirect prompt injection through retrieved content is closer to conventional injection and more likely reportable. Agent privilege escalation is a vulnerability under any reading. Decide your classification criteria in advance rather than during a live incident, and over-report where genuinely uncertain.
How does the CRA support period work for AI models that get deprecated?
This is the least resolved question for AI providers. The CRA expects at least five years of security updates as a rule. Foundation models are typically deprecated within twelve to eighteen months. The answer turns on whether the product is the platform, with model versions as components, or the individual model version. Determine and document which, because it drives the support period, the SBOM scope, and the conformity assessment unit.
Do the CRA and the EU AI Act both apply to our AI product?
Frequently, yes. They regulate different aspects. The AI Act addresses risk classification, data governance, human oversight, and fundamental rights. The CRA addresses product security, vulnerability handling, SBOM, and support periods. Neither displaces the other and both apply in full where both are in scope.
Does complying with the AI Act satisfy the CRA?
No. AI Act Article 15 requires accuracy, robustness, and cybersecurity but does not require a vulnerability handling process, a support period, security update delivery, or an SBOM. A CRA Annex I security programme will substantially cover Article 15. The reverse is not true.
We are a UK AI company selling into the EU. Are we in scope?
Yes, for both frameworks. The CRA follows market placement, not establishment. So does the AI Act. You are a CRA manufacturer and an AI Act provider. A UK entity cannot serve as your EU authorised representative under either framework.
Do GPAI model providers have CRA obligations?
Where the model is placed on the EU market as a commercial product, yes, in addition to AI Act Chapter V obligations. The CRA adds SBOM, vulnerability handling, support period, and security update requirements that Chapter V does not contain. Incident reporting runs to different bodies through different channels under each framework.
What are the CRA penalties for AI products?
The same as for any product with digital elements: up to €15 million or 2.5% of worldwide annual turnover for breach of the Annex I essential requirements or the Article 13 and 14 manufacturer obligations, up to €10 million or 2% for other obligations, and up to €5 million or 1% for supplying incorrect or misleading information to authorities. These are separate from and additional to AI Act penalties.
Which authority enforces the CRA for our AI product?
National market surveillance authorities in the member states where the product is made available. There is no central EU enforcement body. ENISA operates the reporting platform but holds no enforcement power. Several member states have designated their national cybersecurity agency, including the BSI in Germany, but designations vary and should be verified against the Commission’s CRA Member States page.
This guide reflects Regulation (EU) 2024/2847, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, Commission implementation FAQs published December 2025, draft guidance published March 2026, and ENISA SRP guidance as at September 2026. Several questions addressed here, including the treatment of model artefacts in SBOMs and the classification of AI-specific attack classes as vulnerabilities, are not settled by the regulation or by published guidance. This guide is published by Grecta for general informational purposes and does not constitute legal advice.
