Proving It: Conformity Routes, Documentation, and Enforcement

The Cyber Resilience Act borrows its enforcement architecture from decades of EU product law: essential requirements, conformity assessment, a declaration, a CE mark, and market surveillance after launch. If that machinery is unfamiliar, the lesson on conformity assessment for high-risk AI systems covers the general shape, and it transfers.

What is worth attention here is the CRA-specific part, which is where teams lose time.

The reframe that matters: a conformity assessment does not ask whether your product is secure. It asks whether you can show, from records, that you determined what security this product needed and then built to that determination. A well-engineered product with no documented risk assessment fails. A modest product with a coherent, evidenced chain of reasoning passes.

Everything in this lesson is downstream of that. The modules differ in who checks the records. The documentation requirements define what the records are. Market surveillance is what happens when someone asks to see them.

Annex VIII sets out the procedures, using the standard module letters from EU product law.

Module A, internal control, is self-assessment. The manufacturer draws up the technical documentation, satisfies itself that design, development and vulnerability handling meet Annex I, affixes the CE marking and signs the declaration. No external body is involved at any point.

Module B, EU-type examination, has a notified body examine the technical design and the vulnerability handling processes, review the documentation and any specimens, and issue an EU-type examination certificate. Module B is always paired with Module C, conformity to type based on internal production control, under which the manufacturer ensures what it produces matches the examined type.

Module H, full quality assurance, has a notified body approve and then periodically audit a quality system covering design, development and vulnerability handling, rather than examining one product design.

Documentation and the declaration are retained for at least ten years after the product is placed on the market, or for the support period, whichever is longer.

The tier from Annex III and Annex IV decides which modules are open to you.

Default category products may use any route: Module A, Module B plus C, Module H, or a European cybersecurity certification scheme at assurance level at least substantial. In practice almost all self-assess.

Important class I products may use Module A only where the manufacturer has applied harmonised standards, common specifications, or a European cybersecurity certification scheme covering the essential requirements. Otherwise the product goes to a notified body under B plus C or H.

Important class II products cannot self-assess. Third-party assessment under B plus C or H, or a certification scheme, is mandatory.

Critical products follow the class II routes, and the Commission may by delegated act require certain categories to hold a European cybersecurity certificate at assurance level at least substantial.

Note the shape of the class I rule. It is not a fixed sentence of external assessment. It is conditional on the availability of standards, which makes standards development commercially significant.

The decision has two inputs, and only two: the tier, and whether standards covering your requirements exist and were applied.

Read the diagram from the tier you established during scoping. Default category products reach self-assessment directly. Class II and critical products reach a notified body directly, with a certification scheme as the alternative. Only class I has a branch, and that branch is the one worth engineering around.

For a class I product, applying harmonised standards or common specifications keeps Module A available. Failing to apply them routes you to a notified body, with the cost, lead time and scheduling risk that implies.

That asymmetry is why standards coverage is a planning question rather than a technical preference. A class I manufacturer whose product category has usable harmonised standards can ship on its own timetable. One whose category does not is dependent on notified body capacity, in a market where that capacity is still being built out under Chapter IV.

Harmonised standards do more than unlock Module A. A product that conforms to a harmonised standard whose reference is published in the Official Journal is presumed to conform to the essential requirements the standard covers.

That presumption reverses the burden. Without it, you argue from first principles that your approach to, say, secure default configuration satisfies Annex I point (b), and a market surveillance authority may disagree. With it, conformity to the standard is treated as conformity to the requirement unless someone rebuts it.

Harmonised standards are developed by the European standardisation organisations, CEN and CENELEC, in response to a standardisation request from the Commission. Where standards are absent or inadequate, the Commission may adopt common specifications by implementing act, which carry the same presumption.

The practical caution: a standard only covers what it covers. Applying one standard does not create a presumption across all of Annex I. Annex VII asks for a list of the standards applied in full or in part, and that word matters.

The CRA opens a second door out of mandatory third-party assessment, and it is unusual enough to be worth stating precisely.

A manufacturer of free and open-source software that would otherwise fall in important class I or class II may use Module A, self-assessment, provided the technical documentation is made publicly available.

Read that carefully. It is not a licence exemption. It applies to a manufacturer, meaning an entity commercially supplying the software and carrying the full obligation set. What it substitutes is the mechanism of scrutiny: instead of a notified body examining the documentation privately, the documentation is exposed to everyone.

The trade is coherent. Third-party assessment exists to introduce an independent reader of your evidence. Publication introduces an unbounded number of them.

This is separate from the Article 24 steward regime and from the position of non-commercial maintainers, who are outside the scope of these obligations entirely.

Annex VII lists what the technical documentation must contain. It is the artefact every route produces, and the one a market surveillance authority asks for.

A general description: intended purpose, the software versions affecting compliance, and for hardware, photographs or illustrations showing external features, marking and internal layout, plus the Annex II user information.

A description of the design, development, production and vulnerability handling processes, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the contact address for reports, and the processes for distributing security updates.

The cybersecurity risk assessment, including how each applicable Annex I Part I requirement applies and how it was implemented. The information taken into account when determining the support period. A list of harmonised standards, common specifications or certification schemes applied in full or in part. Test reports verifying conformity of both the product and the vulnerability handling processes. A copy of the EU declaration of conformity. And, on reasoned request from a market surveillance authority, the software bill of materials.

On a successful assessment the manufacturer draws up the EU declaration of conformity, following the model in Annex V, and affixes the CE marking. Annex VI provides a simplified declaration, a short statement naming the manufacturer and product type, asserting compliance with Regulation (EU) 2024/2847, and pointing to where the full declaration can be found. By signing, the manufacturer assumes responsibility for compliance.

The question that then governs the product's life is what counts as a substantial modification. Article 3 defines it as a change that affects compliance with the essential requirements or that alters the intended purpose, in a way not foreseen in the original risk assessment. Where one occurs, the modified product is treated as newly placed on the market and reassessed for the affected parts.

For software this is the provision with the most operational weight. Routine security updates are not substantial modifications; that is the whole point of an update obligation. A release that introduces a new interface, a new data flow, or a new trust boundary can be.

Each Member State designates one or more market surveillance authorities, and Regulation (EU) 2019/1020 on market surveillance and product compliance supplies the general powers.

Authorities may request the technical documentation, and the manufacturer must keep it at their disposal. Where a product presents a significant cybersecurity risk, the authority evaluates it and may require corrective action, restrict its availability, order withdrawal, or order a recall. Findings are shared with the Commission and other Member States, which is what turns a national action into a Union-wide one.

Coordination runs through an Administrative Cooperation Group, and authorities conduct simultaneous coordinated checks on specific product categories, known as sweeps.

Two features are worth planning around. Enforcement is not gated on an incident: a sweep is a routine sampling exercise. And a product can be compliant on paper and still face measures if it presents a significant cybersecurity risk, because the risk power sits alongside the compliance power rather than inside it.

Article 64 requires Member States to lay down national penalty rules, within ceilings the Regulation fixes. In each tier the euro figure and the turnover percentage both apply, and the higher of the two governs.

The tiering is informative. The heaviest ceiling covers the substance, the support period and the reporting duty together, which places Article 14 in the same bracket as building an insecure product.

Two carve-outs apply. Microenterprises and small enterprises may not be fined for missing the 24-hour early warning. Open-source software stewards are not subject to these penalties at all.

Compliance questions are settled from primary sources, and for this regime there are four worth knowing by name.

Regulation (EU) 2024/2847 itself is the only binding text. Articles carry the obligations; the annexes carry the substance, and Annex I, VII and VIII do most of the work.

The Commission publishes a summary of the legislative text on its digital strategy site, structured article by article. It is the fastest way to locate the right provision before reading it in the Official Journal.

Commission Implementing Regulation (EU) 2025/2392 gives the technical descriptions of the important and critical categories, and settles most borderline classification arguments.

The Commission has also issued non-binding guidance, Communication C(2026) 5252 with a detailed annex, addressing scope, remote data processing, free and open-source software, substantial modification, support periods and reporting, with worked examples aimed at smaller companies.

Guidance carries no legal force. It does tell you how the authority reads the text.