Module H is the Cyber Resilience Act (CRA) conformity assessment route based on full quality assurance. Under this route, the manufacturer operates an approved quality system for the design, development, final inspection and testing of the products concerned and for vulnerability handling, while a notified body assesses and surveils that system.
This makes Module H different from a simple product-by-product review. The manufacturer still needs to demonstrate that the relevant products with digital elements satisfy the essential cybersecurity requirements in Annex I Part I and that its vulnerability-handling processes satisfy Annex I Part II, but the conformity route is organised around a controlled and approved quality system.
The practical question for manufacturers is therefore not only whether a specific product passes a security assessment. It is whether the organisation can show that its processes consistently produce, verify, release, and maintain products in line with the applicable CRA requirements.
Where Module H sits in the CRA conformity framework
Article 32 lists the conformity assessment procedures available under the CRA.
These include:
- 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).
Module H is relevant both as a generally available conformity route and as one of the routes required for certain product categories where self-assessment is not sufficient.
For important Class I products, Article 32 can require either Module B plus C or Module H where the manufacturer has not fully applied relevant harmonised standards, common specifications, or qualifying certification schemes, or where those instruments do not exist.
For important Class II products, Module H is one of the available routes alongside Module B plus C and, where applicable, a qualifying European cybersecurity certification scheme.
Manufacturers should therefore determine product classification and conformity-route eligibility before preparing the Module H assessment.
What full quality assurance means
Annex VIII Part IV defines conformity based on full quality assurance as a procedure in which the manufacturer:
- fulfils the obligations specified in Part IV;
- ensures and declares on its sole responsibility that the products or product categories concerned satisfy Annex I Part I; and
- ensures that its vulnerability-handling processes meet Annex I Part II.
The manufacturer must operate an approved quality system and keep that system effective throughout the support period.
The system is not approved by the manufacturer itself. A notified body evaluates it and performs surveillance.
That distinction matters operationally. Module H still leaves the conformity declaration with the manufacturer, but the manufacturer's quality system is subject to external assessment and ongoing oversight.
Step 1: define the product or product-category scope
Before approaching a notified body, define exactly what the quality system and conformity assessment are intended to cover.
A useful scope record includes:
- product names and models;
- product categories;
- variants;
- software and firmware lines;
- applicable hardware families;
- intended purposes;
- major deployment models;
- support periods;
- relevant product classifications under the CRA;
- applicable Annex I requirements; and
- organisational units responsible for development, release, and vulnerability handling.
The scope should be precise enough that both the manufacturer and notified body can tell which products, processes, sites, and lifecycle activities are covered.
Avoid defining the scope only in organisational language such as "all secure products." The relationship between the quality system and the actual products with digital elements needs to be explicit.
Step 2: document the quality system
The core of Module H is the quality system.
Annex VIII Part IV requires the manufacturer to submit an application for assessment of its quality system to a notified body. The documentation needs to make the quality system understandable and reviewable.
A practical quality-system description can cover:
- quality objectives;
- organisational structure;
- responsibilities and authority;
- design and development controls;
- cybersecurity risk assessment;
- security requirements management;
- architecture and design review;
- implementation controls;
- verification and validation;
- final inspection and testing;
- release approval;
- configuration management;
- component and dependency management;
- vulnerability intake and triage;
- remediation and update processes;
- post-release monitoring;
- internal audits;
- corrective actions; and
- management review.
The objective is not to create a separate CRA bureaucracy if existing controlled processes already address these activities. The manufacturer should show how its actual operating system meets the Module H requirements.
Step 3: connect the quality system to Annex I
A quality system is not useful for Module H merely because it is formal or mature.
The manufacturer needs to show how the system supports compliance with the CRA's essential cybersecurity requirements.
A practical mapping can connect:
| Quality-system area | CRA evidence example | |---|---| | Requirements management | Applicable Annex I requirement mapped to product requirement | | Risk management | Current cybersecurity risk assessment and treatment decision | | Design control | Architecture review, threat analysis, security design record | | Verification | Test plans, security testing, review evidence | | Release control | Approval record tied to exact release state | | Component management | SBOM and dependency records | | Vulnerability handling | Intake, triage, remediation, disclosure, reporting context | | Corrective action | Root cause, fix, verification, recurrence prevention | | Change control | Impact assessment for product or process changes | | Management review | Evidence that quality-system effectiveness is reviewed |
The CRA does not prescribe this exact table. It is an engineering way to make the relationship between process and regulatory requirement visible.
Step 4: include vulnerability handling as part of the quality system
Module H explicitly covers vulnerability handling.
That means vulnerability management cannot sit outside the assessed system as an informal security-team activity.
The quality system should make clear:
- how vulnerability reports are received;
- who owns triage;
- how affected products and versions are identified;
- how severity, exploitability, and impact are assessed;
- how remediation decisions are made;
- how fixes are developed and verified;
- how updates are released;
- how disclosure and reporting decisions are handled;
- how decisions and supporting evidence are retained; and
- how process effectiveness is monitored.
The manufacturer should also be able to demonstrate that these processes remain effective throughout the product's support period.
Step 5: prepare evidence of actual operation
Written procedures alone are not enough to show that a quality system is operating effectively.
Prepare records showing that the defined processes are used in practice.
Examples include:
- completed design reviews;
- approved requirements;
- risk assessments;
- threat analyses;
- test reports;
- release approvals;
- deviation records;
- change-control records;
- vulnerability cases;
- remediation decisions;
- corrective-action records;
- internal-audit findings;
- management-review records; and
- evidence of follow-up on identified issues.
The evidence should be representative of the scope submitted for assessment.
A procedure saying that every release receives security review is stronger when paired with actual release records that demonstrate the review, findings, decisions, and approvals.
Step 6: identify the notified body
Module H requires a notified body that is authorised for the relevant CRA conformity assessment activities.
Manufacturers should verify:
- the notified body's scope of notification;
- whether it covers the relevant products or product categories;
- whether it covers Module H;
- whether the proposed assessment scope matches the notified body's competence; and
- which organisational sites and processes will be included.
The notified body is not a generic cybersecurity consultant. It performs a regulatory conformity assessment role under the CRA framework.
Step 7: prepare the quality-system application
The manufacturer submits an application to a notified body for assessment of the quality system.
The application should clearly identify:
- the manufacturer;
- the products or product categories concerned;
- the quality-system documentation;
- relevant technical documentation;
- the intended assessment scope; and
- the evidence needed to demonstrate operation of the system.
Internal preparation should also identify the people responsible for explaining each major process during the assessment.
Typical participants may include:
- engineering;
- product security;
- quality;
- compliance;
- release management;
- vulnerability management;
- operations; and
- product ownership.
The exact team depends on the organisation and assessment scope.
Step 8: expect assessment of both documentation and implementation
A Module H assessment is not limited to checking whether written procedures exist.
The notified body needs to determine whether the quality system meets the applicable requirements and whether the manufacturer can operate it effectively.
Manufacturers should therefore expect questions such as:
- How are CRA requirements translated into engineering requirements?
- How are cybersecurity risks identified and treated?
- How does a release inherit evidence from previous versions?
- What happens when a control fails?
- How are unresolved vulnerabilities handled?
- How are product changes assessed?
- How are quality-system changes controlled?
- How is evidence retained?
- How are internal audits performed?
- How are corrective actions closed?
- How does management review system effectiveness?
Teams should answer from controlled records rather than from informal explanations where possible.
Step 9: manage findings and corrective actions
An assessment can identify nonconformities, weaknesses, or evidence gaps.
A disciplined response should record:
- the finding;
- the affected process;
- the affected product scope;
- root cause where appropriate;
- corrective action;
- owner;
- target date;
- verification method; and
- closure evidence.
Corrective action should address the process problem, not merely produce a missing document for the assessor.
For example, if release decisions cannot be traced to the actual tested build, the corrective action should strengthen release traceability rather than only adding one retrospective record.
Step 10: maintain the approved system
Approval is not the end of the Module H lifecycle.
Annex VIII requires the manufacturer to maintain the effectiveness of the approved quality system throughout the support period.
That means controlled change management is essential.
Changes that may affect the system include:
- organisational restructuring;
- new development sites;
- new product families;
- major architecture changes;
- new build or release processes;
- changed vulnerability-handling processes;
- outsourced activities;
- new testing methods; and
- significant process automation.
The manufacturer should determine whether a change needs to be communicated to the notified body under the applicable assessment arrangements.
Step 11: prepare for surveillance
Module H includes notified-body surveillance.
The purpose is to make sure the manufacturer continues to fulfil the obligations arising from the approved quality system.
Surveillance may therefore require access to:
- development and production locations;
- inspection and testing locations;
- quality-system documentation;
- audit records;
- test records;
- product evidence;
- corrective-action records;
- vulnerability-handling evidence; and
- other information relevant to the approved system.
The practical implication is that Module H evidence should remain continuously usable. Reconstructing the whole system only before a surveillance visit is a fragile operating model.
Step 12: keep product evidence connected to process evidence
Module H is process-oriented, but product evidence still matters.
A quality system should make it possible to trace from a specific product or release to:
- applicable requirements;
- risk assessment;
- design decisions;
- component state;
- tests;
- security findings;
- deviations;
- vulnerability decisions;
- approvals; and
- support obligations.
This linkage is important because the manufacturer declares conformity for actual products, not for an abstract process.
Module H versus Module A
Module A and Module H both place responsibility for the conformity declaration on the manufacturer, but they operate differently.
Under Module A:
- the manufacturer relies on internal control;
- there is no notified-body approval of the quality system as part of the Module A procedure; and
- the manufacturer organises and documents the conformity evidence internally.
Under Module H:
- the manufacturer operates an approved quality system;
- a notified body assesses that quality system;
- the system covers design, development, final inspection and testing, and vulnerability handling; and
- the manufacturer remains subject to notified-body surveillance.
The correct route depends on Article 32, product classification, and the manufacturer's chosen conformity strategy.
Module H versus Module B plus C
Module B plus C separates type examination from conformity to the approved type.
Module H instead centres the conformity route on a quality system covering the manufacturer's lifecycle processes.
That does not make one route universally better than the other.
A manufacturer should evaluate factors such as:
- product portfolio structure;
- product variability;
- release frequency;
- organisational maturity;
- existing quality-system controls;
- notified-body scope;
- evidence model; and
- the conformity routes permitted by Article 32.
The decision should be documented rather than treated as an informal preference.
Do you need ISO 9001?
The CRA describes the required Module H quality system in Annex VIII. It does not state that ISO 9001 certification by itself satisfies Module H.
An existing quality-management system can provide useful organisational foundations, but manufacturers should assess it specifically against the CRA Module H requirements.
In particular, the system needs to cover cybersecurity-specific design, development, testing, and vulnerability-handling obligations.
Do not assume that an existing quality certificate automatically establishes CRA conformity.
Build an evidence model for repeated assessments
For organisations with several products or frequent releases, a useful evidence model separates reusable process evidence from product-specific evidence.
Reusable process evidence may include:
- controlled development procedures;
- vulnerability-management procedures;
- audit methods;
- corrective-action workflows;
- management-review procedures;
- role definitions; and
- approved quality-system documentation.
Product-specific evidence may include:
- product risk assessments;
- product requirements;
- release-specific SBOMs;
- architecture records;
- security testing;
- deviations;
- vulnerability decisions; and
- release approvals.
This separation helps avoid duplicating the same process documentation while still preserving exact product context.
Operationalising the evidence
Module H depends on keeping requirements, quality-system controls, product evidence, vulnerability work, findings, and release decisions connected over time. AA-sec is designed around traceability between requirements, evidence, decisions, assessments, 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 roles in the conformity assessment process.
Practical Module H readiness checklist
Before approaching a notified body, verify that you can answer:
- Which Article 32 provision permits or requires Module H for this product?
- What products, product categories, sites, and processes are in scope?
- Is the quality system documented and actually operating?
- Does the system cover design and development?
- Does it cover final inspection and testing?
- Does it cover vulnerability handling throughout the support period?
- Can Annex I requirements be traced to controlled processes?
- Can product-specific evidence be traced to exact releases?
- Are internal audits performed and recorded?
- Are corrective actions tracked to closure?
- Are quality-system changes controlled?
- Can representative operating evidence be produced?
- Is the selected notified body competent for the intended scope?
- Are responsibilities for assessment and surveillance clear?
Key takeaway
CRA Module H is a full-quality-assurance conformity route built around an approved quality system and notified-body surveillance. It requires more than a strong document set: manufacturers need controlled processes that connect cybersecurity requirements, development, testing, vulnerability handling, corrective action, and product-specific evidence, and they need to keep that system effective throughout the support period.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission