Choosing a conformity assessment module under the Cyber Resilience Act is a two-step decision, not a single choice: first your product's Annex III/IV classification fixes which of Article 32's four routes — Module A self-assessment, Modules B+C, Module H, or a certification scheme — are even legally available, and only then, among whichever routes remain open, do cost, lead time, standards coverage and market expectations decide which one actually makes sense to use. Getting the first step wrong means picking a route the regulation does not let you use; getting the second step wrong means paying for third-party assessment you did not need, or self-assessing on a product too complex to defend that choice later.
The module mechanics and classification links below are cross-checked against this site's own dedicated guides to CRA Annex III/IV classification and self-assessment vs notified body, which in turn cite the regulation's Official Journal text and corroborating secondary legal analysis (Springlex, Acquislaw). Treat specific annex and article numbering as a starting point to re-verify against EUR-Lex before a compliance submission; this is general information, not legal advice.
Key takeaways
- Module A — internal control.
- You cannot choose a module before you know your product's tier.
- Only default products and some Class I products actually face a choice.
- Picking a module decides who assesses your product; it does not change what has to be in the Annex VII technical documentation underneath that assessment.
What are the CRA's conformity assessment modules?
Article 32 names up to four procedures a manufacturer can use to demonstrate that a product with digital elements meets the Annex I essential cybersecurity requirements before it goes on the market:
- Module A — internal control. The manufacturer assesses its own product, compiles the technical documentation, and signs the EU declaration of conformity. No notified body is involved.
- Modules B + C, together. A notified body examines a representative sample of the product under Module B (EU-type examination); the manufacturer then has to manufacture every unit to match that approved type under Module C. The CRA pairs these two modules rather than offering Module B alone.
- Module H — full quality assurance. A notified body audits the manufacturer's quality management system itself, rather than a product sample, to confirm the system reliably produces conforming products.
- A European cybersecurity certification scheme, where the Commission has adopted one under the Cybersecurity Act (Regulation (EU) 2019/881) and made it relevant to the product category — the EUCC scheme is the first such scheme to exist, though it predates and was not built specifically for the CRA.
This guide focuses on how to pick among these once you know which ones apply to you; for the detail of where the module text sits in the regulation's annexes and the open-source self-assessment carve-out, see CRA conformity assessment: self-assessment vs notified body.
Which modules are open to you? Classification decides first
You cannot choose a module before you know your product's tier. Annex III and IV sort products with digital elements into three tiers, and each tier opens a different subset of Article 32's routes:
| Tier | Example products | Modules actually open to you |
|---|---|---|
| Default (not in Annex III or IV) | Most products with digital elements | All four: Module A, Modules B+C, Module H, or a certification scheme — your choice |
| Annex III important, Class I | Browsers, password managers, VPN products, routers/modems/switches, smart home security devices | Module A only if harmonised standards, common specifications, or a "substantial"-level certification scheme already fully cover the relevant requirements; otherwise Modules B+C or Module H |
| Annex III important, Class II | Hypervisors, firewalls/IDS/IPS, tamper-resistant microprocessors and microcontrollers | Modules B+C, Module H, or a certification scheme at "substantial" — self-assessment is never an option |
| Annex IV critical | Hardware security modules, smart meter gateways, smartcards and secure elements | A European cybersecurity certification scheme where the Commission requires one; otherwise the Class II third-party procedures |
A default-tier product is the one case where "choosing a module" is a genuinely free decision among all four routes. Everywhere else, classification narrows the menu before cost or preference enters into it.
How do you choose if more than one route is open to you?
Only default products and some Class I products actually face a choice. When they do, four factors decide it in practice:
Standards coverage, for Class IIf a harmonised standard, common specification, or "substantial" certification scheme does not yet fully cover your product's relevant requirements, Module A is not legally available to you yet — check where the CRA's harmonised standards actually stand before assuming self-assessment is on the table. Notified-body lead time against your ship dateModules B+C and Module H both run through a notified body, and capacity is a real planning constraint. A product aimed at the CRA's 11 December 2027 application date, or at an earlier voluntary launch, needs that conversation started months ahead, not after the technical documentation is otherwise finished. Cost and audit burden versus liabilityModule A costs less and avoids a notified-body audit cycle, but the manufacturer alone carries the compliance risk if a market surveillance authority later disagrees with the self-assessment. Modules B+C and Module H cost more and take longer but transfer part of that scrutiny to an independent body before the product ships. What the market actually expectsA default-tier product sold into a sector that already expects third-party assurance — for example alongside IEC 62443-4-2-assessed industrial components — can still legally self-assess under Module A, but a manufacturer may reasonably choose Modules B+C, Module H, or a certification scheme anyway to match what buyers in that market are used to seeing.
None of these factors changes which modules the regulation permits — only which of the permitted ones is the sensible pick.
Why the harmonised standards timeline matters to this choice
Module A eligibility for Annex III Class I products turns on "fully applying harmonised standards, common specifications, or a certification scheme at assurance level at least 'substantial'" — and as of early November 2026, no CRA harmonised standard had been cited in the Official Journal of the EU, the one event Article 27 says actually creates presumption of conformity. The EN 40000 and EN 304 6xx series being drafted under standardisation request M/606 were still moving through CEN, CENELEC and ETSI's internal approval stages at that point, not yet citable. A Class I manufacturer planning to rely on harmonised standards for Module A eligibility needs to track that citation date directly, not assume a CENELEC-approved draft already qualifies.
How SBOM and firmware-analysis evidence supports the technical documentation, whichever module you choose
Picking a module decides who assesses your product; it does not change what has to be in the Annex VII technical documentation underneath that assessment. Every route — Module A, Modules B+C, Module H, or a certification scheme — rests on the same underlying evidence:
- A software bill of materials. Annex I Part II point (1) requires an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. See firmware SBOM without source code for how to build one from a binary image when the original build environment is not available.
- A record that known exploitable vulnerabilities were checked and handled. Annex I Part I point (2)(a) and the vulnerability-handling obligations in Annex I Part II both expect this, and it is part of what a notified body reviews under Modules B+C or H, or what a manufacturer has to be able to defend under Module A.
An automated, engineer-reviewed firmware and SBOM scan can produce this evidence in a timeframe of days rather than the weeks manual component research would take, which matters most for Class II and Annex IV products facing a notified body's own timeline. But it is worth being precise about what that automation does and does not do: it does not decide which Article 32 module applies to your product, and under Article 27 it does not create presumption of conformity — only a harmonised standard the Commission has cited in the Official Journal does that. A scan report, however it was generated, is technical-documentation evidence a human still has to review and a manufacturer or importer still has to stand behind; it is not itself a conformity assessment.
A practical starting point
Classify the product firstWork out whether it falls under Annex III or IV before thinking about modules at all — see CRA Annex III and IV: important and critical products explained. List the modules your classification actually opens up, using the table above, rather than assuming self-assessment is always available. If Class I and weighing Module A, check harmonised-standards status now, not at submission time — see the harmonised standards timeline. If Class II, Annex IV, or opting into third-party assessment voluntarily, start notified-body conversations earlyLead time, not paperwork, is usually the real constraint. Build the SBOM and vulnerability evidence regardless of moduleIt belongs in the Annex VII technical documentation either way, and a firmware SBOM built now does not have to be redone once a module is finally chosen. Revisit the choice if the Commission amends Annex III/IVor a harmonised standard is finally cited in the Official Journal — both can change which modules are open or sensible later, even for a product already on the market.
SoftWSP's firmware security work builds the SBOM and vulnerability evidence that feeds a CRA technical documentation file, and can help work out which conformity assessment modules your product's classification actually opens up: see device & firmware security services. For the underlying requirements any module has to demonstrate, see the CRA checklist for device makers.
This guide summarises Regulation (EU) 2024/2847 and corroborating secondary legal analysis as reflected in this site's own CRA guides; it is not a substitute for the regulation's own text on EUR-Lex or for legal advice, and a conformity assessment decision should rest on that current official text.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 27 and 32 and Annexes I, III, IV and VII, Official Journal text, EUR-Lex
- European Commission: Cyber Resilience Act, summary of the legal text
- European Commission, Digital Strategy: Cyber Resilience Act — Standardisation
- ENISA: Cybersecurity Certification Framework (Regulation (EU) 2019/881, assurance tiers, scheme list)
- Springlex: Cyber Resilience Act, Article 32 — Conformity assessment procedures for products with digital elements
- Acquislaw: Cyber Resilience Act, Article 32 — full text, verified
Frequently asked questions
What are the CRA's conformity assessment modules?
Article 32 of Regulation (EU) 2024/2847 gives manufacturers up to four conformity assessment routes, per corroborated secondary legal analysis: Module A (internal control — self-assessment, no notified body), Modules B+C together (a notified body's EU-type examination plus the manufacturer's own internal production control), Module H (full quality assurance, where a notified body assesses the manufacturer's quality management system rather than a product sample), and a European cybersecurity certification scheme, where one has been adopted under the Cybersecurity Act and the Commission has made it relevant to the product category.
How do I know which modules are actually open to my product?
Your product's classification decides this before you choose anything. A default product (not listed in Annex III or IV) can use any of the four routes. An Annex III important Class I product (browsers, password managers, VPN products, routers/modems/switches, smart home security devices, and more) can self-assess only if harmonised standards, common specifications, or a certification scheme at assurance level at least 'substantial' fully cover the relevant requirements; otherwise it needs a notified body. Annex III Class II products (hypervisors, firewalls/IDS/IPS, tamper-resistant microprocessors and microcontrollers) and Annex IV critical products (hardware security modules, smart meter gateways, smartcards and secure elements) cannot self-assess at all.
If more than one module is open to my product, how should I choose?
Weigh four things: whether harmonised standards or a certification scheme already cover your product closely enough to make self-assessment safe to rely on; notified-body lead time against your own ship date and the CRA's 11 December 2027 application deadline; the cost and audit burden of Modules B+C or H against Module A's lower cost but full manufacturer liability; and whether a stronger third-party signal helps you sell into a market or sector that expects one, even where self-assessment would legally be enough.
Does an SBOM or firmware analysis decide which conformity assessment module I need?
No. Your product's Annex III/IV classification decides which modules Article 32 makes available; an SBOM and a firmware vulnerability analysis do not change that. What they do is supply evidence — the software bill of materials Annex I Part II point (1) requires, and the vulnerability-handling record Annex I Part I point (2)(a) and Annex VII expect — that has to go into the technical documentation regardless of which module you end up using.
Can AI-assisted firmware or SBOM analysis replace a notified body or grant presumption of conformity?
No. Automated, engineer-reviewed firmware and SBOM analysis can generate technical-documentation evidence faster than manual component research, but it cannot stand in for a notified body's Module B+C type-examination or Module H quality-system audit, and under CRA Article 27 only a harmonised standard the Commission has actually cited in the Official Journal creates presumption of conformity — a scan report, however it was produced, does not. The manufacturer or importer remains responsible for the conformity assessment itself.
In this cluster
Questions about this page?