Cyber Resilience Act and AI: what companies building AI software must do now

If your company builds and sells a product with artificial intelligence inside — an app, a plug-in, an installable agent, a connected device — there is an obligation already in force that goes almost unnoticed in the AI Act conversation. Since 11 September 2026 you must report actively exploited vulnerabilities in the product within 24 hours. It is not the AI Act that says so: it is the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847.

The AI Act pushed high-risk obligations back; the CRA did not. And it applies to any product with digital elements, not only to high-risk AI.

What the Cyber Resilience Act is and when it applies

The CRA sets mandatory cybersecurity requirements for products with digital elements: software or hardware, including their remote data processing solutions (Art. 3(1) and (2)). The timetable comes in two stages:

The point people miss: under Article 69(3), reporting also covers products already placed on the market before 11 December 2027. The software you sold last year is already in scope.

Who is in and who is out

• In: desktop and mobile apps, commercially supplied libraries and SDKs, installable agents and components, firmware, IoT devices with on-board models — plus the backend you designed and without which the product does not work.
• Generally out: pure SaaS, delivered entirely remotely and not accompanying a distributed product. Recital 12 excludes cloud services designed outside the responsibility of a manufacturer.

The line is drawn by the architecture, not the sales label: a "SaaS" that requires an installed client needs to be analysed.

24-hour reporting: what Article 14 requires

When you become aware of an actively exploited vulnerability or a severe incident affecting the security of the product, you notify simultaneously the CSIRT designated as coordinator in the Member State of your main establishment and ENISA, through the single reporting platform:

1. Early warning within 24 hours, indicating where possible the Member States where the product is available.
2. Notification within 72 hours, with the nature of the problem, corrective measures taken and measures users can apply.
3. Final report: within 14 days of a fix becoming available (vulnerabilities) or within one month of the notification (severe incidents).

In addition, Article 14(8) requires you to inform impacted users and the measures they can take. An incident is "severe" if it compromises, or may compromise, the availability, authenticity, integrity or confidentiality of important data or functions, or leads to malicious code being executed in the product or the user's systems.

This chain is separate from serious-incident reporting under AI Act Article 73 and from GDPR breach notification (72 hours to the data protection authority): the same event can trigger all three.

Where the CRA and the AI Act meet

For a product that is also a high-risk AI system (Art. 6 of Regulation EU 2024/1689), CRA Article 12 builds a bridge:

• if the product meets the essential requirements of CRA Annex I (product and processes) and the EU declaration of conformity demonstrates it, it is deemed to comply with the cybersecurity requirements of AI Act Article 15;
• conformity assessment as a rule follows the AI Act Article 43 procedure, which also covers the CRA requirements; the exception is CRA "important" or "critical" products assessed under AI Act internal control alone.

But AI Act Article 15 also requires accuracy and robustness, and names AI-specific threats: data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. The CRA does not cover these for you. Also mind the different dates: for high-risk AI, after the Digital Omnibus (Regulation EU 2026/1744), we are talking about 2 December 2027 (Annex III) and 2 August 2028 (Annex I); CRA reporting is running today.

Five things to set up now

1. Map your products: for each distributed product, decide whether it is within CRA scope and document why (especially for "hybrid" SaaS cases).
2. Inventory your components (SBOM): models, open-source libraries, third-party SDKs. Article 13(5) requires due diligence on third-party components, open source included.
3. Write the 24-hour procedure: who decides that a vulnerability is "actively exploited", who notifies on the ENISA platform, who informs customers. Test the chain with a drill.
4. Add AI-specific risks to vulnerability management: prompt injection, training-data extraction, manipulation of purchased models.
5. Set the support period: from 2027 manufacturers will have to handle vulnerabilities for a period matching the product's expected lifetime and, as a rule, no shorter than five years (Art. 13(8)). It needs pricing into contracts today.

What getting it wrong costs

Up to EUR 15 million or 2.5% of worldwide annual turnover for breaching the essential requirements and the obligations in Articles 13 and 14 (Art. 64(2)). Micro and small enterprises cannot be fined merely for a late 24-hour early warning (Art. 64(10)), but they must still notify.

Where to start

If you build AI products, the right question is not "am I high-risk?" but "which of my products are already subject to reporting obligations, and does my procedure hold up in 24 hours?". An independent gap assessment of your CRA scope and its interplay with the AI Act gives you the answer, with priorities and owners, before an authority asks.