AI Act and CRA: what overlaps for AI products with digital elements

The short answer

An AI system embedded in or distributed as a product with digital elements (hardware or software with network connectivity) may be subject to both the EU AI Act and the Cyber Resilience Act. The two regulations share cybersecurity requirements but have different scope criteria, conformity assessment paths, and enforcement timelines. Running one dual-mapped compliance programme is more efficient than treating them separately.

Who this applies to

You are dual-regulated under AI Act + CRA if your product meets both:

Typical dual-regulated products:

Out of scope for CRA (even if in AI Act scope): pure cloud AI services with no embedded product component, AI systems that are free and open-source software not placed on the market for commercial purposes.

• AI Act scope — Your product contains an AI system as defined in Art. 3(1): a machine-based system designed to operate with varying levels of autonomy that generates outputs such as predictions, recommendations, decisions, or content.
• CRA scope — Your product is a product with digital elements — hardware or software with direct or indirect network connectivity — placed on the EU market.
• Connected medical devices with AI-powered diagnostics (also likely MDR-regulated)
• Industrial automation systems with ML-based process control
• Smart cameras or sensors with on-device inference
• Enterprise software products with AI features distributed via network update

Shared obligations

| Obligation | AI Act reference | CRA reference |

|---|---|---|

| Cybersecurity risk management | Art. 9 (risk management system) | Annex I Part I §1 |

| Robustness and security by design | Art. 15 (accuracy, robustness, cybersecurity) | Annex I Part I §2 |

| Logging and monitoring capability | Art. 12 (logging) | Annex I Part I §2(8) |

| Technical documentation | Art. 11 + Annex IV | Art. 31 + Annex VII |

| Incident and anomaly reporting | Art. 73 (serious incidents) | Art. 14 (actively exploited vulnerabilities) |

| Post-market monitoring | Art. 72 | Annex I Part II §2 |

| Vulnerability handling | — implied Art. 72 | Annex I Part II §1 + Art. 14 |

For these areas, a single cybersecurity risk assessment, a single technical documentation set, and a shared evidence base can satisfy both regulations — provided both frameworks are explicitly referenced.

Where they diverge

| Dimension | AI Act | CRA |

|---|---|---|

| Subject | AI systems (by risk class) | Products with digital elements (by connectivity) |

| Risk classification | Prohibited / High-risk / Limited / Minimal | Important class I / Important class II / Default |

| Conformity assessment | Self-assessment (most) or notified body (Annex III high-risk) | Self-assessment or third-party (class II) |

| CE marking | Required for high-risk AI systems | Required for all in-scope products |

| Key deadline | High-risk AI (Annex III): August 2026; General-purpose AI: August 2025 | Art. 14: September 2026; Full: December 2027 |

| Enforcement body | National market surveillance authority (AI) | National market surveillance authority (product safety) |

| Penalty | Up to €35M or 7% global turnover (prohibited AI) | Up to €15M or 2.5% global turnover |

Technical documentation: one set, dual-mapped

Both regulations require technical documentation before placing the product on the market. The content overlaps significantly:

AI Act Annex IV requires:

CRA Annex VII requires:

Dual-compliance approach: Produce one technical documentation set with sections mapped to both Annex IV (AI Act) and Annex VII (CRA). A cross-reference table in the document header is sufficient for audit purposes.

• General description of the AI system
• Description of the development process
• Monitoring, functioning, and control measures
• Description of the risk management system
• Data governance measures
• Post-market monitoring plan
• General description of the product
• Design and development documentation
• Information on cybersecurity measures
• Security testing reports
• SBOM

Cybersecurity requirements: AI Act Art. 15 vs CRA Annex I

AI Act Art. 15 requires that high-risk AI systems achieve appropriate levels of:

CRA Annex I Part I §2 requires security-by-design measures including:

Key difference: AI Act cybersecurity requirements focus on resilience against adversarial manipulation of AI behaviour (model robustness, data poisoning, adversarial examples). CRA focuses on traditional product cybersecurity (network attack surface, vulnerability management, secure update). Both apply — they are complementary, not redundant.

• Accuracy — consistent performance across operating conditions
• Robustness — resilience to errors, faults, and adversarial inputs
• Cybersecurity — resilience against attempts by unauthorised third parties to alter use, outputs, or performance
• No known exploitable vulnerabilities at time of placing on the market
• Secure by default configuration
• Protection of stored, transmitted, and processed data
• Minimisation of the attack surface
• Security update capability

SBOM for AI products

CRA requires a machine-readable SBOM (Annex I Part II §1). For AI products, the SBOM should include:

An AI product SBOM that omits model provenance and inference runtime creates a gap under both CRA and AI Act traceability requirements.

• All software dependencies (standard)
• AI model artefacts — model weights, ONNX/GGUF/TensorRT files, and their provenance
• Training framework — PyTorch, TensorFlow, JAX versions
• Inference runtime — ONNX Runtime, TensorRT, llama.cpp versions

Incident reporting: two parallel workflows

| Event type | AI Act | CRA |

|---|---|---|

| Serious incident (death, health, property, fundamental rights) | Notify national MSA within 15 days | Not required under CRA |

| Actively exploited vulnerability | Not specifically addressed | Notify ENISA within 24h (Art. 14) |

| Malfunctioning affecting safety | Art. 73 serious incident report | May trigger CRA incident notification |

If the same event qualifies under both frameworks, both notification tracks apply simultaneously.

Conformity assessment paths

For a product that is both high-risk AI (Annex III) and a CRA Important Class II product:

In practice, a single conformity assessment engagement covering both regulations is possible if the CAB is notified for both. Coordinating this early (pre-design-freeze) is significantly more cost-effective than sequential assessments.

• AI Act: Third-party conformity assessment by a notified body is required for Annex III high-risk AI systems in categories that do not have harmonised standards enabling self-assessment.
• CRA Class II: Third-party assessment by a conformity assessment body is required.

Practical steps for dual compliance

• Scope both regulations independently — use the AI Act applicability checker and CRA Scope Checker
• Map shared obligations — identify which technical documentation sections, risk assessments, and evidence artefacts satisfy both
• Build one SBOM including AI model provenance
• Establish one CVD policy referencing both CRA Art. 14 and AI Act Art. 72 post-market monitoring
• Document two notification workflows — Art. 73 (AI Act) and Art. 14 (CRA)
• Single CE marking process — coordinate technical documentation and conformity assessment to cover both declarations

Key deadlines

| Obligation | Deadline |

|---|---|

| AI Act — General-purpose AI (GPAI) | August 2025 |

| AI Act — High-risk AI (Annex III) | August 2026 |

| CRA Art. 14 — Vulnerability reporting | 11 September 2026 |

| CRA — Full manufacturer obligations | 11 December 2027 |

Tools on NexCyber

• CRA Scope Checker — confirm CRA applicability and risk class
• 144-obligation gap assessment — maps CRA, AI Act, NIS2, DORA and RED in one assessment
• MRCC — Machine-Readable Compliance Certificate

Further reading

This page provides regulatory guidance for informational purposes. It is not legal advice. AI Act and CRA implementing acts and harmonised standards are still being developed. For compliance decisions, consult the applicable national competent authority or a qualified legal adviser.

NexCyber — EU Market Access Compliance Platform

• CRA Article 14 — vulnerability reporting workflow
• SBOM requirements under CRA
• NIS2 × CRA overlap