How EU AI Act Compliance Reduces Your CRA Burden

If you have built or are building a compliance programme for the EU AI Act, you have probably heard a second acronym getting closer: the Cyber Resilience Act (CRA). If your AI ships as a product, it applies to you too. The good news is that a large part of the work you have already done for AI Act high-risk obligations carries straight over.

This article maps what transfers, what you can claim credit for once, and what the CRA adds.

Why the two laws fit together

The Cyber Resilience Act is Regulation (EU) 2024/2847. It sets baseline cybersecurity rules for “products with digital elements” sold in the EU. Hardware, software, and the services that support them are all in scope. It came into force on 10 December 2024 with incident reporting obligations applying from 11 September 2026 and full enforcement on 11 December 2027.

The CRA and the AI Act are built on the EU’s New Legislative Framework. That means both use CE marking, conformity assessment, harmonised standards, an EU declaration of conformity, and national market surveillance.

So the question is not “do I have to start a second compliance project from scratch?” It is “how much of the first project counts toward the second?” For most teams, it is more than you would expect.

What your AI Act work already covers

If you have done the full high-risk programme, you have already built the foundations the CRA asks for. The mapping is direct.

Risk management. Your Article 9 risk management system (identifying risks, evaluating them, applying mitigations across the lifecycle) is the same as what the CRA wants for security risks. You are extending an existing process, not inventing one.

Technical documentation. The Annex IV technical file you assembled for Article 11 already describes your system’s architecture, components, and how it was assessed. The CRA also requires technical documentation. The structure and much of the substance overlap.

Quality management. If you completed an Article 17 quality management system, you already have documented processes for design, development, testing, and change control. The CRA’s process requirements (how you handle vulnerabilities over time) slot into that same framework.

Post-market monitoring. Your Article 72 post-market monitoring plan watches the system in the field after launch. The CRA’s vulnerability-handling and security-update duties are the security-flavoured version of the same lifecycle discipline.

Conformity assessment and the declaration. You already know how to run a conformity assessment, draw up an EU declaration of conformity, and affix the CE mark. The CRA uses the identical process. You are reusing a skill, not learning a new one.

Cybersecurity itself. Article 15 of the AI Act already requires high-risk systems to be resilient against attempts to alter their use, behaviour, or performance. The measures you put in place there are the starting point for the CRA’s secure-by-design requirements.

A complete AI Act high-risk file covers perhaps two-thirds of a CRA foundation.

Do the Article 12 cybersecurity work once

Article 12 says a product with digital elements that is also a high-risk AI system is “deemed to comply” with the cybersecurity requirements of AI Act Article 15, provided it meets the CRA’s essential cybersecurity requirements (Annex I) and demonstrates that in the EU declaration of conformity.

If you do the cybersecurity conformity assessment under the CRA properly, that work also satisfies the AI Act’s Article 15 cybersecurity duty. One assessment. One declaration. No proving the same security controls twice to two different standards.

The CRA requirement covers cybersecurity only. Article 15 also requires accuracy and robustness, and the CRA does nothing for those. They remain a separate AI Act obligation you own in full.

What work the CRA adds

Three areas go beyond what the AI Act asked of you.

The whole product, not just the AI. The AI Act regulates the AI system. The CRA regulates the entire product with digital elements around it. That pulls in secure-by-default configuration, minimising the attack surface, and protecting all data and communications the product handles, not only the data feeding the model.

Specific vulnerability-handling duties. The CRA is prescriptive where the AI Act is general. You will need a software bill of materials listing the components in your product, a coordinated vulnerability disclosure policy so researchers can report flaws responsibly, and free security updates across a defined support period. These are concrete deliverables the AI Act never named.

A separate reporting channel. The CRA requires you to report actively exploited vulnerabilities and severe incidents to ENISA through a single reporting platform. An early warning within 24 hours and a fuller notification within 72 hours. This is not the same as AI Act Article 73 serious-incident reporting. Different triggers, different recipient, different clock. You will run both.

The timeline: one December 2027 wall, one earlier milestone

The two laws land almost on top of each other.

Date	What applies
11 September 2026	CRA vulnerability and incident reporting obligations
2 December 2027	AI Act high-risk obligations (post-Omnibus deadline)
11 December 2027	CRA main obligations

The two main deadlines sit nine days apart. Plan them as a single programme rather than two. The earlier date to watch is 11 September 2026: the CRA reporting duty arrives more than a year before either main wall, so the disclosure policy and the ENISA reporting path are the parts to stand up first.

What to do now

1. Check whether the CRA catches you at all. If any of your AI ships as software, firmware, or a connected device sold in the EU, assume you are in scope and confirm it. The CRA reaches further than the AI Act’s high-risk list: plenty of products that are not high-risk AI are still squarely in CRA scope.

2. Inventory what you have already built. List your AI Act artefacts: risk file, technical documentation, QMS, post-market monitoring, conformity assessment. Each is a head start, not a duplicate.

3. Plan the cybersecurity assessment as one piece of work. Use Article 12 deliberately. Scope the CRA cybersecurity conformity assessment so it also carries your AI Act Article 15 cybersecurity obligation, and say so in the declaration of conformity.

4. Start the genuinely new items early. The software bill of materials, the vulnerability disclosure policy, the support-period commitment, and the ENISA reporting path have no AI Act equivalent. They are the long poles.

5. Diarise 11 September 2026. The reporting obligation arrives well before the main deadline. Make sure someone can file an ENISA early warning inside 24 hours before that date, not after.

If the AI Act felt like a mountain, the CRA is a ridge off the same peak. Map what carries over, use the Article 12 bridge, and the second regulation costs you a fraction of the first.