Module A is the Cyber Resilience Act (CRA) conformity assessment route based on internal control. Where Article 32 allows this procedure, the manufacturer performs the assessment itself and declares, on its own responsibility, that the product with digital elements and the relevant manufacturer processes meet the applicable essential cybersecurity requirements.
That makes Module A a self-assessment route, but not a reduced-obligation route. The manufacturer still needs technical documentation, controlled product-development and vulnerability-handling processes, evidence that the applicable Annex I requirements are met, an EU declaration of conformity, and the CE marking process required by the CRA.
The first decision is therefore not "Can we document Module A?" It is "Does Article 32 allow Module A for this product and the way we intend to demonstrate conformity?"
Where Module A sits in the CRA conformity framework
Article 32 lists the conformity assessment procedures that can be used to demonstrate conformity with the CRA's essential cybersecurity requirements.
The available routes 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).
The European Commission describes Module A as the self-assessment or internal-control procedure.
However, Article 32 places additional conditions on certain product categories. Manufacturers should therefore determine the product's classification and applicable conformity route before assuming that internal control is sufficient.
What internal control means
Annex VIII Part I defines internal control as a conformity assessment procedure in which the manufacturer fulfils the specified obligations and declares on its sole responsibility that:
- the product satisfies the essential cybersecurity requirements in Annex I Part I; and
- the manufacturer meets the vulnerability-handling requirements in Annex I Part II.
The practical consequence is that responsibility stays with the manufacturer.
There is no external notified body performing the core Module A assessment for the manufacturer. The manufacturer must be able to show how it reached the conformity conclusion and retain the evidence supporting that conclusion.
Step 1: confirm that Module A is an available route
Before building a Module A evidence package, determine whether Article 32 permits the route for the product.
At minimum, record:
- the product with digital elements being assessed;
- the product category and classification;
- the applicable Article 32 paragraph;
- any harmonised standards, common specifications, or applicable certification schemes used;
- whether those specifications are applied fully or only in part; and
- the reason the selected conformity assessment route is legally available.
This route-selection record is useful because product classification, standards coverage, and the selected conformity method are related decisions. Treating them as separate undocumented assumptions makes later review difficult.
Step 2: define the exact assessment scope
Module A should be applied to a clearly defined product scope.
Useful scope information includes:
- product name and model;
- hardware variants;
- software or firmware versions;
- external services that form part of the product where relevant;
- intended purpose and reasonably foreseeable use;
- deployment assumptions;
- interfaces and exposed functions;
- third-party components;
- release or build identifiers; and
- support-period information.
The purpose is to prevent evidence collected for one version, variant, or release from being silently reused for another without an explicit assessment.
Step 3: build the technical documentation
Annex VIII requires the manufacturer to draw up the technical documentation described in Annex VII.
The technical documentation is not merely a final report. It should allow the relevant authority to assess how the manufacturer addressed the applicable CRA requirements.
A practical evidence set can include:
- a general description of the product;
- intended purpose;
- design and development information;
- system and security architecture;
- cybersecurity risk assessment;
- identified essential cybersecurity requirements;
- explanations of the solutions used to meet those requirements;
- standards or technical specifications applied;
- relevant test results;
- vulnerability-handling information;
- SBOM-related evidence where applicable;
- release information; and
- records supporting the final conformity conclusion.
The precise content should follow Annex VII and the actual characteristics of the product.
Step 4: map Annex I requirements to evidence
A strong Module A assessment should make the link between requirement and evidence explicit.
Instead of maintaining a generic statement that the product "meets Annex I," create a traceable mapping such as:
| Assessment item | Evidence example | |---|---| | Product security requirement | Design record, configuration baseline, test result | | Cybersecurity risk | Risk assessment entry and treatment decision | | Third-party component | SBOM entry, supplier or component evidence | | Vulnerability handling | Intake, triage, remediation and disclosure workflow | | Security update capability | Update design and verification records | | Release decision | Approval record and unresolved-risk decision | | Product version | Immutable release or artifact identifier |
The CRA does not prescribe this table format. It is an engineering method for making the manufacturer's reasoning reviewable.
Step 5: control design, development and production
Annex VIII Part I requires the manufacturer to take the measures necessary so that design, development, production, vulnerability handling, and their monitoring ensure conformity with the essential cybersecurity requirements.
For a software or embedded-product organisation, evidence may therefore come from multiple lifecycle stages.
Examples include:
- secure-development requirements;
- architecture and threat-analysis records;
- code-review or verification records;
- security testing;
- build and release controls;
- component and dependency management;
- configuration management;
- production or provisioning controls;
- release approval;
- vulnerability intake and triage;
- remediation decisions;
- security-update processes; and
- monitoring of the effectiveness of these processes.
The important point is not to collect every possible artefact. It is to retain evidence that supports the requirements applicable to the specific product.
Step 6: include vulnerability handling in the assessment
Module A does not end when a release leaves development.
Annex VIII explicitly includes vulnerability handling among the processes the manufacturer must control. The conformity assessment therefore needs to account for Annex I Part II as well as the product requirements in Part I.
A practical vulnerability-handling evidence chain may show:
- how vulnerability information is received;
- how the affected product and version are identified;
- how severity and exploitability are assessed;
- how remediation decisions are recorded;
- how fixes are developed and verified;
- how security updates or mitigations are delivered;
- how relevant disclosure or reporting decisions are handled; and
- how the evidence and decision history are retained.
This is one reason a purely document-at-the-end approach to Module A is risky operationally: key conformity evidence is created throughout the lifecycle.
Step 7: verify evidence against the exact product state
Before the final conformity decision, review whether the evidence actually corresponds to the product that will be placed on the market.
Check items such as:
- exact software and firmware versions;
- build or artifact identifiers;
- configuration defaults;
- included components;
- SBOM version;
- security-test results;
- unresolved vulnerabilities;
- deviations and accepted risks;
- user documentation;
- update configuration; and
- the support-period statement.
A test report from an earlier build is not automatically evidence for a later release. The relationship between the evidence and final product state should be explicit.
Step 8: document unresolved findings
Self-assessment should not erase uncertainty.
If the assessment finds an unresolved issue, record:
- the affected requirement;
- the finding;
- the supporting evidence;
- the product scope;
- the owner;
- the planned treatment;
- the decision status; and
- whether the issue blocks the conformity conclusion.
The final decision should be based on the state that actually exists, not the state the team expects to achieve later.
Step 9: perform a final conformity review
Before the manufacturer declares conformity, perform a controlled review of the assessment package.
A useful review asks:
- Is Module A permitted for this product?
- Is the assessed product scope unambiguous?
- Are all applicable Annex I requirements addressed?
- Is the cybersecurity risk assessment current?
- Does each significant conclusion have supporting evidence?
- Are the technical-documentation references valid?
- Are open vulnerabilities and deviations visible?
- Is vulnerability handling covered?
- Does the evidence correspond to the final release state?
- Are responsibilities and approvals recorded?
This review can be organised internally. The legal responsibility under Module A remains with the manufacturer.
Step 10: declaration of conformity and CE marking
When the manufacturer has completed the applicable conformity assessment and determined that the requirements are met, the CRA framework requires the manufacturer to draw up the EU declaration of conformity and affix the CE marking in accordance with the Regulation.
The declaration should not be treated as the evidence package itself. It is the formal outcome of the conformity assessment.
The underlying technical documentation and decision evidence need to remain available as required by the CRA.
What Module A does not mean
Several interpretations create avoidable risk.
"Self-assessment means no independent evidence is needed"
Incorrect. Self-assessment means the manufacturer performs the conformity assessment rather than relying on the notified-body route for the Module A procedure. The manufacturer's conclusion still needs supporting technical and process evidence.
"Passing security tests proves CRA conformity"
Security testing can be important evidence, but Article 32 concerns the product and the processes put in place by the manufacturer. Annex I also covers vulnerability handling and other lifecycle requirements.
"Module A is available for every CRA product"
Not automatically. Article 32 sets different conformity-assessment conditions depending on the product category and on matters such as the use of harmonised standards, common specifications, or relevant certification schemes.
"Technical documentation can be created after release"
The conformity assessment and required technical documentation are part of the process before placing the product on the market. The evidence should reflect the product state on which the conformity decision is based.
A practical Module A evidence structure
A manufacturer can organise the evidence package into a small number of controlled areas.
1. Scope and route selection
Record the product, classification, release, applicable Article 32 route, and rationale.
2. Requirements and risk
Map applicable Annex I requirements to the cybersecurity risk assessment and identified controls.
3. Product evidence
Retain architecture, security design, testing, configuration, component, update, and release evidence relevant to the assessment.
4. Process evidence
Show how development, production, vulnerability handling, and monitoring processes support conformity.
5. Findings and decisions
Keep open findings, accepted deviations, remediation decisions, approvals, and their supporting rationale.
6. Formal conformity output
Link the final assessment state to the EU declaration of conformity and the exact product version being placed on the market.
This structure is not mandated by the CRA, but it helps keep the manufacturer's conformity argument reproducible.
Keep the assessment maintainable
The most useful Module A process is one that can be updated when the product changes.
Manufacturers should define triggers for reassessing evidence, for example:
- a new release;
- a significant architecture change;
- a new externally exposed interface;
- a major dependency change;
- a changed cybersecurity risk;
- a newly discovered vulnerability;
- a change in applied standards or specifications; or
- a change that may affect the product classification or conformity route.
Not every change necessarily requires a completely new assessment package. The organisation should determine what changed, which requirements are affected, and which evidence must be updated.
Operationalising the evidence
Module A creates a traceability problem as much as a documentation problem: requirements, risk decisions, security evidence, vulnerability work, and the exact release state need to remain connected. AA-sec is designed around traceability between requirements, evidence, decisions, and product lifecycle context; its MVP scope includes assessment/readiness workflows and release evidence packages. AA-sec does not determine CRA conformity; the conformity assessment decision remains with the manufacturer.
Module A readiness checklist
Before relying on internal control, verify that you can answer:
- Which Article 32 provision allows Module A for this product?
- What exact product, variant, and release are being assessed?
- Which Annex I requirements apply?
- Where is the current cybersecurity risk assessment?
- What evidence supports each material conformity conclusion?
- Which standards or specifications were used?
- Are design, development, production, and vulnerability-handling processes covered?
- Can evidence be traced to the exact release state?
- Are unresolved findings and deviations visible?
- Is the technical documentation complete enough to reconstruct the assessment?
- Is the final conformity decision recorded?
- Is the EU declaration of conformity linked to the assessed product state?
Key takeaway
CRA Module A lets a manufacturer use internal control for conformity assessment where Article 32 permits that route. It does not reduce the manufacturer's responsibility. A defensible Module A process depends on clear product scope, current technical documentation, traceable Annex I evidence, controlled development and vulnerability-handling processes, and a final conformity decision tied to the exact product state.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission