CRA Conformity Assessment: When Self-Declaration Is Not an Option

· Eurtifact Platform Team

Context

For most products with digital elements, the CRA allows internal control (module A) — the manufacturer self-declares conformity. But the Regulation carves out three categories where this is not enough:

  • Annex III Class I — Important products, 19 categories: identity management, browsers, password managers, antivirus, VPNs, network management, SIEMs, boot managers, PKI, network interfaces, operating systems, routers/modems/switches, security-related microprocessors/microcontrollers/ASICs/FPGAs, smart home assistants, smart home security devices, internet-connected toys, and personal wearables for health monitoring.
  • Annex III Class II — Important products at a higher tier, 4 categories: hypervisors and container runtime systems, firewalls/IDS/IPS, tamper-resistant microprocessors, tamper-resistant microcontrollers.
  • Annex IV — Critical products: hardware devices with security boxes, smart meter gateways within smart metering systems referred to in Directive (EU) 2019/944, and smartcards or similar devices including secure elements.

Article 32 prescribes the conformity assessment procedure for each tier. For Class II — which includes container runtime systems used by every Kubernetes cluster — module A self-assessment is not available.

Reality Check

Common Belief

“Conformity assessment is a paperwork exercise. We will draw up technical documentation and sign the EU declaration of conformity.”

Why That’s Incomplete

For Class II products, Article 32(3) restricts the manufacturer to:

  • (a) EU-type examination procedure (based on module B) set out in Annex VIII, followed by conformity to EU-type based on internal production control (based on module C); or
  • (b) A conformity assessment based on full quality assurance (based on module H) set out in Annex VIII; or
  • © Where available and applicable, a European cybersecurity certification scheme at assurance level “high” pursuant to Article 27(9).

All three options route through a notified body. The manufacturer does not declare conformity on its own.

For Critical products (Annex IV), Article 8 allows the Commission to require a mandatory European cybersecurity certification at assurance level “substantial” or “high” via delegated act — narrowing the assessment options further.

Engineering Implications

What the Modules Actually Mean

The procedure names come from Decision No 768/2008/EC, the EU’s common framework for the marketing of products. The CRA adapts them in Annex VIII. At a high level:

  • Module A (internal control) — manufacturer self-assessment. Manufacturer draws up technical documentation per Annex VII, ensures the design/development/production/vulnerability handling processes are compliant, affixes the CE marking, and issues the EU declaration of conformity. No external body involved. Not available for Class II.
  • Module B (EU-type examination) — a notified body examines a representative sample (the “type”) of the product and assesses whether it meets the essential cybersecurity requirements. If satisfied, the notified body issues an EU-type examination certificate. The certificate is the input to module C.
  • Module C (conformity to type based on internal production control) — once module B has issued the certificate, the manufacturer ensures that every product in series production conforms to the approved type, and declares conformity. No further notified-body intervention per unit, but the manufacturer must operate quality controls.
  • Module H (full quality assurance) — a notified body assesses the manufacturer’s quality management system for design, manufacture, final product inspection and testing. Approval covers the system, not the type. The notified body conducts periodic audits and may make unannounced visits. The manufacturer then declares conformity for products produced under the approved QMS.

For a software-only Class II product, “production” largely means the build pipeline. Module B+C aligns naturally with a versioned-release model (each major version is a “type”). Module H aligns with a continuous-delivery model under an audited engineering system. Both are valid; the cost and rhythm differ.

Why Container Runtimes Are Class II

Annex III Class II point (1) classifies “hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments” as important products at the higher tier. This means:

  • A team distributing an OCI container runtime (containerd, CRI-O, gVisor, Kata, etc.) for use in the EU is the manufacturer of a Class II product.
  • That distribution cannot rely on module A. A notified body must be involved.
  • The manufacturer must demonstrate not only that the runtime meets the essential cybersecurity requirements in Annex I, but also that the production process maintains that conformity.

This is a significant change for projects that distribute container runtimes commercially in the EU, including most enterprise Kubernetes distributions.

Who Can Be a Notified Body

Article 39 sets the requirements: a notified body must be a third party established under the law of a Member State, with independence, technical competence, and procedures that ensure confidentiality. It must be designated by a notifying authority following the procedures in Articles 36–43.

Chapter IV (Articles 35–51) on notification of conformity assessment bodies applies from 11 June 2026 — six months earlier than Article 14 reporting. The intent is to have a designated body capacity in place before full application in December 2027.

Failure Modes

Pattern 1: Treating Class II as Class I

A team reads “Important products” in Annex III and stops at Class I. The procedure for Class I (Article 32(2)) allows module A if harmonised standards, common specifications, or EU cybersecurity certification schemes are applied. The team plans for self-assessment, then discovers their product (a hypervisor, a firewall) is actually Class II — where module A is never available.

The correction can be expensive if discovered late. Module B requires preparing a representative sample of the product for examination. Module H requires having a documented and operating QMS. Neither is built in a quarter.

Pattern 2: Assuming the Notified Body Knows the Product

A notified body conducting an EU-type examination depends on the technical documentation prepared by the manufacturer under Annex VII. If the documentation is thin, the body’s questions multiply and the timeline extends. Notified bodies are not paid to reverse-engineer the product; they assess what is documented.

For software products in particular, the documentation is more than a feature list. Annex VII requires “a general description of the product with digital elements” and information enabling the body to verify each essential cybersecurity requirement is met. Architecture diagrams, threat models, vulnerability handling procedures, and the SBOM are all part of the package.

Pattern 3: No Plan for Subsequent Versions

A manufacturer goes through module B for version 5.0, receives the EU-type examination certificate, and ships. Version 5.1 introduces a substantial modification — which under Article 13(2) and the definition in Article 3(30) means a change that affects compliance with the essential cybersecurity requirements or modifies the intended purpose.

A substantial modification triggers a fresh conformity assessment. A team without a plan for what counts as “substantial” — and a notified body relationship that can re-examine quickly — discovers in the middle of a release cycle that their new build is non-compliant for the EU market.

Pattern 4: Geographic Mismatch With the Notified Body

Notified bodies are designated by Member States. A manufacturer in one Member State can use a notified body from another, but practical considerations (language of the technical documentation, on-site audits for module H, time zones) matter. Choosing a notified body without operational fit raises the cost of every interaction.

What “Good” Looks Like

A manufacturer of a Class II product that is ready for the December 2027 deadline has:

  1. A classification decision recorded in writing: For each product placed on the EU market, the Annex III classification (Class I or Class II) is explicit, justified, and dated. Where the product is borderline, the reasoning is documented and reviewed by counsel.

  2. A chosen module: B+C or H, with a stated rationale. Module B+C suits stable release cadences and clear product types; module H suits continuous-delivery models where the engineering system is more stable than individual versions.

  3. A notified body relationship: An NB has been engaged before the application date. The technical documentation package has been reviewed at least informally. The cost and lead time for examination or QMS audits is known.

  4. A substantial-modification policy: An internal rule that says which kinds of code, dependency, or architectural change require re-assessment, and which do not. Without this, every release cycle becomes a regulatory ambiguity.

  5. A path for harmonised standards adoption: When CEN, CENELEC, or ETSI publish harmonised standards under the CRA, the manufacturer applies them where applicable. Conformity to harmonised standards creates a presumption of conformity under Article 27.

  6. Production discipline that matches the module: For module B+C, evidence that every shipped build matches the approved type. For module H, evidence that the QMS is operating as audited — including non-conformance reports and corrective actions.

Limits & Trade-offs

This does not:

  • Define which notified body to choose: The choice depends on technical fit, language, geographic proximity for module H audits, sector experience, and cost. The CRA does not rank notified bodies.
  • Replace the essential cybersecurity requirements: A successful conformity assessment is evidence of conformity, not a separate substantive standard. Annex I is the substantive obligation; Annex VIII is the procedural one.
  • Cover the conformity assessment of open-source steward products: Article 24 and Article 25 introduce a different, lighter regime for open-source software stewards and security attestation of FOSS. This article addresses manufacturers placing Class II products on the market in the course of commercial activity.
  • Eliminate timing risk: Notified body capacity in Europe is finite. Manufacturers that wait until late 2027 to begin will find queues. Chapter IV explicitly applies from June 2026 to give the system time to build capacity.

Key Takeaways

  • For Annex III Class II products — including container runtime systems and hypervisors — Article 32(3) blocks module A self-assessment. Module B+C, module H, or a high-assurance EU cybersecurity certification scheme is required.
  • All three options involve a notified body. The manufacturer does not affix the CE mark on its own authority for Class II.
  • Chapter IV on notification of conformity assessment bodies applies from 11 June 2026 — building the system before full application.
  • Substantial modifications under Article 3(30) trigger a fresh assessment. A clear internal policy is essential.
  • Notified body capacity is a finite resource. Manufacturers who engage early — in 2026 — have the most options.

This article reflects the Eurtifact platform team’s reading of the Cyber Resilience Act as of May 2026. Article and Annex references were verified against the consolidated EUR-Lex text (CELEX 32024R2847) and are linked to the on-site CRA explorer. It is not legal advice. For obligations specific to your products, consult qualified legal counsel.