A good CRA crosswalk is evidence-oriented. It answers what the CRA requires, which existing process or technical control addresses it, what proof exists for the actual product and what remains missing. This lets companies reuse mature security programmes without turning broad framework alignment into an unsupported claim of product conformity.
Start With the CRA Requirement, Not the Existing Standard
The CRA is the controlling framework for CRA conformity, so the crosswalk should start with the relevant Article or Annex I requirement. Starting with the existing standard can encourage teams to declare familiar controls sufficient even when the CRA asks a different product-specific question. Requirement-first mapping keeps the analysis anchored to the legal obligation.
- CRA article or Annex requirement.
- Requirement interpretation.
- Relevant product scope.
- Then identify supporting standards.
Inventory Standards by Purpose and Scope
List the standards, frameworks and certifications already used by the organisation and classify what each one actually covers. ISO 27001 may provide organisation-level management evidence, IEC 62443 may provide industrial product-development and technical controls and ISO 29147 or ISO 30111 may provide vulnerability-process evidence. Scope matters because evidence from one layer cannot automatically prove another.
- Standard and version.
- Purpose.
- Product or organisational scope.
- Certification status where relevant.
- Internal owner.
Map Clauses or Controls to Individual CRA Requirements
For each CRA requirement, identify the exact clause, control or process that contributes. Avoid a broad one-to-one statement such as ISO 27001 covers Annex I. A single CRA requirement may need evidence from several standards and product records, while one standard control may support several CRA requirements. The crosswalk should show these many-to-many relationships explicitly.
- CRA requirement ID.
- Standard clause or control.
- Coverage explanation.
- Product evidence reference.
- Reviewer.
Rate Coverage as Full, Partial or Gap
A practical crosswalk should distinguish full support, partial support and no meaningful support. Partial coverage is especially important because standards often address the same security concept with different scope, lifecycle or evidence expectations. The gap should state exactly what additional CRA-specific evidence or process is needed rather than simply marking the requirement red.
- Full support.
- Partial support.
- Gap.
- Additional action.
- Owner and target date.
Map Evidence, Not Just Policy Language
A standards clause can show what a process should do, but CRA technical documentation needs evidence that the relevant product actually meets the applicable requirement. Link the crosswalk to architecture, threat models, test results, SBOM records, update evidence, vulnerability cases and user information as appropriate. This turns the standards mapping into usable conformity evidence.
- Architecture.
- Risk assessment.
- Security requirements.
- Test results.
- Vulnerability records.
- Release and update evidence.
Track Legal Status Separately From Technical Coverage
A standard can have strong technical coverage without Article 27 harmonised status. The crosswalk should include a separate legal-status field stating whether the standard is an Official Journal cited harmonised standard for the relevant CRA requirements, a common specification, another technical standard or an internal framework. This prevents technical usefulness from being mistaken for legal presumption of conformity.
- Harmonised status.
- Official Journal reference.
- Common specification status.
- Voluntary technical standard.
- Internal framework.
Feed the Crosswalk Into Annex VII Technical Documentation
Annex VII requires the technical documentation to identify harmonised standards, common specifications and relevant certification schemes applied and to describe other solutions used where those routes are not applied. A well-maintained crosswalk can support that section by showing standards used, covered requirements and the product-specific evidence or alternative solutions relied on.
- Standards applied.
- Requirements covered.
- Alternative solutions.
- Product evidence.
- Version and change history.
Maintain the Mapping as Standards and Products Change
A crosswalk is not a one-time spreadsheet. New standard editions, Official Journal references, product architecture changes and CRA secondary legislation can all change the relationship. Assign review triggers and ownership so changes create an impact assessment rather than leaving the original mapping frozen after the first conformity project.
- Standard revision.
- CRA harmonisation change.
- Product change.
- New delegated or implementing act.
- Periodic review.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.