Do not begin CRA control mapping with a generic security-control catalogue and then search for legal requirements that happen to fit it. Start with Annex I and the product's cybersecurity risk assessment. For each applicable requirement, record the required outcome, product-specific risk, control implementation, responsible owner, verification method and evidence location. Keep Part I product properties and Part II vulnerability-handling processes distinct, while allowing one technical control to support more than one requirement where the mapping is explicit.
Start With Annex I, Not With a Generic Control Catalogue
A useful CRA control matrix begins with the Regulation rather than with an existing security-control catalogue. Article 13 requires manufacturers to ensure that products with digital elements satisfy the essential cybersecurity requirements and to undertake a cybersecurity risk assessment that informs planning, design, development, production, delivery and maintenance. A company can reuse controls from existing security programmes, but those controls should be mapped back to the applicable Annex I requirement and the product-specific risk. This prevents a familiar security checklist from becoming a substitute for analysing what the CRA actually requires for the product.
- Create one traceable entry for each applicable Annex I requirement.
- Connect the entry to the Article 13 cybersecurity risk assessment.
- Describe the product-specific security outcome.
- Map existing controls only after the requirement is understood.
- Document why a requirement or control is not applicable where relevant.
Use a Consistent Requirement-to-Control Record
The CRA does not prescribe one mandatory control-matrix format. A practical internal matrix can nevertheless make compliance traceable and reviewable. Each row should identify the legal reference, required security outcome, relevant cybersecurity risk, implemented control, responsible owner, verification method, evidence location, applicable product version and current status. Additional fields can record dependencies, residual risk, standards used and review triggers. The structure should be stable enough that engineering, security, compliance and conformity-assessment teams are referring to the same requirement rather than maintaining incompatible interpretations in separate documents.
- Legal reference.
- Required security outcome.
- Product-specific cybersecurity risk.
- Product or process control.
- Implementation owner.
- Verification method.
- Evidence location.
- Applicable product version.
- Status and residual risk.
- Review trigger.
Separate the Requirement, Control, Test and Evidence
One of the most useful disciplines in a CRA matrix is keeping four concepts separate. The requirement describes what the Regulation expects. The control describes what the manufacturer has implemented to achieve that outcome. The verification method describes how the manufacturer checks whether the control works. The evidence is the durable record showing what was implemented or tested. For example, an Annex I confidentiality requirement is not itself an encryption control. Encryption can be one control, a transport-security test can be one verification activity and the resulting test report can be evidence. Keeping these layers distinct makes gaps easier to identify.
- Requirement: the applicable CRA obligation.
- Control: the mechanism or process used to meet it.
- Verification: how effectiveness is checked.
- Evidence: the retained record of implementation or verification.
- Conclusion: the compliance judgement based on the complete record.
Map the Baseline, Vulnerability and Secure-Default Requirements
The first group of Part I requirements establishes the security baseline for the product. Annex I requires an appropriate level of cybersecurity based on risk, products to be made available without known exploitable vulnerabilities where applicable, secure-by-default configuration and the ability to address vulnerabilities through security updates. Control mapping for these requirements can include product-security requirements, release vulnerability gates, secure configuration baselines, default-account controls, update architecture and release checks. Each mapped control should point to evidence showing how the product version placed on the market actually implements the intended security baseline.
- Part I point 1: risk-appropriate cybersecurity.
- Part I point 2(a): known exploitable vulnerabilities.
- Part I point 2(b): secure-by-default configuration.
- Part I point 2(c): security updates and automatic updates where applicable.
- Evidence examples: release criteria, configuration baselines, vulnerability review records and update tests.
Map Access, Confidentiality and Integrity as Separate Outcomes
Annex I separately addresses protection from unauthorised access, confidentiality and integrity. A single control can support several requirements, but the matrix should not collapse the requirements into one broad security statement. Authentication and access management can support point 2(d). Encryption and access restrictions can support confidentiality under point 2(e). Signatures, authenticated encryption, software verification and configuration protection can support integrity under point 2(f). The matrix should show which security outcome each control addresses and which verification activity demonstrates it. This avoids assuming that encryption, for example, automatically proves authentication, authorisation, confidentiality and integrity simultaneously.
- Point 2(d): protection from unauthorised access.
- Point 2(e): confidentiality.
- Point 2(f): integrity.
- Map authentication and authorisation separately where useful.
- Map confidentiality and integrity tests to their respective outcomes.
Map Data Minimisation and Data Lifecycle Controls
Point 2(g) requires processing to be limited to data that are adequate, relevant and necessary for the intended purpose. Point 2(m) requires the possibility for users to securely and easily remove all data and settings permanently and requires secure transfer where such transfer is available. These requirements cover different stages of the data lifecycle. A control matrix can connect point 2(g) to data inventories, telemetry design reviews and collection minimisation, while point 2(m) can map to deletion workflows, credential cleanup, storage erasure, ownership-transfer functions and decommissioning tests. The evidence should demonstrate actual product behaviour rather than only policy statements.
- Point 2(g): data minimisation.
- Point 2(m): permanent data and settings removal.
- Map telemetry and diagnostic collection decisions.
- Map secure deletion and decommissioning controls.
- Map secure transfer controls where applicable.
Map Availability and Wider Network Impact Separately
Annex I contains two related availability outcomes. Point 2(h) concerns availability of essential and basic product functions, including after an incident, with resilience and denial-of-service mitigation. Point 2(i) concerns minimising negative impact by the product or connected devices on the availability of services provided by other devices or networks. One set of controls can support both, but the risks are different. The matrix can map point 2(h) to resource controls, graceful degradation, recovery and resilience testing, while point 2(i) can map to bounded retries, traffic controls and safeguards against the product becoming a source of disruption.
- Point 2(h): availability and resilience of product functions.
- Point 2(i): impact on availability of external services.
- Map denial-of-service mitigations.
- Map recovery and degraded-mode controls.
- Map controls limiting harmful traffic or retry behaviour.
Map Attack-Surface and Exploitation-Mitigation Controls Separately
Point 2(j) requires attack surfaces to be limited, including external interfaces. Point 2(k) requires reduction of incident impact using appropriate exploitation-mitigation mechanisms and techniques. Attack-surface reduction focuses on reducing opportunities for exploitation before compromise. Exploitation mitigation focuses on limiting consequences if compromise occurs. A product can therefore map interface reduction, disabled services and restricted management endpoints to point 2(j), while least privilege, sandboxing, process isolation and compartmentalisation can map to point 2(k). Keeping the distinction visible produces a stronger defence-in-depth model.
- Point 2(j): attack-surface limitation.
- Point 2(k): exploitation and incident-impact mitigation.
- Map interface and service inventories to point 2(j).
- Map privilege and isolation controls to point 2(k).
- Verify both exposure reduction and post-exploitation containment.
Map Logging and Monitoring to Security Information
Point 2(l) requires security-related information to be provided by recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out mechanism for the user. A control matrix should identify both the event-recording controls and the monitoring or detection controls that use those events. Evidence can include an event catalogue, log-field specification, monitoring architecture, alert tests, log-integrity controls and opt-out verification. Logging and monitoring can share one Annex I reference while still being represented by separate controls where different teams or systems implement them.
- Point 2(l): recording relevant internal activity.
- Point 2(l): monitoring relevant internal activity.
- Map event-generation controls.
- Map monitoring and detection controls.
- Map user opt-out behaviour.
- Map log confidentiality and integrity protections.
Treat Part II as an Operational Control System
Annex I Part II concerns vulnerability handling and should not be reduced to a single vulnerability-management row. It contains multiple operational requirements that continue through the support period. Manufacturers should map each requirement to the process, tooling, owner and evidence that supports it. Part II controls can span product security, engineering, release management, security communications and vulnerability disclosure teams. A Part I design control can reduce the chance of vulnerabilities, but it does not replace the Part II processes needed to identify, assess, remediate and communicate vulnerabilities after release.
- Create separate Part II control rows.
- Assign operational owners.
- Identify support-period processes.
- Connect vulnerability records to affected product versions.
- Keep vulnerability handling distinct from product-design controls.
Map Part II Vulnerability Identification and Remediation
Part II point 1 requires vulnerabilities and components to be identified and documented, including an SBOM in a commonly used machine-readable format covering at least top-level dependencies. Point 2 requires vulnerabilities to be addressed and remediated without delay in relation to risk, including security updates, with security updates separated from functionality updates where technically feasible. A matrix can connect these requirements to component inventories, SBOM generation, vulnerability intake, affected-version analysis, remediation workflows, security patch development and verification. The evidence should show both what was discovered and how the manufacturer acted on it.
- Part II point 1: vulnerability and component identification.
- Part II point 1: SBOM.
- Part II point 2: risk-based remediation without delay.
- Part II point 2: security updates.
- Evidence examples: SBOMs, vulnerability records, remediation tickets and test reports.
Map Testing, Disclosure and Vulnerability-Reporting Channels
Part II point 3 requires effective and regular tests and reviews of product security. Point 4 addresses information about fixed vulnerabilities once a security update is available. Point 5 requires a coordinated vulnerability disclosure policy, while point 6 concerns measures that facilitate the sharing of information about potential vulnerabilities. These requirements need different controls even though they support the same vulnerability-handling programme. A security-testing schedule does not replace a disclosure policy, and a disclosure mailbox does not replace the process for publishing useful remediation information after a fix becomes available.
- Part II point 3: regular security tests and reviews.
- Part II point 4: information about fixed vulnerabilities.
- Part II point 5: coordinated vulnerability disclosure policy.
- Part II point 6: measures facilitating vulnerability-information sharing.
- Map separate controls, owners and evidence for each.
Map Secure Update Distribution and Dissemination
Part II points 7 and 8 complete the operational update chain. Point 7 addresses secure distribution mechanisms so vulnerabilities can be fixed or mitigated in a timely manner. Point 8 addresses dissemination of security updates without delay and associated user information, subject to the Regulation's specific qualifications. A control matrix can map these requirements to update signing, package verification, key management, distribution infrastructure, release monitoring, security advisories and support procedures. This makes it possible to distinguish developing a correct patch from securely delivering that patch to affected users.
- Part II point 7: secure update distribution.
- Part II point 8: dissemination without delay.
- Map update-signing and verification controls.
- Map release and distribution operations.
- Map user security advisories and required actions.
Assign One Accountable Owner Even When Several Teams Contribute
Many CRA requirements span several teams. Authentication can involve architecture, application engineering and identity specialists. Security updates can involve vulnerability management, engineering, release operations and support. The control matrix should still identify an accountable control owner who can explain whether the control exists, whether it is operating as intended and where the evidence is located. Contributors can be listed separately. Clear ownership reduces the risk that each team assumes another team is maintaining the CRA evidence or reviewing the requirement after a product change.
- Assign an accountable control owner.
- Identify contributing teams.
- Define responsibility for verification.
- Define responsibility for evidence maintenance.
- Define escalation when the control is ineffective.
Link Every Important Control to a Verification Method
A control description does not demonstrate that the control works. Each important CRA control should have an appropriate verification method. Depending on the control, verification can involve architecture review, source review, automated tests, configuration inspection, vulnerability scanning, penetration testing, fuzzing, build verification, update testing, deletion testing, resilience testing or process-record review. The matrix should identify the expected result and evidence location. Verification frequency can also be recorded where controls need recurring review during the support period.
- Define how the control will be verified.
- Define the expected result.
- Identify the test environment or product version.
- Link the resulting evidence.
- Define recurring verification where necessary.
Use the Matrix to Assemble Article 31 and Annex VII Evidence
Article 31 requires technical documentation containing relevant data or details about the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with the essential cybersecurity requirements. Annex VII sets out minimum technical-documentation content, including product description, design and development information, vulnerability handling processes, the cybersecurity risk assessment, standards or specifications applied and reports of tests carried out to verify conformity. A well-maintained control matrix can act as an index into this evidence. It does not replace the technical documentation, but it can show where each Annex I requirement is addressed and where supporting evidence can be found.
- Link requirements to architecture evidence.
- Link requirements to cybersecurity risk decisions.
- Link controls to test reports.
- Link vulnerability-handling requirements to process evidence.
- Link applicable standards or specifications.
- Use the matrix as an evidence index, not as a substitute for Annex VII.
Do Not Treat One Control as Automatic Proof of Several Requirements
One technical control can legitimately support several CRA requirements. Authentication can support protection from unauthorised access and contribute to confidentiality. Signed updates can support integrity, vulnerability remediation and secure update distribution. Logging can contribute to access reporting and security monitoring. Shared controls should be mapped to each relevant requirement, but the evidence should still demonstrate the specific security outcome required by each row. A control should not be copied across the matrix as automatic proof merely because its name sounds relevant.
- Allow legitimate many-to-many mappings.
- Explain the security outcome for each mapping.
- Use requirement-specific verification where needed.
- Avoid duplicate claims unsupported by evidence.
- Identify gaps hidden by broad control labels.
Record Applicability Decisions and Residual Risk
Several Annex I requirements apply on the basis of the cybersecurity risk assessment and where applicable. The matrix can therefore record applicability decisions together with the technical reasoning supporting them. A blank row is weaker than a documented conclusion explaining why a requirement does not apply to the product or why a particular implementation approach was selected. Where a control reduces but does not eliminate a risk, the residual risk should also be visible and linked to the cybersecurity risk assessment. This makes the matrix an engineering record rather than a simple yes-or-no checklist.
- Record applicability explicitly.
- Document the technical rationale.
- Record residual cybersecurity risk.
- Link exceptions to the risk assessment.
- Review conclusions when the product changes.
Version the Matrix With the Product
CRA evidence should remain connected to the product version it describes. New features can add interfaces, data flows, dependencies, privileges and vulnerability-handling requirements. A control matrix that remains unchanged while the product evolves can become misleading. Manufacturers should version the matrix or otherwise maintain traceable change history, identify which product release each control applies to and update mappings when architecture, configuration, support processes or security assumptions change. The matrix can also record which evidence supersedes older test results after substantial design changes.
- Associate the matrix with product versions.
- Track requirement-mapping changes.
- Review mappings after architecture changes.
- Review mappings after new interfaces or dependencies.
- Retire superseded evidence deliberately.
Use the Matrix Before Conformity Assessment, Not Only at the End
Article 32 requires conformity assessment to determine whether the essential cybersecurity requirements are met. Building the requirement-to-control matrix only immediately before conformity assessment can expose unresolved gaps too late. Teams can use the matrix during architecture and development reviews so missing controls, tests and evidence become visible while there is still time to address them. By release readiness, each applicable Annex I row should have a clear implementation status, verification result and evidence reference. This provides a stronger basis for technical documentation and the applicable conformity-assessment procedure.
- Create the matrix during product planning.
- Review it during architecture and development.
- Use it at security release gates.
- Resolve missing evidence before conformity assessment.
- Keep it current during the support period.
A Practical CRA Control-Mapping Workflow
A repeatable workflow can keep the exercise manageable. First define the product boundary, intended purpose and relevant versions. Then complete the Article 13 cybersecurity risk assessment. Next create Annex I Part I and Part II requirement rows. Map product-specific risks and existing controls to each row, identify gaps, assign owners and define verification. Run the required tests or process reviews, attach evidence and record residual risk. Review the complete matrix against the technical documentation before conformity assessment. After placing the product on the market, maintain the rows affected by vulnerabilities, updates, product changes and support-period activities.
- 1. Define the product and version boundary.
- 2. Complete the cybersecurity risk assessment.
- 3. Create Annex I requirement rows.
- 4. Map risks and controls.
- 5. Identify control gaps.
- 6. Assign accountable owners.
- 7. Define and perform verification.
- 8. Link technical evidence.
- 9. Review conformity readiness.
- 10. Maintain the mapping through the support period.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.