Cyber Resilience Act Enforcement: What AI Vendors Must Ship

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, entered into force in December 2024 as the bloc's first horizontal cybersecurity law for products with digital elements. AI software, connected devices, firmware updaters, and SaaS platforms that ship code to European users fall in scope when they qualify as products with digital elements rather than pure online services exempt under narrow carve-outs. Enforcement is staggered: notification rules for conformity assessment bodies began in June 2026, mandatory vulnerability and severe incident reporting under Article 14 began September 11, 2026, and full conformity obligations including CE marking and software bills of materials apply December 11, 2027.

Cyber Resilience Act AI compliance is not a separate regime. It intersects the EU AI Act, NIS2, GDPR, and product liability rules. A connected medical device running a high-risk AI model may need CRA security updates, AI Act conformity documentation, and sector-specific medical device regulation. Vendors should map obligations now because September 2026 reporting deadlines arrived with little grace period for manufacturers already shipping in-market products. Review AI code and devops tools and EU AI Act compliance guides alongside CRA planning.

CRA Scope for AI Products and SaaS

The CRA covers products with digital elements placed on the EU market, including software that is standalone, embedded in hardware, or delivered as firmware updates, when the product is intended for commercial distribution. Pure online services under the Digital Services Act carve-outs are generally outside CRA product rules, but many AI vendors ship desktop agents, edge models, SDKs, appliances, or IoT firmware that clearly qualify. Open-source stewards face lighter but real duties when they facilitate development of in-scope products.

AI-specific angles include:

• Model serving containers and on-prem inference appliances shipped to EU customers.
• Agent frameworks bundled with auto-update channels and local tool execution.
• Smart devices whose firmware includes on-device LLMs or vision models.
• CI/CD plugins and IDE extensions distributed as versioned binaries with automatic updates.

If your AI product connects to the internet, processes security-relevant data, or can be updated remotely, assume CRA relevance until counsel confirms an exemption. Microenterprises and small enterprises receive some fine exemptions but remain responsible for fundamental security practices and incident reporting in many cases.

Enforcement Milestones Through 2027

Article 14 reporting obligations became enforceable on September 11, 2026, requiring manufacturers to notify actively exploited vulnerabilities and severe incidents through the EU Single Reporting Platform. This date predates full CE marking requirements by more than a year, meaning teams must report on products already in the field even while technical documentation and SBOM programs are still maturing.

Market surveillance authorities in each member state enforce CRA, without a GDPR-style one-stop shop. A single missed Article 14 notification could trigger parallel investigations in multiple countries, though coordination mechanisms exist. Fines reach up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Vulnerability Handling and SBOM Expectations

Manufacturers must report actively exploited vulnerabilities within 24 hours of becoming aware, followed by intermediate updates at 72 hours and 14 days as specified in CRA implementing guidance. A vulnerability counts as actively exploited when reliable evidence shows a malicious actor used it without the system owner's permission. Routine pen-test findings without exploitation evidence do not trigger mandatory notification unless exploitation later appears.

Severe incidents include events that negatively affect confidentiality, integrity, or availability of sensitive functions, or that introduce malicious code into the product or customer networks. For AI vendors, examples might include compromised model download channels, poisoned weight files in update servers, or agent frameworks executing attacker-controlled tools at scale.

Software bills of materials become formally mandatory at the December 2027 deadline, but practical SBOM readiness is required earlier because you cannot meet 24-hour reporting without knowing which open-source components ship in each release. CRA expects machine-readable inventories covering dependencies, third-party libraries, and firmware modules, kept accurate across versions.

Overlap with the EU AI Act

The same security incident on a high-risk AI system deployed as a product with digital elements may require parallel notifications under CRA Article 14 and AI Act Article 73 serious incident rules, with EU law anticipating coordination to reduce duplicate filings. CRA focuses on product cybersecurity across the lifecycle. The AI Act adds model documentation, risk management, and transparency duties depending on system classification.

High-risk AI systems that are also CRA products should pursue aligned conformity processes rather than two siloed compliance teams. Technical documentation can share threat models, logging designs, and update mechanisms. GPAI model providers face AI Act obligations that do not replace CRA duties when they ship downloadable runtimes or appliances to EU customers.

Deployers remain responsible for operating AI within intended purposes, but manufacturers must deliver secure defaults, timely patches, and accurate SBOMs so deployers can fulfill NIS2 and sector rules. Contractual pass-through clauses shifting all security liability to customers will not satisfy market surveillance authorities if the manufacturer controls update channels.

Vendor Checklist for AI Software Manufacturers

Use this checklist to align engineering, legal, and product teams before the December 2027 conformity cliff while meeting live September 2026 reporting duties.

1. Inventory every SKU with digital elements sold or distributed in the EU, including on-prem AI agents and firmware.
2. Assign a CRA economic operator role (manufacturer, importer, or distributor) per entity in your corporate structure.
3. Stand up Article 14 playbooks: 24-hour, 72-hour, and 14-day notification templates tied to ENISA's platform.
4. Integrate SBOM generation into CI for each release artifact; store manifests with version control tags.
5. Map overlap with AI Act classifications, especially high-risk and GPAI documentation already required in 2026.
6. Publish a coordinated vulnerability disclosure policy with secure contact channels and SLAs.
7. Train support and SRE teams to escalate exploited vuln signals without waiting for executive approval cycles.
8. Document secure development practices, pen-test cadence, and supplier security reviews for technical files.
9. Plan CE marking and conformity assessment pathways for hardware-plus-AI bundles before December 2027.
10. Review customer contracts for update obligations, data access for incident response, and regulatory notice clauses.

AI-native startups that previously shipped only SaaS APIs should evaluate whether desktop clients, edge boxes, or partner OEM bundles pull them into CRA product rules faster than AI Act deployer duties alone. Early investment in component visibility pays off the first time a Log4j-style flaw hits a transitive dependency inside a model server image.

Open-source AI projects face nuanced CRA roles. Stewards who distribute model weights, inference servers, or fine-tuning toolchains may qualify as economic operators when they place products with digital elements on the EU market. Community maintainers without commercial distribution often fall outside manufacturer duties but should still publish security advisories and cooperate with downstream vendors who embed their code. Foundation model labs releasing open weights should expect European customers to demand CRA-aligned update channels even when licenses are permissive.

Incident playbooks for AI-specific failures differ from classic CVE responses. Model poisoning, adversarial prompts that crash serving infrastructure, and agent tool misuse can constitute severe incidents when they compromise integrity of security functions or introduce malicious code into customer environments. Legal and engineering should pre-draft ENISA notification templates that distinguish exploited vulnerabilities in dependencies from novel AI failure modes, while mapping both to CRA Article 14 timelines. Keep forensic artifacts: model version hashes, container image digests, and prompt logs subject to privacy review.

Procurement teams buying AI appliances from vendors should require CRA conformity roadmaps in RFPs issued after September 2026. Ask for sample SBOM formats, historical patch cadence, and proof of ENISA platform registration readiness. European public sector buyers may mandate CE marking timelines in framework agreements even before the December 2027 hard deadline, mirroring how GDPR readiness became a selection criterion years before peak enforcement. U.S. and Asian vendors without EU legal entities may need authorized representatives to fulfill manufacturer obligations when importing products with digital elements.

DevSecOps leaders should treat CRA as a forcing function to unify software composition analysis, container scanning, and model artifact signing. A single release train that publishes SPDX manifests, signs OCI images, and documents known vulnerabilities supports both CRA technical files and AI Act risk management records. Delaying SBOM automation until 2027 invites September 2026 reporting failures when a zero-day hits a buried dependency inside a GPU driver bundle shipped with your inference appliance.

Legal teams should brief boards on CRA fines alongside AI Act penalties so directors understand cumulative exposure. A severe incident that triggers both CRA Article 14 reporting and AI Act serious incident notification can generate parallel investigations, legal fees, and customer churn even before fines attach. Quarterly risk dashboards should track open vulnerabilities past SLA, SBOM coverage percentage per product line, and ENISA submission test drills completed before real incidents force first-time use of the Single Reporting Platform under deadline pressure.

For multinational AI vendors, harmonize CRA reporting with U.S. CISA coordinated vulnerability disclosure norms and ISO 29147 processes so security teams do not maintain three incompatible playbooks. A unified severity taxonomy mapped to CRA "actively exploited" and "severe incident" definitions saves hours when a zero-day spans EU and North American customer bases simultaneously.

Frequently Asked Questions

Does CRA apply to pure cloud APIs with no downloadable client?

Many pure APIs fall outside CRA product rules but may still face NIS2 or sector obligations. Any shipped agent, SDK binary, or appliance triggers CRA product analysis.

When did CRA reporting obligations start?

Article 14 reporting for actively exploited vulnerabilities and severe incidents began September 11, 2026.

Are SBOMs required before 2027?

Formal SBOM duties align with the December 11, 2027 full application date, but manufacturers need component visibility to comply with 2026 reporting timelines in practice.

What fines apply for CRA violations?

Up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, with some reductions for micro and small enterprises on certain provisions.

How does CRA interact with the AI Act?

CRA secures products with digital elements; the AI Act regulates AI system risk and transparency. Overlapping products may require coordinated documentation and parallel incident notifications with EU coordination mechanisms.