EU AI Act vs Cyber Resilience Act: Who Owns Security for AI Products?

When an AI-powered product gets hacked, who answers for it? In the EU, the answer now comes from two regulations. The Cyber Resilience Act (CRA) makes manufacturers of hardware and software products responsible for cybersecurity across the product's whole life cycle. The EU AI Act makes providers of high-risk AI systems responsible for accuracy, robustness and cybersecurity, including defences against attacks no traditional software law anticipated, such as data poisoning and adversarial inputs.

The two laws were designed to fit together, and they meet in a single article: CRA Article 12. Since 11 September 2026, CRA manufacturers have had to report actively exploited vulnerabilities within 24 hours through ENISA's new Single Reporting Platform. The rest of the CRA applies from 11 December 2027, five days after the AI Act's high-risk rules for Annex III systems start on 2 December 2027.

This guide explains which law covers which AI products, how the CRA–AI Act "bridge" works, what each law still requires on its own, and how to build one security programme for AI products sold in the EU.

Cyber Resilience Act: Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements, in force since 10 December 2024
EU AI Act: Regulation (EU) 2024/1689, in force since 1 August 2024
CRA reporting duties: Apply since 11 September 2026: 24-hour early warning, 72-hour notification, then a final report
CRA full application: 11 December 2027
AI Act high-risk duties: 2 December 2027 (Annex III); 2 August 2028 (Annex I products)
The bridge: CRA Article 12, mirrored in AI Act Article 42(3) by the Digital Omnibus on AI: CRA compliance can give a presumption of conformity with AI Act cybersecurity requirements
Harmonised standards: Around 41 CRA standards are in development; none had been cited in the Official Journal as of mid-2026

The short answer

The CRA owns product security for almost every connected hardware and software product, AI or not: secure design, no known exploitable vulnerabilities, secure defaults, security updates, vulnerability handling and incident reporting. The AI Act owns AI-specific trustworthiness for high-risk AI: accuracy, robustness, protection against AI-specific attacks, plus data governance, human oversight and fundamental rights.

For a high-risk AI product that is also a CRA product, the CRA's cybersecurity requirements can satisfy the AI Act's cybersecurity requirement, but not its accuracy and robustness requirements. For the much larger group of AI products that aren't high-risk, the CRA is effectively the main security law.

The CRA owns

Secure-by-design development, vulnerability handling, software bills of materials (SBOMs), security updates for the support period, conformity assessment, CE marking and reporting of exploited vulnerabilities and severe incidents.

The AI Act owns

Accuracy and robustness, defences against data poisoning, model poisoning and adversarial inputs, data governance, human oversight, logging and serious-incident reporting, for high-risk AI.

What the CRA requires from AI product makers

The CRA applies to products with digital elements: hardware and software, including their remote data processing, placed on the EU market and capable of connecting to a device or network. That covers smart cameras with on-device AI, AI-enabled industrial controllers, connected toys with voice assistants, downloadable AI software and many other AI products. Pure software-as-a-service generally sits outside the CRA unless it is the remote data processing of a covered product.

Manufacturers must meet the essential cybersecurity requirements in Annex I:

Part I, product requirements: risk-based design, no known exploitable vulnerabilities at release, secure-by-default configuration, protection of confidentiality, integrity and availability, access control, attack surface reduction, logging and security updates
Part II, vulnerability handling: an SBOM, prompt remediation, regular testing, a coordinated vulnerability disclosure policy, secure update distribution and public advisories once fixes are available
Support period: security updates for the product's expected lifetime, normally at least five years
Conformity: self-assessment for default products; harmonised standards, certification or third-party assessment for "important" Class I and II products and "critical" products

Reporting is already live

Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through ENISA's Single Reporting Platform. That means an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix becoming available for vulnerabilities, or within one month for incidents. Reports go to the designated national CSIRT, with ENISA receiving a copy.

24 hoursto send an early warning on an actively exploited vulnerability, since 11 September 2026

~41harmonised standards requested from CEN, CENELEC and ETSI under mandate M/606

5 yearsnormal minimum support period for security updates

The standards aren't ready yet

As of mid-2026, no CRA harmonised standard had been cited in the Official Journal, and a July 2026 draft amendment pushed drafting deadlines back two months. Until standards are cited, the presumption of conformity under CRA Article 27 isn't available. Important Class I products can't rely on the lighter self-assessment route either.

What the AI Act requires for AI product security

The AI Act's security duties are concentrated in high-risk AI. That covers AI in Annex III use cases (such as critical infrastructure, employment, credit and education) and AI that is part of products regulated under Annex I legislation (such as machinery, toys, medical devices and radio equipment).

Article 15 requires high-risk AI to reach an appropriate level of accuracy, robustness and cybersecurity throughout its life cycle, with measures against AI-specific vulnerabilities:

Data poisoning

Corrupting training data to change model behaviour.

Model poisoning

Tampering with pre-trained components used in training.

Adversarial examples

Inputs crafted to make the model err, also called model evasion.

Confidentiality attacks

Extracting training data or details of the model.

Model flaws

Exploiting weaknesses in model design or logic.

Robustness

Resilience to errors and faults, and controls on feedback loops in systems that keep learning.

On top of that, high-risk AI needs risk management, data governance, technical documentation, logging, transparency, human oversight, a quality management system and post-market monitoring. Providers must report serious incidents under Article 73, which focuses on harm to health, safety, fundamental rights, property or critical infrastructure, not just on security breaches.

If you are working out who owns security for your AI products, I post practical breakdowns of the CRA, the AI Act, NIS2 and ISO 42001 regularly on LinkedIn. Feel free to connect with me there and tell me where your product team is drawing the line.

The bridge: how CRA Article 12 connects the two laws

CRA Article 12 is the rule that stops AI products being certified twice for the same security work. It applies to products that are in scope of the CRA and classified as high-risk AI under AI Act Article 6.

Paragraph	What it says	What it means in practice
Article 12(1): presumption	A high-risk AI product is deemed to meet AI Act Article 15 cybersecurity requirements if it meets CRA Annex I Parts I and II and this is shown in the CRA EU declaration of conformity	Do the CRA security work once and document how it covers AI Act cybersecurity
Carve-out within 12(1)	The presumption is without prejudice to AI Act accuracy and robustness requirements	AI-specific accuracy and robustness still need separate evidence
Article 12(2): one procedure	The AI Act's conformity assessment procedure (Article 43) applies, and AI Act notified bodies can assess CRA requirements	One conformity assessment and one notified body, led by the AI Act route
Article 12(3): exception	For CRA important or critical products that need third-party assessment, where the AI Act would allow internal control, the CRA's procedures apply to the cybersecurity requirements	Stricter CRA assessment can override the AI Act's self-assessment route for cybersecurity
Article 12(4): sandboxes	Manufacturers may join AI regulatory sandboxes	Test CRA and AI Act compliance together with regulators

The Digital Omnibus on AI, in force since 27 July 2026, wrote the same presumption into the AI Act itself as Article 42(3). This was done for visibility; the Omnibus recitals say the interplay between the two laws is unchanged.

Robustness is where the bridge stops

A model can be patched, signed, access-controlled and updated securely, which is everything the CRA asks for, and still be fooled by an adversarial image or skewed by poisoned data. That's why Article 12 keeps AI Act accuracy and robustness requirements outside the presumption.

Who owns security for which AI product?

Product type	CRA	AI Act	Who owns security
Smart home camera with on-device face detection (not high-risk)	Yes	Transparency and general rules only	CRA: the manufacturer owns all product security
AI-enabled industrial machine controller (safety component)	Yes	High-risk via Annex I	Both, through one assessment; CRA covers cybersecurity, AI Act covers robustness
Downloadable AI software sold commercially	Yes, as software placed on the market	Depends on intended purpose	CRA baseline, plus AI Act if high-risk
Cloud-only AI service (SaaS) used for hiring	Generally no	High-risk via Annex III	AI Act owns AI security; NIS2 may cover the operator
Connected medical device with diagnostic AI	No: devices under the MDR are excluded	High-risk via Annex I	MDR plus AI Act
Non-commercial open-source AI library	Generally no	Generally no, unless placed on the market as high-risk AI	Community practice; light CRA steward duties where applicable

This table is an analytical guide. Scope depends on intended purpose, commercial activity and the exact product definition, so check each product individually.

EU AI Act vs CRA: side by side

Dimension	Cyber Resilience Act	EU AI Act
Regulates	Products with digital elements: hardware and software	AI systems and general-purpose AI models
Main duty holder	Manufacturer	Provider, plus deployer duties
Security scope	All cybersecurity risks across the product life cycle	Accuracy, robustness and cybersecurity of high-risk AI, including AI-specific attacks
Applies to non-high-risk AI?	Yes, any in-scope product	Only general duties such as transparency and AI literacy
Key requirements	Annex I Parts I and II: secure design, SBOM, vulnerability handling, updates	Articles 9 to 15: risk management, data, documentation, logs, oversight, robustness
Reporting	Exploited vulnerabilities and severe incidents: 24h / 72h / final, via ENISA's platform	Serious incidents: generally no later than 15 days, sooner for the most severe cases
Reporting live since	11 September 2026	High-risk duties from 2 December 2027 or 2 August 2028
Full application	11 December 2027	Phased, 2025 to 2028
Conformity	Self-assessment or third-party, by product class	Internal control or notified body, by system type
Max penalty	EUR 15M or 2.5% of worldwide turnover	EUR 15M or 3% (high-risk duties); EUR 35M or 7% (prohibited practices)
Enforcer	Market surveillance authorities; CSIRTs and ENISA for reporting	Market surveillance authorities; AI Office for general-purpose AI

Maximum fines as a share of worldwide annual turnover

AI Act: prohibited practices 7%

AI Act: high-risk and most other duties 3%

CRA: essential requirements and core manufacturer duties 2.5%

CRA: other obligations 2%

Each tier also has a fixed euro cap, with the higher of the two amounts applying. Lower caps apply to SMEs under the AI Act.

How the timelines fit together

1 Aug 2024
AI Act enters into force.
10 Dec 2024
CRA enters into force.
2 Feb 2025
AI Act prohibitions and AI literacy duties apply.
11 Jun 2026
CRA rules on notifying conformity assessment bodies apply.
27 Jul 2026
Digital Omnibus on AI enters into force, adding the CRA presumption as AI Act Article 42(3).
2 Aug 2026
AI Act Article 50 transparency duties and penalties apply.
11 Sep 2026
CRA reporting duties apply; ENISA's Single Reporting Platform goes live.
2 Dec 2027
AI Act high-risk duties apply to Annex III systems.
11 Dec 2027
CRA applies in full, including essential requirements and CE marking.
2 Aug 2028
AI Act high-risk duties apply to AI in Annex I products.

December 2027 is a double deadline

For many AI product makers, the AI Act's Annex III date and the CRA's full application date fall nine days apart. Products shipping in early 2028 need both compliance tracks finished, documented and, where required, assessed by a notified body.

A 6-step plan for one AI product security programme

Classify every product under both laws
For each product, decide whether it is a CRA product with digital elements (default, important or critical) and whether it contains high-risk AI under the AI Act. That determines whether Article 12 applies.
Stand up CRA vulnerability reporting now
Reporting has applied since 11 September 2026. Register on ENISA's platform, set up a product security incident response team, and test the 24-hour early-warning process, including vulnerabilities in AI components and third-party models.
Extend secure development to AI
Apply CRA secure-by-design practices to models and data pipelines: signed model artefacts, an AI bill of materials alongside the SBOM, dependency scanning for AI libraries and secure model update channels.
Add AI-specific robustness testing
Test against data poisoning, adversarial examples, model extraction and prompt injection, using MITRE ATLAS techniques. Keep this evidence separately, because the CRA presumption doesn't cover robustness.
Write one declaration and one technical file
For high-risk AI products, document in the CRA declaration of conformity how CRA compliance covers AI Act cybersecurity, and keep a single technical file that a notified body can assess under both laws.
Unify incident handling
Use one triage process that checks CRA exploited-vulnerability and severe-incident criteria alongside AI Act serious-incident criteria, with clear roles for suppliers of models and components.

Common mistakes to avoid

Assuming CRA reporting starts in December 2027, when it began on 11 September 2026
Treating CRA compliance as full AI Act Article 15 compliance, ignoring accuracy and robustness
Leaving models, weights and AI libraries out of the SBOM and vulnerability handling
Assuming cloud-only AI services fall under the CRA
Waiting for harmonised standards before starting design and documentation work

A prompt to map your AI products to the CRA and the AI Act

Paste in your product details to get a first-draft compliance map. Your product security and legal teams should review it.

CRA + EU AI Act product security mapping prompt

You are a product security and AI regulatory specialist with
deep knowledge of the Cyber Resilience Act (Regulation (EU)
2024/2847), the EU AI Act (Regulation (EU) 2024/1689) as amended
by the Digital Omnibus on AI, and MITRE ATLAS.

Our product portfolio:
[for each product: what it does; hardware, software or SaaS;
whether it connects to devices or networks; AI functions and
model source (in-house, open-weight, API); intended purpose and
users; EU markets; whether it is a safety component or used in
an Annex III area; current secure development, SBOM and
vulnerability handling practices]

Produce:
1. For each product: CRA scope and class (default, important
   Class I or II, critical) and AI Act classification.
2. Whether CRA Article 12 applies, and which AI Act Article 15
   requirements it covers and which it does not.
3. A gap table against CRA Annex I Parts I and II, including
   AI-specific items (model artefacts, AI BOM, model updates).
4. The AI robustness tests we need, mapped to MITRE ATLAS.
5. A combined incident triage flow for CRA reporting (24h/72h)
   and AI Act serious-incident reporting.
6. A plan to 11 December 2027, with owners.

Use only what I provide and mark uncertain points UNKNOWN.

The CRA makes sure your AI product can't be broken into. The AI Act makes sure it can't be tricked into the wrong answer. Security for AI products needs both. — Kumail Mehdi

Frequently asked questions

Does the Cyber Resilience Act apply to AI products?

Yes, if the AI product is a product with digital elements, meaning hardware or software placed on the EU market that can connect to a device or network. Pure SaaS is generally out of scope unless it is the remote data processing of a covered product.

Does CRA compliance satisfy the AI Act?

Partly. Under CRA Article 12, now mirrored in AI Act Article 42(3), a high-risk AI product that meets CRA Annex I requirements is deemed to meet AI Act Article 15 cybersecurity requirements, if this is shown in the CRA declaration of conformity. Accuracy and robustness requirements still apply separately.

When do CRA obligations apply?

Reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026. Rules on conformity assessment bodies applied from 11 June 2026. The rest of the CRA, including the essential requirements and CE marking, applies from 11 December 2027.

Do I need two conformity assessments for a high-risk AI product?

Usually not. CRA Article 12(2) says the AI Act's conformity assessment procedure applies, and AI Act notified bodies can also assess the CRA requirements. The exception is CRA important or critical products, where the CRA's stricter procedures apply to cybersecurity if the AI Act would only require internal control.

Are AI models covered by the CRA's vulnerability handling?

Where a model or AI library is part of a CRA product, its vulnerabilities are product vulnerabilities. They should be tracked in the SBOM, fixed through secure updates and reported if actively exploited.

What are the CRA penalties?

Up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and core manufacturer duties, whichever is higher, and up to EUR 10 million or 2% for other obligations.

Master AI governance in 6 months, 15 minutes a week

AI Governance – Decoded is my weekly newsletter that explains the EU AI Act, the Cyber Resilience Act, NIS2, ISO 42001 and the frameworks around them in plain language. One short, practical read every week.

Join the newsletter

Building secure AI products for the EU market? Let's connect on LinkedIn. I'm always glad to compare notes on AI product security.

EU AI Act vs Cyber Resilience Act: Who Owns Security for AI Products?