CRA and AI Act: Do You Have to Comply with Both - and Can the Work Be Shared?
Yes, both can apply to the same product - and yes, the compliance work can largely be shared. If your AI system is embedded in, or is itself, a product with digital elements (PDE), the Cyber Resilience Act (Regulation (EU) 2024/2847) and the EU AI Act (Regulation (EU) 2024/1689) both have a claim on it. The good news: the EU deliberately designed a bridge between the two so that a single cybersecurity assessment under the CRA can count toward the AI Act's cybersecurity expectations - you do not need two separate security programmes.
This article is general guidance on the Cyber Resilience Act and the EU AI Act, not legal advice. Confirm specifics against the official regulation texts and seek qualified legal or compliance advice for your situation.
Key points
- Both regimes can apply to the same product if it has digital elements and contains AI.
- They are complementary, not duplicative. The CRA governs product cybersecurity; the AI Act governs AI risk classification, transparency, and (for high-risk systems) its own conformity assessment.
- CRA Article 12 is the bridge. A product that meets the CRA's essential cybersecurity requirements (Annex I, Parts I and II) is deemed to comply with the AI Act's cybersecurity requirements under Article 15 - one workstream, not two.
- High-risk AI products still need an AI Act conformity assessment for accuracy, robustness, human oversight, and other non-cybersecurity obligations. CRA compliance only covers the cybersecurity slice.
- Timelines are converging but not identical. CRA reporting obligations start 11 September 2026; full CRA application is 11 December 2027. High-risk AI obligations under the AI Act have been deferred - pending formal adoption of the Digital Omnibus - to 2 December 2027 (standalone Annex III systems) or 2 August 2028 (AI embedded in regulated products).
- Harmonised standards are not yet finalised. The presumption-of-conformity machinery that underpins both regimes is still being built.
What each regulation actually covers
The two laws have different objects, different scopes, and different conformity routes. Understanding that distinction is the starting point for any dual-compliance strategy.
The Cyber Resilience Act (CRA)
The CRA - Regulation (EU) 2024/2847 - entered into force on 10 December 2024, with vulnerability reporting obligations applying from 11 September 2026 and full application from 11 December 2027. It is a horizontal product regulation: it applies to any hardware or software product that connects to a device or network and is placed on the EU market, including the manufacturer's own remote data processing that is integral to the product's functions.
The CRA's core obligations are:
- Essential cybersecurity requirements (Annex I, Part I): secure-by-design and secure-by-default architecture, protection against known vulnerabilities, secure configuration, logging, and protection of data and communications.
- Vulnerability handling (Annex I, Part II): coordinated disclosure, security update processes, and lifecycle risk management.
- Conformity assessment and CE marking, with the route depending on your product class (default, important Class I/II, or critical - see our post on CRA product classes).
- Vulnerability and incident reporting to ENISA from 11 September 2026.
The CRA does not care whether your product contains AI. If it connects to a network or device, it is in scope.
The EU AI Act
The AI Act - Regulation (EU) 2024/1689 - phases in across 2025-2027, with general provisions and prohibited-practice rules from early 2025, and high-risk system obligations now deferred under the Digital Omnibus provisional agreement to 2 December 2027 (standalone Annex III systems) or 2 August 2028 (AI embedded in regulated products). Confirm sub-dates against the official AI Act text and monitor the Digital Omnibus adoption, which was not yet formally published in the Official Journal as of the date of this article.
The AI Act's obligations scale with risk classification:
- Prohibited practices - banned outright (e.g. social scoring, certain biometric categorisation).
- High-risk AI systems (Annex III and Annex I use cases) - the most demanding tier: risk management system, technical documentation, data governance, human oversight, transparency to deployers, logging, and a conformity assessment before market placement.
- General-purpose AI models - transparency and (for systemic-risk models) additional obligations.
- Limited-risk systems - mainly transparency obligations.
Critically, Article 15 of the AI Act requires that high-risk AI systems "achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle." That cybersecurity requirement is where the CRA steps in.
Where the two regimes overlap
Many AI systems are embedded in, or are themselves, products with digital elements - a connected medical device running a diagnostic model, a smart camera with on-device inference, a security appliance with anomaly-detection AI, or a software product that connects to a network and uses a machine-learning component. In all of these cases, both the CRA and the AI Act can apply simultaneously.
The dual-compliance burden is real. Controls get duplicated across teams, evidence is produced twice in different formats, and security, risk, product, and AI departments end up working from different regulatory playbooks. The EU's design intent is to prevent exactly that.
The bridge: CRA Article 12
Under CRA Article 12(1), a product with digital elements that is also classified as a high-risk AI system under AI Act Article 6 is deemed to comply with the AI Act's cybersecurity requirements (Article 15) if it meets the essential cybersecurity requirements in CRA Annex I, Parts I and II, and demonstrates this in its EU Declaration of Conformity.
In plain English: satisfy the CRA's cybersecurity requirements, document it properly, and you have simultaneously satisfied the AI Act's cybersecurity expectations. You do not run two separate cybersecurity evaluations.
What CRA Annex I, Part I covers (the product-side requirements):
- Secure-by-design and secure-by-default architecture
- Protection against known vulnerabilities at time of placing on the market
- Secure configuration, access control, and data minimisation
- Logging and protection of data in transit and at rest
What CRA Annex I, Part II covers (the process-side requirements):
- Vulnerability identification and handling throughout the support period
- Coordinated vulnerability disclosure
- Security update processes and lifecycle risk management
Both parts must be satisfied for the deemed-compliance bridge to apply.
The bridge is cybersecurity-only. CRA Article 12 does not relieve you of the AI Act's other high-risk obligations — accuracy, robustness, data governance, human oversight, transparency, logging, and the quality management system all remain squarely under the AI Act. The CRA covers the security slice; the AI Act covers everything else.
Who runs the conformity assessment?
This is where it gets slightly technical, but the principle is straightforward:
- For most products (default and important Class I): the AI Act's conformity assessment procedure (Article 43) is the primary route and covers both AI Act and CRA cybersecurity aspects in a single procedure. Notified bodies competent under the AI Act are also competent to assess CRA cybersecurity requirements.
- For important Class II and critical products (CRA Annexes III and IV): where those products are subject to mandatory third-party CRA assessment or a European cybersecurity certificate, the CRA conformity procedure governs the cybersecurity aspects, even when the AI Act's internal control procedure would otherwise apply. The result is a split assessment - CRA third-party assessment for cybersecurity, AI Act internal control for everything else.
The practical upshot: for the vast majority of AI products in scope of both regimes, one conformity assessment covers both. Only the higher-risk CRA product classes create a more complex split.
The standards gap - and why it matters right now
The presumption-of-conformity machinery that makes the CRA bridge most straightforward to use depends on harmonised standards. As of June 2026, no CRA harmonised standard has been published in the Official Journal of the EU, meaning the Article 27 presumption of conformity is not yet available for any product category.
The EN 40000 series (horizontal standards under Standardisation Request M/606) is the cornerstone of the CRA's technical framework. The public enquiry on the EN 40000-1-4 generic security requirements standard - the part that maps CRA essential requirements to specific security controls - is expected to run from mid-July to mid-November 2026, with publication targeted for October 2027. The first standards (vocabulary, principles, vulnerability handling) are expected to be delivered in the second half of 2026, with Official Journal citation to follow on a timetable the Commission has not yet confirmed.
This matters for dual-compliance planning because:
- Without a cited harmonised standard, you cannot rely on the automatic presumption of conformity - you must demonstrate compliance against the Annex I essential requirements directly, using your own technical documentation and risk assessment.
- The same gap affects the AI Act's cybersecurity bridge: the deemed-compliance mechanism in CRA Article 12 works whether or not harmonised standards are in place, but the evidence you need to produce is more bespoke until the standards land.
Don't wait for the standards. The absence of harmonised standards does not prevent you from building genuine product security or from demonstrating compliance — it just means you rely on your own risk-based evidence rather than a standard's presumption. Start with CRA Annex I and build your technical documentation now. The standards, when they arrive, will make it easier to demonstrate what you have already done.
The AI Act timeline update: Digital Omnibus
One important development as of June 2026: the Council of the EU and the European Parliament reached a provisional political agreement on 7 May 2026 on the Digital Omnibus on AI, which defers the high-risk AI system obligations. Under the provisional agreement, high-risk AI obligations for standalone Annex III systems are deferred to 2 December 2027, and for AI embedded in regulated products (Annex I) to 2 August 2028. Formal adoption and Official Journal publication were expected before 2 August 2026 - confirm the current status before relying on these dates.
The deferral does not change the underlying obligations; it changes when they apply to new products placed on the market. The CRA timeline is unaffected.
What about pure SaaS or cloud AI?
If your AI product is delivered purely as a cloud service - with no associated installable software, no hardware, and no remote data processing that is integral to a connected product - it is generally outside the CRA's scope. NIS2 is the more relevant cybersecurity regime for those services. See our post on CRA vs NIS2: which EU cyber rule applies to your software for a detailed breakdown of that boundary.
The AI Act, by contrast, applies to AI systems regardless of how they are delivered - so a pure SaaS AI product still needs to be classified under the AI Act's risk tiers.
What to do: a practical four-step approach
First, determine whether your product is a PDE in scope of the CRA — does it connect to a device or network? Does it include remote data processing integral to its functions? Use our scope checker as a starting point. Then, separately, classify your AI system under the AI Act: is it prohibited, high-risk (Annex III or Annex I), general-purpose, or limited-risk? These are two independent questions with different answers — a product can be in CRA scope without being high-risk AI, and vice versa.
If both regimes apply, resist the temptation to run two separate programmes. The CRA's Article 13 risk assessment and the AI Act's Article 9 risk management system share significant common ground — both require you to identify risks, implement mitigations, and document your reasoning. Build a single security and technical-documentation backbone that satisfies both. The CRA Article 13 risk assessment is a natural anchor: it is the document that connects your product's real-world risks to the specific security measures you have put in place.
If your product is a PDE in CRA scope and a high-risk AI system under the AI Act, structure your CRA Annex I compliance work so that it explicitly demonstrates the cybersecurity level required by AI Act Article 15. Include a statement to that effect in your EU Declaration of Conformity. This is the mechanism CRA Article 12 provides — use it deliberately, not as an afterthought. Your conformity assessment body (if you need one) should be briefed to assess both sets of requirements in a single procedure.
The CRA's vulnerability reporting obligations apply from 11 September 2026. Full CRA application is 11 December 2027. High-risk AI obligations (pending formal Omnibus adoption) are deferred to 2 December 2027 (Annex III) or 2 August 2028 (Annex I products). Harmonised CRA standards are expected in the second half of 2026 but are not yet in the Official Journal. Monitor the European Commission's CRA page and the AI Act page for updates. Our deadlines tracker and compliance checklist are updated as the picture develops.
The dual-compliance decision tool
Use this interactive tool to quickly assess whether both regimes apply to your product and what your priority actions are.
The bottom line
The CRA and the AI Act are not competing regimes - they are complementary layers of the same EU digital product framework. The CRA sets the cybersecurity floor for any connected product; the AI Act adds risk classification, transparency, and governance obligations for AI systems. Where a product sits in both scopes, CRA Article 12 provides a deliberate, legally grounded mechanism to avoid running two separate cybersecurity programmes.
The practical discipline is straightforward: map your product against both regimes early, build a single security and technical-documentation backbone, and use your CRA conformity work explicitly to satisfy the AI Act's cybersecurity expectations. Don't let two separate teams produce two separate sets of evidence for the same underlying security controls.
The standards and guidance are still developing - harmonised CRA standards are not yet in the Official Journal, and the AI Act's high-risk obligations are in flux pending the Digital Omnibus. That is not a reason to wait. It is a reason to build on the essential requirements now, so that when the standards land, they confirm what you have already done.
Stay current as both regimes develop. Subscribe to The CRA Brief — a regular digest covering CRA and AI Act developments, harmonised standards updates, and practical compliance guidance for product teams building for the EU market.
Regulation references: Cyber Resilience Act - Regulation (EU) 2024/2847 · EU AI Act - Regulation (EU) 2024/1689 · European Commission CRA page · European Commission AI Act page
Related reading
Your CRA Compliance Checklist: A Sequenced Readiness Roadmap
A practical, deadline-ordered CRA compliance checklist for manufacturers, importers and distributors. Know what to do first, what can wait, and why September 2026 matters now.
CE Marking and the EU Declaration of Conformity Under the CRA: What You Sign and What Sits Behind It
For most products with digital elements, CE marking under the CRA means one thing: you self-assess, build a technical file, and sign the EU Declaration of Conformity yourself. Here is exactly how that works.
CRA vs NIS2: Which EU Cyber Rule Applies to Your Software - and Is SaaS in or Out?
The CRA covers products placed on the market; NIS2 covers organisations operating essential services. Pure SaaS is generally out of CRA scope - but the line is not always clean.