The Cyber Resilience Act and the EU AI Act: What AI Product Makers Must Do Now

Last updated: 28 September 2026. General information, not legal advice.

Most AI compliance teams have spent 2026 focused on the EU AI Act. Meanwhile, a second regulation quietly switched on for almost every AI product sold in Europe. Since 11 September 2026, manufacturers of "products with digital elements" must report actively exploited vulnerabilities and severe security incidents under the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), through a new ENISA Single Reporting Platform.

If you build AI-enabled software or hardware, this post explains whether the CRA applies to you, what you must report and how fast, and how the CRA and the AI Act fit together so you can run one programme instead of two.

Why the Cyber Resilience Act matters for AI products

The CRA sets mandatory cybersecurity requirements for hardware and software products with digital elements, including their remote data processing solutions, across their whole lifecycle. It is horizontal: it does not care whether a product uses AI. That is exactly why it catches so many AI products. A SaaS-connected app, an AI-powered desktop tool, an embedded model in an industrial device or a smart consumer product will usually be a product with digital elements.

The timing makes this urgent:

• 11 September 2026: CRA Article 14 reporting obligations apply to manufacturers.
• 11 December 2027: the CRA applies in full, including the essential cybersecurity requirements and conformity assessment.
• 2 December 2027: the AI Act's Annex III high-risk obligations apply (moved from August 2026 by the Digital Omnibus).

The CRA and the AI Act high-risk regime land within nine days of each other. Plan them as one project.

CRA reporting: what is live since 11 September 2026

Under Article 14 CRA, manufacturers must notify two kinds of events that they become aware of (Hogan Lovells Cadwalader):

1. Actively exploited vulnerabilities contained in their products.
2. Severe incidents having an impact on the security of their products.

Notifications go simultaneously to the national CSIRT designated as coordinator and to ENISA, via the Single Reporting Platform (SRP). The SRP routes the report to the CSIRT of your main establishment, which then shares it with CSIRTs in other member states where the product is available.

The three-stage reporting clock

Stage	Deadline
Early warning	Without undue delay, and within 24 hours of becoming aware
Vulnerability or incident notification	Within 72 hours of becoming aware
Final report	Exploited vulnerability: within 14 days after a fix or mitigation is available. Severe incident: within one month after the incident notification

"Aware" means you have a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised your product's security.

Details that trip teams up

• Legacy products are covered. Reporting applies to products placed on the market before full CRA application, and continues after a product's support period ends.
• No retroactive reporting. According to the Commission's final CRA guidance, you do not have to report active exploitation you already knew about before 11 September 2026.
• Users must be told too. Article 14(8) requires you to inform impacted users, and where appropriate all users.
• Registration takes time. Reporters need a personal EU Login account with multi-factor authentication, then registration as an Assigned Representative validated by the CSIRT. ENISA asks manufacturers to start registration only when they actually need to report, so prepare the paperwork and people in advance.
• Voluntary reporting is not in the platform yet. The launch version supports mandatory Article 14 notifications only.
• Open-source stewards get their reporting duties from 11 December 2027.

Further detail is on the Commission's CRA reporting page and ENISA's SRP guidance.

Why AI makes vulnerability reporting harder

AI systems add attack surfaces that classic vulnerability management was not built for: prompt injection, data poisoning, model extraction, jailbreaks that unlock unsafe tool use, and agentic systems that can act on external systems. September 2026 showed this is not theoretical. Several frontier developers disclosed that AI agents accessed third-party systems without authorization during testing, and the UK FCA published a review on 2 September noting that frontier AI is accelerating the identification and exploitation of vulnerabilities (Stephenson Harwood).

For CRA purposes, ask a practical question for each AI-specific weakness: if an attacker is using it in the wild against our product, does it compromise the product's security? If yes, the 24-hour clock may already be running.

The bridge: CRA Article 12 and AI Act Article 15

The two laws are explicitly linked. Article 12 CRA provides that a product with digital elements that is also a high-risk AI system is deemed to comply with the cybersecurity requirements of AI Act Article 15 where:

1. the product meets the CRA's essential cybersecurity requirements in Annex I, Part I;
2. the manufacturer's processes meet the vulnerability-handling requirements in Annex I, Part II; and
3. the achievement of the Article 15 level of cybersecurity protection is demonstrated in the CRA EU declaration of conformity.

Two important limits:

• The presumption covers cybersecurity only. Article 15's accuracy and robustness requirements, and AI-specific threats such as data poisoning and adversarial examples, still need to be addressed on their own terms.
• As a rule, the conformity assessment procedure under the AI Act applies to the high-risk AI system, with the CRA's essential requirements assessed as part of it. Notified bodies competent under the AI Act can assess CRA conformity in that process, subject to the specific carve-outs for important and critical products. Check your product class before choosing a route.

Taylor Wessing's analysis of the AI Act, CRA and Cybersecurity Act is a good deep dive on how these interact.

CRA vs AI Act at a glance

	Cyber Resilience Act	EU AI Act
What it regulates	Cybersecurity of products with digital elements	Safety, fundamental rights and transparency of AI systems and GPAI models
Who is primarily obliged	Manufacturers (plus importers, distributors, open-source stewards)	Providers and deployers (plus importers, distributors)
Reporting trigger	Actively exploited vulnerability or severe security incident	Serious incident involving a high-risk AI system (Article 73)
Reporting deadlines	24h early warning, 72h notification, final report	Generally within 15 days; shorter for widespread infringements or deaths
Reporting channel	ENISA Single Reporting Platform to coordinating CSIRT	National market surveillance authority
Reporting applies from	11 September 2026	With high-risk obligations: 2 December 2027 (Annex III)
Maximum fines	Up to EUR 15M or 2.5% of worldwide turnover for essential requirements	Up to EUR 35M or 7% for prohibited practices; EUR 15M or 3% for most other obligations

One incident, four regulators: build a single triage playbook

A single event affecting an AI product can trigger several reporting duties at once: CRA Article 14 (security of the product), AI Act Article 73 (serious incident with a high-risk system, from December 2027), NIS2 (if you are an essential or important entity) and GDPR Article 33 (personal data breach, 72 hours). Each has its own trigger, clock and recipient.

Build one intake and triage process that asks all four questions at the same time, records the "awareness" timestamp once, and assigns an owner to each notification. Our guide to Articles 72 and 73 covers the AI Act side in detail.

Checklist: what to do this quarter

1. Inventory in-scope products, including legacy versions still in use and products past end of support.
2. Identify the manufacturer entity and coordinating CSIRT for each product line, based on main establishment.
3. Name your reporters and have them create EU Login accounts with MFA now.
4. Define reportability thresholds for "actively exploited" and "severe incident", including AI-specific attack types.
5. Prepare templates mapped to the SRP's mandatory and optional fields, using ENISA's glossary.
6. Wire in intake channels: bug bounty, security researchers, customers, suppliers, model providers and threat intelligence.
7. Draft user notification templates for Article 14(8).
8. Run a tabletop exercise with a realistic AI scenario, such as a prompt-injection exploit being used against customers.
9. Plan one conformity project for late 2027 that covers CRA Annex I and AI Act Articles 9 to 15 together, and use CRA Article 12 to avoid duplicating cybersecurity evidence.

Bottom line

For AI product makers, the Cyber Resilience Act is not a future problem. Its reporting duties are live today, they apply to products already on the market, and the clock starts at 24 hours. The good news is that the CRA and the AI Act were designed to interlock. Get your CRA vulnerability handling right now, and you will have built a large part of your AI Act Article 15 cybersecurity evidence before the high-risk deadline arrives.