Does the Cyber Resilience Act apply to AI software?

Yes. The CRA covers products with digital elements placed on the EU market, and software is squarely within that scope regardless of whether it uses AI. An AI product is not exempt because the EU AI Act also applies to it — the two regulations run in parallel, and the AI Act expressly contemplates that meeting cybersecurity requirements under other Union law can support conformity rather than replace it.

What are the CRA deadlines?

The regulation entered into force in December 2024. The vulnerability and incident reporting obligations for manufacturers apply from September 2026, and the remaining obligations — essential cybersecurity requirements, conformity assessment, CE marking, technical documentation — apply from December 2027. The September 2026 date is the one that surprises teams, because it arrives more than a year before the requirements most people associate with the law.

Is pure SaaS in scope?

Generally not on its own. The CRA targets products with digital elements placed on the market, and a remote service delivered purely as SaaS is largely addressed by NIS2 instead. The nuance that catches people is remote data processing solutions: where a hosted component is necessary for the product to perform its functions, that component is pulled into the CRA's scope alongside the shipped software. A downloadable agent, desktop app, browser extension, mobile app, or on-premise deployment paired with a required cloud backend is not a clean SaaS exemption.

What has to be reported, and how fast?

Manufacturers must report actively exploited vulnerabilities in their products, and severe incidents affecting the security of the product, to the designated CSIRT and ENISA. The reporting cadence is staged: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report later. The trigger is active exploitation, not the existence of a vulnerability — but the 24-hour clock starts on awareness, which means the detection and escalation path has to exist before the first event.

Does the CRA require an SBOM?

It requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies. The SBOM does not have to be published to users by default, but it must exist, be kept current, and be available to market surveillance authorities on request. For AI products the interesting question is how far the bill of materials reaches into model artifacts and their dependencies — an area where practice is still consolidating.

EU Cyber Resilience Act: The AI Compliance Deadline Nobody Put on the Calendar

Two Regulations, One Product

The EU AI Act asks whether your system's use case is risky. The Cyber Resilience Act asks whether you placed a product with digital elements on the EU market. Those are different questions with different answers, and an AI company can pass the first scoping exercise cleanly — minimal risk, no Annex III use case, nothing to do — while being fully inside the second.

The overlap is not accidental. The AI Act's cybersecurity requirement for high-risk systems and the CRA's essential requirements are meant to interlock, and demonstrating conformity under one can support the other. But interlocking is not substitution. A team that produced an AI Act technical file and assumed it discharged the CRA will find the CRA asks for things the AI file does not contain: a coordinated vulnerability disclosure policy, a support period declared to purchasers, a machine-readable component inventory, and a reporting relationship with a CSIRT.

What the CRA Actually Obliges a Manufacturer to Do

Report actively exploited vulnerabilities

Early warning within 24 hours of awareness, a fuller notification within 72 hours, and a final report thereafter — to the designated CSIRT and ENISA. Live from September 2026.

Declare and honour a support period

Manufacturers must define how long they will provide security updates, with an expectation anchored around five years unless the product's expected lifetime is shorter. That declaration becomes a commitment purchasers can rely on.

Maintain a software bill of materials

In a commonly used machine-readable format, covering at least top-level dependencies, kept current and available to authorities. For AI products, decide early how model artifacts and their dependencies are represented.

Run coordinated vulnerability disclosure

A published contact point and a policy for receiving reports. This is the cheapest item on the list and the one most often missing when the first researcher email arrives.

Meet essential requirements and CE mark

Secure-by-default configuration, no known exploitable vulnerabilities at release, protection of data confidentiality and integrity, and an attack-surface minimisation story — evidenced through conformity assessment and technical documentation by December 2027.

The Scope Trap: "We're SaaS, So We're Out"

The most common CRA scoping conclusion in AI companies is that a hosted product is not a product placed on the market, so the regulation does not apply. That is a reasonable first read and frequently wrong in the details. The CRA reaches remote data processing solutions where the remote component is necessary for the product to perform its functions — so the moment your offering includes something a customer installs or deploys, the shipped artifact and the backend it depends on come along with it.

Work through the actual distribution list rather than the marketing description. A desktop client, an IDE plugin, a browser extension, a mobile app, an on-premise container, a self-hosted agent, an SDK shipped to customers, firmware in a device — any of these puts you in the manufacturer role for that artifact. Open source adds its own category: the CRA carves out non-commercial open source development but creates a lighter-touch "open source steward" role for organisations that support open source software commercially, which is a status worth determining deliberately rather than discovering later.

CRA Readiness Checklist for AI Software Teams

1. Scope Determination

☐List every artifact customers install, download, embed, or self-host — not the product name, the artifacts
☐For each, decide whether you are the manufacturer, importer, distributor, or open source steward
☐Identify remote components that are necessary for a shipped artifact to function
☐Record the determination and the reasoning; scope is the document authorities ask for first

2. September 2026 Reporting Readiness

☐Identify the CSIRT you would notify and the ENISA single reporting platform route in advance
☐Define what 'becoming aware' means internally, and who starts the 24-hour clock
☐Pre-draft the early-warning template so the first hour is not spent on wording
☐Rehearse the path once — an untested reporting process is not a reporting process

3. Product and Documentation

☐Generate an SBOM in a machine-readable format and wire it into the build, not a quarterly script
☐Decide how AI model artifacts and their dependencies appear in the component inventory
☐Publish a coordinated vulnerability disclosure policy with a working contact address
☐Declare the support period and make sure the roadmap can actually honour it

4. Alignment With Adjacent Regimes

☐Map CRA evidence against AI Act technical documentation to reuse rather than duplicate
☐Check whether NIS2 obligations apply to you as an entity in addition to CRA product duties
☐Reconcile CRA incident timelines with GDPR breach notification and any contractual notice terms
☐Give one owner the whole set; split ownership is how a 24-hour clock gets missed

Start with what your product shows the public

A missing disclosure contact, a broken policy page, an inaccessible support flow — reviewers find these before they find anything in your codebase. RatedWithAI scans your site and reports what they will see.

Scan Your Product for Free →

Frequently Asked Questions

We're a US company with no EU entity. Does the CRA reach us?

If you place products with digital elements on the EU market, yes — the obligations follow the product, not the incorporation. A manufacturer established outside the EU generally needs an authorised representative or has its importer and distributor pick up defined duties. Selling through a European reseller does not make the manufacturer obligations disappear; it distributes some of them to the reseller.

What are the penalties?

The CRA sets tiered administrative fines, with the highest band for breaches of the essential cybersecurity requirements and manufacturer obligations reaching up to 15 million euro or 2.5% of worldwide annual turnover, whichever is higher. Lower bands apply to other obligations and to supplying incorrect or misleading information to authorities.

Does an AI Act conformity assessment cover the CRA?

Not by itself. The regimes are designed to interlock — a high-risk AI system that meets CRA essential requirements is presumed to meet the AI Act's cybersecurity requirement in relevant respects — but the CRA carries its own documentation, reporting, support-period, and marking obligations that the AI Act file does not produce. Plan for one evidence base serving two assessments, not one assessment serving two laws.

What should a small team do first, given the December 2027 date is far off?

Ignore 2027 for now and solve September 2026. Confirm scope in writing, publish a vulnerability disclosure contact, and build a rehearsed 24-hour reporting path. Those three cost days, not quarters, and they are the obligations that are live. SBOM automation and conformity work can follow on the longer clock.

Related Guides

EU AI Act Conformity Assessment

How high-risk AI systems are assessed and CE marked.

DORA and AI Vendors

ICT third-party risk rules for financial entities in the EU.

SOC 2 and AI Subprocessors

What buyers check when your product calls someone else's model.

AI Incident Response Plans

Building an escalation path that survives a 24-hour clock.