Module B plus Module C is the Cyber Resilience Act (CRA) conformity assessment route that combines external EU-type examination with manufacturer-controlled conformity to the approved type. Under Module B, a notified body examines a representative product type and the supporting technical documentation. Under Module C, the manufacturer then has to ensure and declare that the products placed on the market remain in conformity with that approved type and the applicable CRA requirements.
This is therefore a two-stage route rather than a one-time external review. The notified body's type examination establishes an approved technical basis, while the manufacturer remains responsible for keeping later production, variants, releases, and vulnerability-handling processes aligned with that basis.
For product teams, the practical task is to control the boundary between the examined type and the products actually released.
Where Module B plus C sits in the CRA framework
Article 32 identifies several conformity assessment routes under the CRA, including:
- internal control based on Module A;
- EU-type examination based on Module B followed by conformity to type based on Module C;
- full quality assurance based on Module H; and
- where available and applicable, a European cybersecurity certification scheme under Article 27(9).
Which route is available or required depends on the product category, classification, and the conditions in Article 32.
For important Class I products, Module B plus C can become relevant where the conditions for using internal control are not met, including cases where relevant harmonised standards, common specifications, or qualifying certification schemes are not fully applied or are unavailable.
For important Class II products, Module B plus C is one of the third-party conformity routes available alongside Module H and, where applicable, a qualifying European cybersecurity certification scheme.
Manufacturers should therefore confirm route eligibility before preparing a Module B application.
What Module B examines
Annex VIII Part II defines EU-type examination as the part of the conformity assessment procedure in which a notified body examines the technical design of a product with digital elements and verifies that the design meets the applicable essential cybersecurity requirements.
The manufacturer submits an application to a notified body. The application is tied to a defined product type and includes the documentation needed for the notified body to understand the design and assess conformity.
The exact scope matters. A vague statement such as "our software platform" is not enough for robust conformity control. The examined type should be identifiable through controlled product information such as:
- product name and model;
- hardware configuration where relevant;
- software or firmware version or version family;
- intended purpose;
- relevant deployment models;
- interfaces and exposed functions;
- supported variants;
- configuration assumptions;
- applicable support-period information; and
- the technical documentation used for examination.
The objective is to make it clear what the notified body's certificate actually covers.
Step 1: define the type before submitting evidence
Before approaching the notified body, define the product type precisely.
A practical type-definition record can include:
- commercial product name;
- internal product identifier;
- version or release baseline;
- supported variants;
- hardware revision where relevant;
- software and firmware baseline;
- intended purpose;
- architecture boundaries;
- external services forming part of the product where relevant;
- major security-relevant configurations;
- third-party components;
- support period; and
- applicable CRA product classification.
This record becomes the anchor for the examination and for later Module C conformity control.
If the examined type is not defined clearly, teams may later struggle to decide whether a changed release is still covered by the approved type.
Step 2: prepare the technical documentation
The technical documentation should enable the notified body to assess whether the product type meets the CRA's applicable essential cybersecurity requirements.
A practical evidence package can include:
- product description and intended purpose;
- architecture and design information;
- cybersecurity risk assessment;
- mapping of applicable Annex I requirements;
- security requirements;
- design decisions and compensating controls;
- SBOM and component information where relevant;
- interface and attack-surface information;
- security test plans and results;
- vulnerability-handling processes;
- update mechanisms;
- support-period information;
- release and configuration identifiers; and
- evidence supporting the manufacturer's conformity claims.
The CRA does not prescribe this exact evidence list as a template. It is an operational way to organise the material required by the regulation and the notified body's assessment process.
Step 3: make the requirement-to-evidence chain visible
A notified-body review is easier to support when each applicable requirement is linked to concrete evidence.
For example:
| Assessment question | Evidence example | |---|---| | Which requirement applies? | Annex I requirement mapping | | Why does it apply? | Product scope and risk assessment | | How is it implemented? | Design record or security control description | | How was it verified? | Test report or review record | | What remains open? | Risk treatment or deviation record | | Which exact type was assessed? | Version, build, or configuration baseline |
Avoid relying on a single statement that the product "meets the CRA." The useful evidence is the traceable chain showing how that conclusion was reached.
Step 4: support the notified body's examination
During Module B, the notified body assesses the submitted technical design and supporting evidence.
Manufacturers should be prepared to explain:
- the product architecture;
- the cybersecurity risk assessment;
- the relationship between identified risks and implemented controls;
- how third-party components are managed;
- how security requirements are verified;
- how vulnerabilities are handled;
- how security updates are produced and distributed;
- how the support period is managed; and
- how the exact product type under examination is identified.
The notified body may request additional evidence or clarification where the submitted material is insufficient.
Internal owners should therefore be identified in advance for architecture, product security, testing, compliance, vulnerability management, and release control.
Step 5: understand the EU-type examination certificate
When the notified body determines that the examined type meets the applicable requirements, it issues an EU-type examination certificate under the Module B procedure.
The certificate should be treated as a controlled conformity record tied to the examined type and assessment scope.
Operationally, teams should retain:
- the certificate;
- the approved type definition;
- technical documentation submitted for assessment;
- final assessment evidence;
- correspondence relevant to the conformity conclusion;
- conditions or limitations associated with the certificate; and
- the version of the product evidence that supported the approval.
The certificate is not permission to treat every future product change as automatically covered.
Module C starts after the type is approved
Annex VIII Part III covers conformity to type based on internal production control.
Under Module C, the manufacturer ensures that products placed on the market conform to the type described in the EU-type examination certificate and satisfy the applicable CRA requirements.
That means the manufacturer needs controls that preserve conformity after the notified body's Module B examination.
Typical areas include:
- production and release control;
- configuration management;
- software and firmware versioning;
- reproducible identification of released artifacts;
- controlled changes;
- security verification;
- vulnerability handling;
- deviations;
- release approval; and
- retained evidence showing conformity to the approved type.
Module C therefore turns type approval into an ongoing operational discipline.
Step 6: create a conformity-to-type baseline
After Module B approval, establish a baseline that teams can use to assess later releases.
A useful baseline can identify:
- approved product type;
- approved hardware revision;
- approved software or firmware baseline;
- security-relevant architecture;
- applicable requirements;
- critical interfaces;
- relevant third-party dependencies;
- required security controls;
- approved configuration constraints;
- verification evidence; and
- the corresponding EU-type examination certificate.
Each later release can then be compared against that baseline.
Step 7: control product changes
Change control is one of the most important parts of Module B plus C in practice.
Not every code change automatically means a new type examination, but manufacturers need a disciplined way to assess whether a change affects the approved type or the product's conformity with the applicable CRA requirements.
A change assessment can consider:
- architecture changes;
- new interfaces;
- new or replaced components;
- changed cryptographic mechanisms;
- authentication changes;
- new remote-processing functionality;
- changed update mechanisms;
- hardware revisions;
- major dependency changes;
- security-relevant configuration changes;
- changed intended purpose; and
- changes affecting the cybersecurity risk assessment.
The assessment decision should be recorded with supporting evidence.
Where a change may affect the validity of the type examination, the manufacturer should engage the notified body as required by the applicable procedure and certificate conditions.
Step 8: keep release evidence tied to the approved type
A common operational risk is losing the connection between conformity evidence and the exact released product.
For each release, teams should be able to identify:
- the release or build identifier;
- source or artifact reference used internally;
- product variant;
- applicable type-examination certificate;
- differences from the approved baseline;
- change assessment;
- security test results;
- open deviations;
- vulnerability status;
- release approval; and
- the resulting declaration and marking records where applicable.
The purpose is not to duplicate every Module B document for every build. It is to show that the released product remains inside the approved conformity basis.
Step 9: manage vulnerabilities without losing type control
Vulnerability handling continues after type examination.
A newly discovered vulnerability can lead to:
- a software update;
- component replacement;
- configuration change;
- architectural mitigation;
- changed user guidance; or
- a broader product redesign.
Those actions need both security handling and conformity impact assessment.
A practical workflow records:
- the vulnerability and affected versions;
- the remediation decision;
- the product change;
- verification of the fix;
- the effect on the approved type;
- whether notified-body interaction is required; and
- the release evidence showing the updated product remains appropriately controlled.
This avoids treating vulnerability remediation and conformity management as separate processes.
Step 10: retain evidence for authorities and future assessment
Manufacturers should retain the technical and conformity records required by the CRA for the applicable retention period.
For Module B plus C, useful retained records include:
- technical documentation;
- risk assessments;
- assessment submissions;
- notified-body findings;
- the EU-type examination certificate;
- type baseline records;
- release records;
- change assessments;
- vulnerability decisions;
- testing evidence;
- declarations of conformity; and
- records showing how later products remained aligned with the approved type.
The important principle is traceability over time.
Module B + C versus Module A
Module A relies on manufacturer internal control without the Module B notified-body type examination.
Module B plus C adds external examination of the type and then requires the manufacturer to keep production in conformity with that approved type.
The difference is therefore not simply "external versus internal." Module B plus C creates a defined approved type that later releases and production outputs must continue to match.
Module B + C versus Module H
Module H centres conformity assessment on an approved quality system covering design, development, final inspection and testing, and vulnerability handling.
Module B plus C instead centres the external assessment on the product type, followed by manufacturer-controlled conformity to that type.
A manufacturer choosing between available routes may consider factors such as:
- product portfolio structure;
- release frequency;
- degree of product variation;
- change rate;
- quality-system maturity;
- notified-body scope;
- evidence architecture; and
- the conformity routes allowed by Article 32.
Neither route should be treated as universally easier.
Operationalising the evidence
Module B plus C creates a continuing traceability problem: teams need to connect the examined type, assessment evidence, changes, vulnerabilities, and later release decisions without mixing product versions or losing the approved baseline. AA-sec is designed around traceability between requirements, evidence, decisions, and exact product or lifecycle context; its MVP scope includes assessment/readiness workflows, release blockers, and evidence packages. The manufacturer and notified body retain their respective regulatory roles.
Practical readiness checklist
Before starting a Module B plus C assessment, verify that you can answer:
- Why is Module B plus C available or required for this product under Article 32?
- What exact product type will be examined?
- Which versions, variants, and configurations are in scope?
- Is the technical documentation complete enough for notified-body review?
- Can each applicable Annex I requirement be linked to evidence?
- Is the cybersecurity risk assessment current?
- Are test results tied to the examined product baseline?
- Is vulnerability handling documented and operating?
- Can the approved type be represented as a controlled baseline?
- Is there a defined process for assessing product changes?
- Can each later release be traced to the approved type?
- Can security fixes be assessed for conformity impact?
- Are certificate, assessment, release, and change records retained together?
- Are responsibilities clear for notified-body communication?
Key takeaway
CRA Module B plus Module C is a two-stage conformity route. The notified body examines and approves a defined product type under Module B; the manufacturer then remains responsible for ensuring that later products conform to that type under Module C. The strongest implementation is therefore not a one-off assessment package, but a controlled evidence chain linking the approved type to every relevant change and release.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission