The Cyber Resilience Act and the EU AI Act are separate regulations with separate scopes, separate authorities, and separate penalty regimes. CRA and EU AI Act apply concurrently to a large and growing category of products: AI systems that are also products with digital elements.

An AI-powered connected device, an AI feature embedded in commercial software, or an AI system distributed as a standalone software product will frequently fall within both. Where that happens, both sets of obligations apply in full. Neither displaces the other.

The overlap between CRA and EU AI Act is not evenly distributed. Cybersecurity requirements duplicate substantially and can be satisfied once. Documentation requirements overlap in content but differ in structure and recipient. Reporting obligations run on different clocks to different bodies and cannot be consolidated. Conformity assessment routes are separate exercises.

The most immediate practical issue is timing. nd bound on 11 September 2026. AI Act enforcement for GPAI models began on 2 August 2026. High-risk AI obligations follow in December 2027 and CRA full application in December 2027. Organisations subject to both CRA and EU AI Act are managing four distinct compliance deadlines across eighteen months.

Key Definitions: CRA and EU AI Act

Term	Definition
CRA	Cyber Resilience Act, Regulation (EU) 2024/2847. In force since 10 December 2024
EU AI Act	Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744
Product with digital elements	Any software or hardware product, and its remote data processing solutions, placed on the EU market with a direct or indirect data connection
High-risk AI system	An AI system under Article 6 of the AI Act, either an Annex I product safety component or an Annex III use case
Manufacturer	The CRA term for the entity placing a product on the EU market under its own name
Provider	The AI Act term for the entity placing an AI system on the market under its own name
SBOM	Software bill of materials. Required under CRA Annex I
Annex IV	The AI Act technical documentation requirements for high-risk AI systems
SRP	Single Reporting Platform. The ENISA-operated CRA reporting channel
Notified body	An independent conformity assessment body designated under either regulation

Do Both CRA and EU AI Act Regulations Apply to the Same Product?

Frequently, yes. The scope tests are independent and a product can satisfy both.

CRA scope. Any product with digital elements placed on the EU market. This means any software or hardware product whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. In practice this covers most modern software and most connected hardware.

AI Act scope. Any AI system placed on the EU market or put into service, or whose output is used in the EU. Obligations scale by risk tier, with the substantive requirements concentrated on high-risk systems and GPAI models.

The intersection is large:

Product	CRA applies	AI Act applies	Combined position
AI-powered CV screening SaaS	Yes, software with digital elements	Yes, Annex III employment	Full CRA plus full high-risk AI Act
Connected medical device with AI diagnostics	CRA excluded, MDR governs	Yes, Annex I product safety route	AI Act plus MDR, CRA carve-out applies
AI-enabled industrial sensor	Yes	Depends on Machinery Regulation position post-Omnibus	Assess both, classification uncertain
Enterprise chatbot product	Yes	Limited risk, Article 50 transparency	CRA in full, AI Act transparency only
Standalone GPAI model via API	Yes if placed on market as a product	Yes, Chapter V	CRA plus GPAI obligations
Smart home camera with facial recognition	Yes, Important Class I	Yes, Annex III biometrics	Full CRA plus full high-risk AI Act
Non-AI connected thermostat	Yes	No	CRA only
AI model used purely internally, never placed on market	No	Depends on putting into service	Assess separately

The Sector Carve-Outs

The CRA excludes products already covered by equivalent sector cybersecurity regimes, including medical devices under the MDR and IVDR, motor vehicles, and civil aviation products. The AI Act does not exclude these; it routes them through the Annex I product safety pathway instead.

The consequence is asymmetric. A medical device with AI diagnostics is outside the CRA but firmly inside the AI Act. An industrial connected sensor may be inside the CRA and, following the Digital Omnibus, in an uncertain position under the AI Act because the Machinery Regulation moved from Annex I Section A to Section B.

Where CRA and EU AI Act Obligations Overlap

Cybersecurity Requirements

This is where the duplication is greatest and where a single body of work can satisfy both.

AI Act Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity, and to be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities.

CRA Annex I requires products with digital elements to be designed and developed to ensure an appropriate level of cybersecurity, delivered without known exploitable vulnerabilities, with secure default configuration and appropriate protection against unauthorised access.

The specific AI threat vectors, data poisoning, model poisoning, adversarial examples, and model extraction, are addressed under AI Act Article 15 and are within the CRA’s general security requirement for products containing AI components.

Requirement	AI Act	CRA
Cybersecurity by design	Article 15(5)	Annex I, Part I
No known exploitable vulnerabilities at release	Implicit in Article 15	Annex I, Part I, explicit
Secure default configuration	Not expressly required	Annex I, Part I, explicit
Resilience to adversarial manipulation	Article 15(5), AI-specific	Annex I general requirement
Vulnerability handling process	Not expressly required	Annex I, Part II, explicit
Security updates for support period	Not expressly required	Annex I, Part II, explicit

A security programme built to CRA Annex I will substantially cover AI Act Article 15. The reverse is not true: Article 15 does not require a vulnerability handling process, a support period, or security update delivery.

Practical conclusion: build to CRA Annex I and map the AI-specific threat vectors into it. This satisfies both.

Documentation

Both regulations require technical documentation. The content overlaps significantly. The structure and the recipient do not.

Documentation element	AI Act Annex IV	CRA Annex VII
General product description	Required	Required
Intended purpose	Required	Required
System architecture	Required	Required
Development methodology	Required	Required
Training data description	Required	Not applicable
Data governance practices	Required, Article 10	Not applicable
Risk management system	Required, Article 9	Cybersecurity risk assessment required
Testing and validation results	Required	Required
Accuracy metrics	Required	Not applicable
Human oversight measures	Required, Article 14	Not applicable
SBOM	Not required	Required, Annex I
Vulnerability handling process	Not required	Required
Support period	Not required	Required
Standards applied	Required	Required
Declaration of conformity	Required, Article 47	Required

Neither document is a subset of the other. Annex IV carries the AI-specific content: training data, accuracy, human oversight, fundamental rights. CRA Annex VII carries the product security content: SBOM, vulnerability handling, support period.

The overlapping sections, product description, architecture, development methodology, testing, and standards, should be maintained once and rendered into both formats rather than drafted twice.

The SBOM Question in CRA

The CRA requires a software bill of materials in a commonly used machine-readable format covering at least top-level dependencies. The AI Act does not require an SBOM.

However, an SBOM produced for CRA purposes has direct value for AI Act compliance. Annex IV requires a description of the system architecture and the software components used. A current SBOM answers part of that requirement and does so in a form a market surveillance authority can process.

Where an AI system is also a product with digital elements, the CRA SBOM should cover the AI components, including model files, inference libraries, and any third-party models integrated into the product.

Where CRA and EU AI Act Obligations Diverge

Reporting: Two Clocks, Two Bodies

This is the area where consolidation of CRA and EU AI Act requirements is not possible and where organisations are most likely to fail.

Feature	CRA Article 14	AI Act Article 73	AI Act Article 55 (GPAI)
Trigger	Actively exploited vulnerability or severe incident	Serious incident involving high-risk AI system	Serious incident involving systemic risk GPAI model
First deadline	24 hours	15 days	Without undue delay
Second stage	72 hours	Not applicable	Not applicable
Final report	14 days after corrective measure available	Not separately specified	Not separately specified
Recipient	Coordinating CSIRT and ENISA via SRP	National market surveillance authority	AI Office
Channel	Single Reporting Platform	National authority channel	AI Office
In force since	11 September 2026	2 December 2027 for Annex III	2 August 2025

A single event can trigger both. An actively exploited vulnerability in an AI-powered product that causes serious harm is a CRA Article 14 report within 24 hours and an AI Act Article 73 report within 15 days, to different bodies through different channels.

The reports are not interchangeable. Filing on the SRP does not discharge the AI Act obligation. Notifying a market surveillance authority does not discharge the CRA obligation.

Practical conclusion: one incident response process with two output paths, triggered by a single assessment. The 24-hour CRA clock is the binding constraint, so the process must be designed around it.

Conformity Assessment: CRA and EU AI Act

Both regulations require conformity assessment before market placement, and they are separate exercises with separate classification schemes.

Feature	AI Act	CRA
Classification basis	Risk tier under Article 6	Product class under Annex III
Default route	Internal control, Annex VI	Manufacturer self-assessment
Third-party route	Notified body for certain biometric and Annex I systems	Notified body for Important Class II and Critical
Presumption of conformity	Harmonised standards under Article 40	Harmonised standards
CE marking	Article 48	Required
Declaration of conformity	Article 47	Required
Registration	EU database, Article 49	Not required

A product can be default-tier under the CRA and high-risk under the AI Act, or Important Class II under the CRA and minimal risk under the AI Act. The classifications are independent.

Where both require notified body involvement, the same notified body may be able to perform both assessments if designated under both regulations. Capacity is finite and demand will concentrate in 2027.

Support Periods and Lifecycle in CRA and EU AI Act

The CRA requires manufacturers to provide security updates for a support period, generally a minimum of five years, and to make the support period visible at the point of purchase.

The AI Act has no equivalent support period obligation. It requires post-market monitoring under Article 72 and retention of technical documentation for ten years under Article 18, but does not require the manufacturer to keep issuing security updates for a defined period.

This is a genuine gap rather than an overlap. An AI system that is also a product with digital elements carries the CRA support obligation. An AI system outside CRA scope, such as a medical device AI, does not, though sector legislation may impose an equivalent.

CRA and EU AI Act: Enforcement and Penalties

The CRA and EU AI Act regulations have separate enforcement architectures and separate penalty ceilings. Both can be applied to the same organisation for the same product.

Infringement	Regulation	Maximum penalty
Prohibited AI practices	AI Act Article 99(3)	€35m or 7% of worldwide turnover
High-risk AI or GPAI obligations	AI Act Article 99(4)	€15m or 3% of worldwide turnover
CRA Annex I essential requirements	CRA	€15m or 2.5% of worldwide turnover
Other CRA manufacturer obligations, including reporting	CRA	€10m or 2% of worldwide turnover
Misleading information to authorities	Both	AI Act €7.5m or 1%; CRA €5m or 1%

Enforcement bodies differ. CRA enforcement sits with national market surveillance authorities designated under that regulation. AI Act enforcement for high-risk systems sits with national market surveillance authorities designated under the AI Act, and for GPAI models with the AI Office. These may or may not be the same national body depending on member state designation.

Both CRA and EU AI Act regulations permit market withdrawal and recall. For a software product, a withdrawal order under either regulation is a more serious commercial event than the fine.

The Combined CRA and EU AI Act Timeline

Date	Obligation	Regulation
2 February 2025	Prohibited practices, AI literacy	AI Act
2 August 2025	GPAI obligations, GPAI authorised representative	AI Act
11 June 2026	Member states designate CRA authorities and notified bodies	CRA
2 August 2026	AI Office enforcement powers, Article 50 transparency	AI Act
11 September 2026	CRA reporting obligations, Single Reporting Platform live	CRA
2 December 2026	Article 50(2) synthetic content marking for existing systems	AI Act
2 December 2027	Annex III high-risk AI obligations	AI Act
11 December 2027	CRA full application, Annex I, SBOM, CE marking	CRA
2 August 2028	Annex I product-embedded high-risk AI obligations	AI Act

December 2027 is the convergence point. Organisations subject to both face full CRA application and Annex III high-risk AI obligations within nine days of each other.

Building One Programme, Not Two

The efficient approach treats the shared facts as a single record and the obligations as views onto it.

What can be built once

• Security architecture to CRA Annex I, with AI-specific threat vectors mapped in, satisfying AI Act Article 15.
• SBOM covering all components including AI models and inference libraries, serving CRA Annex I and supporting AI Act Annex IV architecture documentation.
• Product description, architecture documentation, development methodology, and testing records, maintained once and rendered into both Annex IV and CRA Annex VII formats.
• A single incident detection and assessment process, terminating in two reporting paths on different clocks.
• Supplier contract requirements covering SBOM provision, vulnerability notification, and, for AI components, the Article 53 downstream information a GPAI provider must supply.

What must be built separately

• Risk management system under AI Act Article 9, which addresses risks to health, safety, and fundamental rights rather than cybersecurity risk.
• Data governance under Article 10, covering training data quality and bias examination.
• Human oversight design under Article 14.
• Fundamental Rights Impact Assessment under Article 27 where the deployer falls within scope.
• Vulnerability handling process and support period commitments under CRA Annex I Part II.
• Conformity assessment for each regulation against its own classification.
• Reporting submissions, which run to different bodies on different clocks and cannot be consolidated.