A CRA conformity assessment is the procedure a manufacturer uses to demonstrate that a product with digital elements and the manufacturer's relevant processes meet the Cyber Resilience Act's essential cybersecurity requirements. The route depends first on the product's CRA classification and, for important Class I products, on whether the manufacturer can rely on technical specifications or certification mechanisms recognised by the Regulation.
For many ordinary products, manufacturer self-assessment under Module A is available. Important Class II products require a third-party or eligible certification route. Important Class I products sit between those outcomes: self-assessment can remain available where Article 32 conditions are met, while uncovered requirements must go through a stricter procedure. Critical products follow the certification or third-party routes specified by Article 32 and Article 8.
The practical sequence is classify first, select the legally available assessment route second, then build the evidence package around that route.
Conformity assessment is not product classification
Product classification asks whether the product is in the default category, important Class I, important Class II or critical. Conformity assessment asks how the manufacturer will demonstrate that the applicable Annex I requirements are met.
Keep those decisions separate but linked. A classification record should explain the product boundary, intended purpose, core functionality and Annex III or Annex IV comparison. The conformity-assessment record should use that result to identify the applicable Article 32 route.
Module A self-assessment does not reduce the underlying CRA work. It identifies who performs the assessment; the manufacturer still needs the cybersecurity risk assessment, technical documentation, verification evidence and vulnerability-handling processes.
The four practical route outcomes
Article 32 and Annex VIII create the following operating model.
| Product outcome | Main conformity-assessment route | Practical consequence | | --- | --- | --- | | Default category | Module A is available; B+C or H may also be chosen | Manufacturer can normally perform internal conformity assessment | | Important Class I | Module A where Article 32 conditions are met; otherwise B+C or H for relevant uncovered requirements | Standards, common specifications or eligible certification coverage affects the route | | Important Class II | B+C, H, or an available and applicable European cybersecurity certification scheme at least at assurance level "substantial" | Module A alone is not available | | Critical, Annex IV | Certification under Article 8(1), or, where its conditions are not met, a Class II route | Ordinary Module A self-assessment is not the route |
Manufacturers of products qualifying as free and open-source software that fall within Annex III have a specific exception. Article 32(5) allows them to use one of the paragraph 1 procedures if the required technical documentation is made public when the product is placed on the market.
Default-category products: Module A
For products in CRA scope that do not fall into Annex III or Annex IV, the Commission describes Module A as the normal self-assessment route. Annex VIII defines it as an internal control procedure in which the manufacturer declares on its sole responsibility that the product and its processes meet the applicable essential cybersecurity requirements.
The manufacturer must still draw up Annex VII technical documentation and operate design, development, production and vulnerability-handling processes that ensure conformity. The procedure culminates in the required EU declaration of conformity and CE marking.
A useful Module A record should let a reviewer reconstruct which requirements were considered, what technical solution was selected, how it was verified and which product or release the evidence belongs to. Typical evidence includes the risk assessment, Annex I mapping, architecture decisions, security tests, SBOM information, vulnerability-handling procedures, update mechanisms, support-period rationale and release records.
Important Class I: coverage changes the route
Article 32(2) makes Class I route selection conditional. Where the manufacturer has not applied, has only partly applied, or cannot use relevant harmonised standards, common specifications or qualifying European cybersecurity certification schemes, the product and manufacturer processes must be submitted for those essential cybersecurity requirements to either:
- Module B followed by Module C; or
- Module H.
The practical question is therefore not simply "Is the product Class I?" but which applicable requirements are fully covered by a recognised route and which are not?
For each relevant requirement, record the exact standard or specification, its legal status, whether it is applied fully or partly, and the evidence showing implementation. Article 27 gives a presumption of conformity only under the conditions set by the Regulation, including publication of harmonised-standard references in the Official Journal where applicable.
That distinction matters in August 2026. The Commission's implementation timeline places the first CRA standardisation deliverables in Q3 2026. A draft or technically useful standard is not automatically a harmonised standard that creates a CRA presumption of conformity.
Important Class II and critical products
Important Class II products cannot rely on Module A alone. Article 32(3) requires one of these routes:
- Module B + Module C;
- Module H; or
- where available and applicable, a European cybersecurity certification scheme under Article 27(9) at assurance level at least "substantial".
For critical products listed in Annex IV, Article 32(4) points first to a European cybersecurity certification scheme in accordance with Article 8(1). Where those conditions are not met, the manufacturer uses one of the Class II routes.
The operational implication is to plan Class II and critical products for third-party or certification-based assessment rather than assuming strong internal testing can substitute for the required route. The technical work remains the manufacturer's responsibility: a notified body assesses evidence and processes; it does not replace product engineering, risk analysis or vulnerability handling.
Module B + C: type examination and controlled production
Under Module B, a notified body examines the technical design and development of the product and the manufacturer's vulnerability-handling processes. The review uses technical documentation and supporting evidence and can include specimens of critical product parts. If the assessed type meets the relevant requirements, the body issues an EU-type examination certificate.
The manufacturer must keep the notified body informed about approved-type modifications that can affect conformity or certificate conditions. Annex VIII also gives the body an ongoing role in auditing the effectiveness of vulnerability-handling processes.
Module C then requires the manufacturer to ensure that production or development remains conformant with the approved EU type and applicable CRA requirements. The evidence chain should therefore connect:
assessed type -> approved technical baseline -> production/release controls -> shipped product or release.
Configuration and change control are central. A certificate for one design baseline is weak evidence if the organisation cannot show which later release corresponds to it and which changes were reviewed.
Module H: full quality assurance
Module H assesses conformity through a full quality-assurance system. The manufacturer operates a documented quality system covering the relevant product and lifecycle processes, and a notified body assesses and supervises that system.
Annex VIII expects the quality system to cover quality objectives and responsibilities, design and development controls, production or development methods, examinations and tests, quality records, system monitoring and vulnerability-handling processes. The notified body assesses the system and performs surveillance.
Module H may fit an organisation with mature repeatable product-development and quality processes, but it is not a shortcut around product evidence. The organisation still needs to demonstrate how the system produces compliant product outcomes and how security-relevant decisions are controlled and retained.
Selecting a notified body
The CRA notification framework began applying on 11 June 2026. A conformity assessment body must be assessed, designated and notified by a Member State before acting as a CRA notified body. The Commission's NANDO system is the authoritative place to verify notified status and scope once CRA bodies are listed.
Selection should therefore check more than general cybersecurity-audit experience:
- notification for the required CRA procedure;
- scope covering the relevant product and assessment activity;
- technical competence of the proposed audit team;
- ability to assess vulnerability-handling processes as well as product evidence; and
- an assessment plan aligned with the product boundary and release timetable.
ENISA's June 2026 Technical Competence Requirements for CRA Notified Bodies describes high-level experience and training expectations for auditors and evaluators. ENISA also notes that those competences need to be complemented by product- and harmonised-standard-specific competence.
Build one evidence baseline
The external-assessment depth varies, but the core evidence foundation is shared. Before assessment, connect at least:
- Product identity and boundary — product, variant, version or release family and relevant remote functions.
- CRA classification — default, Class I, Class II or critical with its rationale.
- Cybersecurity risk assessment — product-specific risks and control assumptions.
- Annex I mapping — applicable requirements and how each is addressed.
- Technical documentation — architecture, design decisions, interfaces and dependencies.
- Verification evidence — security tests, reviews and resolution of significant findings.
- Vulnerability handling — intake, triage, remediation, disclosure, updates and retained decisions.
- SBOM and component evidence — component identification and related vulnerability work.
- Configuration and change control — the link between assessed evidence and the exact market release.
- Conformity records — selected Article 32 route, rationale, certificates where applicable, EU declaration and CE records.
The route changes who assesses what, not whether the manufacturer can explain its product-security case.
Common mistakes
A few route-selection errors recur:
- Choosing the module before classifying the product. Classification is the input to the Article 32 route decision.
- Assuming every Class I product needs a notified body. Class I depends on recognised coverage for the relevant requirements.
- Assuming Class II can self-assess if internal engineering is strong. Module A alone is not an Article 32(3) route.
- Treating a draft standard as a legal presumption of conformity. Record the current legal status and exact coverage.
- Treating the notified body as the product-security owner. The manufacturer remains responsible for product evidence and processes.
- Losing the link between the assessed baseline and later releases. Define change triggers before assessment closes.
A practical route-selection workflow
For each product family:
- Confirm CRA scope and the manufacturer role.
- Define the exact product boundary.
- Classify the product and retain the rationale.
- Map applicable Annex I requirements from the cybersecurity risk assessment.
- For Class I, map recognised technical coverage requirement by requirement.
- Select Module A, B+C, H or an applicable certification route as legally available.
- If a notified body is required, verify its notification scope and technical competence early.
- Freeze an assessable product and evidence baseline.
- Retain findings, responses, certificates or approvals produced by the assessment.
- Connect the result to release and change control so reassessment triggers are visible.
Keeping classification, Annex I requirements, risk assessment, security evidence and release decisions connected to the exact product and lifecycle state can become difficult when those records live in separate systems. AA-sec is designed around traceability between requirements, security evidence, assessments and release decisions across product lifecycle context. It does not perform or replace a notified-body conformity assessment and does not determine CRA conformity for the manufacturer.
Key takeaway
CRA conformity assessment is a route-selection problem built on product classification. Default-category products can normally use Module A. Important Class I products need a coverage analysis because uncovered requirements can trigger B+C or H. Important Class II products use B+C, H or an eligible certification route, while critical products follow the certification or Class II pathways provided by Article 32.
The best preparation is a traceable route decision: record the product boundary, classification, applicable requirements, standards status, evidence baseline and change triggers before the formal assessment begins. That foundation supports self-assessment, notified-body work and later market-surveillance questions while preserving the manufacturer's responsibility for the product.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Conformity assessment — European Commission
- Technical Competence Requirements for CRA Notified Bodies — ENISA
- Cyber Resilience Act - Implementation — European Commission