CRA Conformity for AI-Enabled Products: Where the CRA and AI Act Assessments Collide

A product that is both a high-risk AI system and a product with digital elements is not two products. It is one product with two conformity regimes pointed at it, and if you run them as two projects you will pay for the same evidence twice and then have to reconcile the two versions when they disagree.

Most of the writing on the Cyber Resilience Act and the AI Act treats them as separate compliance tracks, because that is how the consultancies are staffed and how the tooling is sold. For a firm shipping, say, an AI-enabled access-control appliance or a diagnostic device with an embedded model, they are not separate. The Cyber Resilience Act, Regulation (EU) 2024/2847, catches the product because it has digital elements. The AI Act, Regulation (EU) 2024/1689, catches the same product because the model inside it is a high-risk AI system. Both demand a conformity assessment, a technical file, a declaration and a CE mark. The question is not whether both apply. It is how to run them so the evidence from one feeds the other instead of contradicting it.

The legislation already anticipated the collision

This is the part most readers miss. The overlap is not an accident the two regulations left for you to sort out. The CRA contains an explicit bridge in Article 12. Where a product with digital elements is also classified as a high-risk AI system, and it meets the CRA’s essential cybersecurity requirements in Annex I, the achievement of the cybersecurity level required by Article 15 of the AI Act can be demonstrated in the EU declaration of conformity issued under the CRA. In plain terms: satisfy the CRA on cybersecurity, evidence it in the CRA declaration, and you are treated as having satisfied the AI Act’s cybersecurity limb. You do not build that evidence twice.

Article 12 goes further. Where the AI Act’s conformity assessment under its Article 43 applies to the product, that same procedure covers the CRA’s cybersecurity requirements too, and a notified body competent under the AI Act becomes competent to assess the CRA cybersecurity requirements. So for a large part of the estate, there is one conformity assessment, one notified body if you need one, and one declaration carrying both hats. That is the design. The trap is assuming it applies to your product without checking, because for an important or critical product it does not.

Where the single-assessment path breaks

Article 12(3) is the exception that decides your project plan. If the product is an important product with digital elements (the CRA’s Annex III categories) or a critical product (Annex IV), then the CRA’s own conformity assessment procedures apply so far as its cybersecurity requirements are concerned. The streamlined “fold it into the AI Act assessment” route in Article 12(2) does not carry those products. You run the CRA route for cybersecurity, on its own terms.

Which means the very first thing to establish is not the AI Act classification. It is the CRA class of the product, because that is what tells you whether you get the collapsed single assessment or two parallel routes. The important-versus-critical class test under the CRA is the gate. Default products can self-assess against Annex I. Important Class I products can self-assess only where they apply harmonised standards or a European cybersecurity certification scheme; without those, and for Class II and critical products, a third party is in the loop. The Commission’s implementing regulation setting out the technical description of important and critical products is where you check what your product actually is, rather than guessing from the marketing name.

Sequence the CRA first, then the rest of the AI Act

Because Article 12 lets the CRA declaration carry the AI Act’s Article 15 cybersecurity evidence, the cybersecurity work sequences first. Do the CRA essential-requirements analysis, produce the Annex I evidence and the CRA technical documentation, and structure the EU declaration so that the Article 15 demonstration lives inside it as a labelled section a notified body or a market surveillance authority can find without a scavenger hunt.

What Article 12 does not collapse is everything else the AI Act asks of a high-risk system. Accuracy, robustness and cybersecurity under Article 15 are one requirement out of a chapter. Risk management, data governance, logging, transparency, human oversight and the Annex IV technical documentation are still yours to satisfy in full, and the CRA says nothing about them. So the honest picture is: one shared cybersecurity assessment, and a wider AI Act conformity assessment wrapped around it. The choice of route for that wider assessment — internal control against Annex VI or a notified body against Annex VII — is a separate decision that turns on whether harmonised standards exist and whether you have applied them, which is the same fork covered in internal control versus notified body under the AI Act. Get the CRA cybersecurity module solid first, and it slots into whichever AI Act route you land on.

The dates do not line up, and that matters

The CRA’s main obligations apply from 11 December 2027, with its incident and vulnerability reporting duties biting earlier, from 11 September 2026. That 2027 date is fixed; the CE-marking and conformity path for software under the CRA is already a live planning problem.

The AI Act’s high-risk timing is not fixed in the same way. As originally enacted, standalone high-risk systems under Annex III applied from 2 August 2026 and high-risk systems that are safety components of products under Annex I from 2 August 2027. The Digital Omnibus reached provisional political agreement in mid-2026 to push these back — to 2 December 2027 for Annex III and 2 August 2028 for Annex I products — but at the time of writing that is a provisional deal, not adopted law, and the trilogue has been contested. Treat those two dates as provisional and verify them against the final adopted text before you commit a plan to them. The stable conclusion holds regardless: for many AI-enabled products the CRA obligation lands before the AI Act high-risk obligation, so the CRA declaration is the one you will hold first, and building the Article 15 evidence into it is not premature — it is the natural order.

What this means for the technical file

The practical output of getting this right is one technical documentation set, not two. The CRA technical documentation and the AI Act Annex IV documentation overlap heavily on the product description, architecture, the risk assessment and the cybersecurity controls. Structure the cybersecurity evidence once, as a referenced module, and point both declarations at it. Run them as two independent projects and you get two files that describe the same architecture in two vocabularies, two risk assessments that grade the same threat differently, and an auditor who now has a contradiction to ask about. This is the same reasoning that makes the case for running overlapping EU regimes as one programme rather than a stack of parallel ones.

The instinct to commission two assessments feels safe because it maps to how the obligations are written up and how vendors quote. It is the expensive answer. Establish the CRA class, decide whether Article 12(2) collapses the cybersecurity assessment or Article 12(3) keeps it separate, build the cybersecurity evidence once and let the CRA declaration carry the AI Act’s Article 15 requirement. Do that, and you reach 2027 with one coherent story. Skip it, and you reach it with two files that disagree and a supervisor who has noticed.