CRA vs AI Act: Cybersecurity Overlap for High-Risk AI

You build an AI safety controller for an electricity grid. It's a product with digital elements, so the Cyber Resilience Act (CRA) applies. It's also a high-risk AI system, so the EU AI Act applies. Two regulations, two conformity assessments, two declarations? Not for the cybersecurity part.

By the end you'll know three things: whether the overlap even applies to your product, what cybersecurity evidence you can reuse across both laws, and what still needs separate AI Act work. The short version: CRA Article 12 lets you reuse cybersecurity evidence across both laws, on conditions. It does not collapse CRA and AI Act compliance into one regime.

Summary

• The overlap is narrow. It only matters when one product is both in CRA scope and a high-risk AI system under the AI Act.
• The CRA gives a one-way bridge, on conditions. Meet the CRA cybersecurity requirements and show that level of protection in your CRA Declaration of Conformity, and the product is treated as meeting the AI Act's cybersecurity requirement.
• The bridge covers cybersecurity only. AI Act accuracy and robustness are carved out and stay with the AI Act.
• For most products you run one conformity assessment, keep a single set of technical documentation, and carry one CE marking. Important and critical CRA products are the exception.
• Everything else stays split. Data governance, logging and human oversight stay on the AI Act side. SBOM, vulnerability handling, the support period and 24-hour reporting stay on the CRA side.

Are you even in the overlap?

Most AI is not in scope, and most CRA products are not AI. Three questions decide it.

• Is it a product with digital elements? The CRA covers hardware and software that connects to a device or a network. A paper-only process or a fully offline tool falls outside.
• Is it also a high-risk AI system? Under the AI Act, a system is high-risk when it's a safety component of a product that already needs independent testing, or when it does one of the high-risk uses the AI Act lists, such as remote biometric identification. The list is specific, and some uses are filtered back out as lower-risk. A general-purpose chatbot usually is not high-risk.
• Is it pulled out by sector law? The CRA steps aside for products already governed by their own rules: medical devices, in vitro diagnostics, type-approved vehicles, certified aircraft, and marine equipment. An AI medical device handles its security under the medical-device rules, not the CRA.

If any gate fails, the bridge does not apply. That is useful too: you can stop trying to reuse CRA cybersecurity evidence for the AI Act and plan the two workstreams separately.

The short answer: prove cybersecurity once

When all three gates pass, the bridge does the work, on three conditions. The product meets the CRA cybersecurity requirements, the manufacturer's processes meet the CRA vulnerability-handling duties, and the CRA EU Declaration of Conformity shows the level of cybersecurity protection the AI Act asks for. Meet those and the product is treated as meeting the AI Act's cybersecurity requirement. You build the security evidence once for the CRA, and it counts for the AI Act too.

That last condition matters. The presumption is not automatic. It hangs on a declaration that actually states the protection level, not a box-tick.

What the bridge does not cover

The bridge carries cybersecurity and nothing else. The AI Act asks for accuracy and robustness too, and the CRA side does nothing for those. It also doesn't touch the wider high-risk AI duties: data and data governance, record-keeping and logging, human oversight, and clear information for the people who use the system. If you've already done the CRA, that list is what's left for the AI Act. Plan the AI Act work around it, not around repeating the security work you finished for the CRA.

Three boundaries are worth fixing in your head. A European cybersecurity certificate can also satisfy the AI Act's cybersecurity requirement, to the extent it covers it, so certification is a second path to the same place. A general-purpose AI model on its own is not the overlap, but a product, app, or device built on that model can still be a CRA product if it meets the scope test. And if your AI sits inside machinery, watch that interface: the Digital Omnibus would route the AI health-and-safety rules for machinery through the Machinery Regulation, with delegated acts due by 2 August 2028.

What evidence carries across

The bridge is about reuse. Here is what you build for the CRA and what it answers on the AI Act side.

The third row is the one teams miss. The CRA risk assessment has to account for attacks that target the model itself, not just the software around it. Data poisoning targets the training data, and adversarial inputs target what the model sees at run time, so both belong inside the same assessment. That same work is what the AI Act's cybersecurity requirement expects, so doing it once covers both.

One assessment, one technical file, one CE mark

For most products in the overlap, you run a single conformity assessment under the AI Act's route, and a notified body that assesses the AI system can cover the CRA cybersecurity check too, as long as it's competent for the CRA side. You keep a single set of technical documentation that serves both laws, and the finished product carries one CE marking, not two. The AI Act is built for this: you draw up one EU Declaration of Conformity covering every law that applies, and the single CE marking signals that you meet that other law too.

Two things change that picture. Important and critical CRA products keep the CRA's own assessment route for the security part when the AI Act would otherwise let the AI system self-assess, so a CRA-competent notified body stays involved. And the single-assessment route covers cybersecurity, not the rest of the AI Act. See the conformity assessment routes for the CRA side.

What the CRA still requires on its own

The bridge runs one way and covers security only. Your CRA duties don't shrink because the product is also AI. For the product, you still owe:

• a software bill of materials and a record of the components inside it
• vulnerability handling and reporting, including the 24-hour early warning for actively exploited flaws
• a defined support period with security updates
• secure-by-default configuration and the other CRA product properties

The AI Act adds one instruction the CRA does not spell out on its own. Your security risk assessment has to cover AI-specific attacks, such as data poisoning and adversarial inputs. Reusing that work does not let you skip those. It expects you to fold them into the same risk work.

Two reporting duties, not one

The bridge reuses your security evidence. It does not merge incident reporting. A product in the overlap can carry two separate reporting duties that do not fold into each other. One wording note: the CRA calls you the manufacturer and the AI Act calls you the provider. For a product you build and sell under your own name, that is the same company, not two parties.

• The CRA duty. You report an actively exploited vulnerability or a severe security incident to your coordinating CSIRT and to ENISA, through the single reporting platform. The clock is short: a 24-hour early warning, a 72-hour update, then a final report.
• The AI Act duty. The provider reports a serious incident, such as serious harm to health, a breach of fundamental rights, or a serious disruption of critical infrastructure, to the market surveillance authority where it happened. The deadline runs up to 15 days, and as fast as 2 days for the worst cases.

The triggers barely meet. CRA reporting is about the security of the product. AI Act reporting is about safety and rights harm. One event can set off both, so route each incident type to the right channel before something goes wrong. The AI Act trims duplicate reporting in one case: for a standalone high-risk system whose provider already faces equivalent reporting under another Union law, the AI Act report narrows to fundamental-rights incidents.

Teams commonly build the CRA's 24-hour reporting and treat the AI Act side as covered. It is not. The serious-incident report to the market surveillance authority is separate work, and it needs its own owner and its own playbook.

If your organisation is also an essential or important entity under NIS2, that adds a third reporting track at the company level, not the product level. See how the CRA and NIS2 overlap for that side.

How the deadlines line up

One timing caveat is worth tracking. The AI Act's original date for product-embedded high-risk systems was 2 August 2027. The Digital Omnibus on AI would move standalone high-risk systems to 2 December 2027 and product-embedded ones to 2 August 2028. The co-legislators agreed the change on 7 May 2026, and the European Parliament approved it on 16 June 2026. As of 24 June 2026 it's not yet binding law. It still needs Council adoption and publication in the Official Journal. The Commission's high-risk classification guidance is also still in draft, with final guidelines expected by the end of 2026. Treat the new dates as the likely landing point, not settled law.

For a product in the overlap, the CRA moves first, with reporting from September 2026 and full application in December 2027. The AI Act high-risk duties land around December 2027 for standalone systems and in August 2028 for product-embedded ones, under the proposed timeline.

What to keep in mind

A few things change the simple version of this story.

• The presumption is conditional. It only holds if your CRA Declaration of Conformity actually shows the AI Act's level of cybersecurity protection. A thin declaration breaks the bridge.
• Important and critical products are different. When the AI Act would otherwise let them self-assess, the CRA's own assessment route governs the security part, so a CRA notified body stays in the loop.
• One market surveillance authority. For a product in the overlap, the authority that supervises your AI system also supervises the CRA side, and it works with the CSIRTs and ENISA on the CRA reporting.
• The bridge is security only. It does nothing for accuracy, robustness, data governance, logging or human oversight. Budget for those as separate AI Act work.
• The dates are not settled. The 2027 and 2028 high-risk dates are pending Council adoption of the Digital Omnibus.
• Machinery has its own path. AI-enabled machinery is heading toward the Machinery Regulation for its AI health-and-safety rules.

Our take

The bridge is real and useful, but treat "assessed once" as a planning goal, not a guarantee. The win is evidence reuse. Build one strong CRA security file and a single technical documentation set, then point both regimes at it.

The trap we see is teams reading the bridge as "the AI Act security box is ticked" and skipping the AI-specific threat work the CRA assessment still has to cover. Data poisoning and adversarial inputs are where an AI product actually gets hurt, and they're what both laws expect you to handle.

Our advice is plain. Scope the product first, build the CRA security file to a high bar, write a declaration that states the protection level, and run the AI Act's accuracy, robustness and oversight work on its own track. Do that and the overlap saves you real duplication. Read it as a shortcut and it bites you at assessment.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.