A useful CRA readiness system turns the Regulation into linked records rather than isolated spreadsheets. Start with the product inventory and scope decision, connect each product to classification and risk assessment, map applicable Annex I requirements, collect evidence, track vulnerabilities and reporting readiness, assemble technical documentation and record the applicable conformity route. Future CRA software should preserve those relationships and the evidence behind them instead of reducing compliance to a single score.
CRA Readiness Tools Should Follow the Compliance Lifecycle
A CRA readiness programme works best when its tools follow the same lifecycle as the product. The manufacturer first needs to know which products exist, whether the CRA applies, how each product is classified and what cybersecurity risks it presents. The programme then needs evidence for Annex I requirements, vulnerability handling, reporting readiness, technical documentation, conformity assessment and continued support. Tools should connect these stages instead of treating each obligation as an isolated task.
- Inventory products with digital elements.
- Record CRA scope decisions.
- Classify products where applicable.
- Complete the cybersecurity risk assessment.
- Map Annex I requirements and evidence.
- Prepare vulnerability and reporting processes.
- Assemble technical documentation.
- Select and document the conformity route.
- Maintain evidence through the support period.
A Readiness Checklist Is a Starting Point, Not Proof of Compliance
A checklist is useful for identifying work that has not started, evidence that is missing and decisions that still need an owner. It cannot determine conformity simply because every box has been checked. CRA obligations are product-specific and risk-based. A manufacturer may need to explain why a requirement applies, why it does not apply or why a particular control is appropriate for the product's risk profile. The evidence behind the checklist matters more than the completion percentage.
- Use checklists to organise work.
- Attach evidence to completed items.
- Record not-applicable reasoning.
- Do not convert checklist completion into an automatic legal conclusion.
The Product Inventory Is the Foundation of a CRA Toolset
A manufacturer cannot manage CRA readiness reliably if it does not have a controlled list of the products and software variants it places on the Union market. The inventory should distinguish product families, versions, intended purpose, market status, remote data processing, relevant components and product owners. It should also preserve the reasoning behind scope decisions so that a product is not silently omitted from later risk, documentation or conformity workflows.
- Product and product-family name.
- Version or model information.
- Intended purpose.
- CRA scope status and reasoning.
- Remote data processing relationships.
- Product owner and evidence owner.
- Market and support status.
Classification Should Be a Recorded Decision, Not a Dropdown Guess
A classification tool can guide teams through default-category, important class I, important class II and critical product analysis, but the output should retain the reasoning and evidence used. Product categories can affect the conformity route, so a software interface should not hide uncertainty behind a simple dropdown. Where the category depends on core functionality or a Commission technical description, the record should capture the facts supporting the classification.
- Record the selected category.
- Record the product functionality used for classification.
- Record the legal or technical category reference.
- Flag uncertain classifications for review.
- Connect classification to conformity-route selection.
The Cybersecurity Risk Assessment Should Drive the Rest of the Readiness Record
Article 13 requires the manufacturer to undertake a cybersecurity risk assessment and take its outcome into account across planning, design, development, production, delivery and maintenance. A useful CRA tool should therefore treat the risk assessment as a central record. Requirements, controls, tests, residual risks, support assumptions and technical-documentation evidence should be traceable back to the risks and product characteristics that justify them.
- Identify assets and product functions.
- Identify threats and attack scenarios.
- Assess cybersecurity risks.
- Record treatment decisions.
- Map controls and evidence.
- Update the assessment when relevant facts change.
Annex I Mapping Should Connect Requirements to Evidence
Annex I contains product cybersecurity requirements in Part I and vulnerability-handling requirements in Part II. A readiness system should map each applicable requirement to the product design, process, test, policy or other evidence used to support it. Where a requirement is not applicable, Article 13 requires the manufacturer to justify that conclusion in the technical documentation. A readiness tool should preserve that justification rather than offering a generic not-applicable checkbox with no explanation.
- Map each applicable Annex I requirement.
- Link technical and process evidence.
- Record responsible teams.
- Record not-applicable justifications.
- Track open evidence gaps.
SBOM Readiness Is One Part of Vulnerability Readiness
The software bill of materials supports vulnerability handling and technical documentation, but an SBOM alone is not a CRA compliance programme. A useful readiness workflow should track whether relevant components are represented, whether component information can be maintained as versions change and whether vulnerability intelligence can be connected to the components actually integrated into the product. The SBOM should feed vulnerability triage rather than exist as a static export created only for assessment day.
- Track product components.
- Maintain component versions.
- Connect vulnerability intelligence.
- Update the SBOM as the product changes.
- Keep SBOM evidence connected to vulnerability handling.
Vulnerability Management Tools Need Product Context
Generic vulnerability tools can identify findings, but CRA readiness requires product context. Teams need to know which supported products are affected, whether the vulnerable item is part of the product, what remediation is planned, whether a third-party component maintainer needs to be informed, how the risk assessment changes and whether an Article 14 reporting trigger needs evaluation. A CRA workflow should therefore connect vulnerability records to products, components and support periods.
- Connect findings to affected products.
- Record vulnerability status and remediation.
- Track third-party component communication where applicable.
- Track support-period status.
- Escalate potential Article 14 triggers for assessment.
Incident Reporting Tools Should Support Decisions, Not Automate Legal Conclusions
Article 14 reporting requires facts about an actively exploited vulnerability or a severe incident having an impact on product security. A tool can collect timestamps, affected products, evidence, exploitation information, incident impact and reporting status, but it should not assume every security event is reportable. The workflow should preserve the decision record and the information needed for the applicable reporting stages.
- Capture the time the manufacturer became aware.
- Identify affected products and versions.
- Capture exploitation or incident evidence.
- Record the reporting assessment.
- Track required reporting stages where the trigger is met.
Technical Documentation Tools Should Build an Evidence Graph
Article 31 and Annex VII require technical documentation that explains the product, its architecture, cybersecurity risk assessment, vulnerability-handling processes, relevant standards or specifications and test evidence. A useful tool should not treat the technical file as one final document assembled manually at the end. It should connect architecture, versions, risks, controls, SBOM data, tests and processes so that the technical documentation can be generated or reviewed from controlled evidence.
- Connect product description and intended purpose.
- Connect architecture and software versions.
- Connect the cybersecurity risk assessment.
- Connect vulnerability-handling evidence.
- Connect SBOM and component information.
- Connect test reports and conformity evidence.
Conformity Assessment Readiness Depends on Product Classification
The applicable Article 32 conformity procedure depends on the product and its classification. A readiness tool should therefore connect classification to the selected conformity route and flag the evidence needed for that route. It should not imply that one checklist supports every product equally. Module A, Module B followed by C, Module H and qualifying certification routes involve different assessment structures and can require different external parties.
- Record the conformity route.
- Record why the route is available.
- Identify notified-body involvement where required.
- Track technical-documentation readiness.
- Track unresolved conformity findings.
Supplier Questionnaires Should Feed the Product Risk Record
Article 13 requires due diligence when manufacturers integrate third-party components. Supplier questionnaires can help gather development, vulnerability, update, contact and component information, but their value depends on how the answers are used. A readiness system should link supplier evidence to the components and product risks it supports instead of storing questionnaires as disconnected procurement attachments.
- Identify the supplied component.
- Capture security and vulnerability processes.
- Capture update and support information.
- Record security contacts.
- Connect supplier answers to product risk and component evidence.
Support Period Tracking Should Begin Before Market Placement
The CRA requires manufacturers to determine and disclose a support period and to handle vulnerabilities throughout it. A tracker should therefore record the product-specific support decision, its reasoning, the public end date, supported versions and the teams responsible for vulnerability handling. Support should not be treated as a date field added after release because it affects maintenance planning, update availability and user information.
- Record the support-period reasoning.
- Record the disclosed end date.
- Map supported product versions.
- Track vulnerability-handling coverage.
- Track changes affecting the support decision.
CRA Compliance Software Should Preserve Evidence and Decisions
The strongest future CRA software opportunity is not a generic compliance score. It is a system that connects products, classifications, risks, requirements, evidence, vulnerabilities, suppliers, support periods and conformity decisions. Each status should be explainable. A reviewer should be able to move from a dashboard indicator to the product facts and evidence supporting that indicator rather than receiving a black-box result.
- Product-level records.
- Decision history.
- Requirement-to-evidence traceability.
- Role and ownership tracking.
- Version-aware evidence.
- Review and approval workflows.
- Exportable technical-documentation evidence.
A Dashboard Should Show Readiness, Evidence Quality and Open Decisions Separately
A single percentage can hide important differences. One product may have most documents uploaded but an unresolved classification decision. Another may have strong technical evidence but weak reporting readiness. A CRA dashboard should therefore distinguish workflow completion, evidence sufficiency, unresolved decisions, overdue remediation and upcoming support milestones. These indicators can help teams manage readiness without pretending the dashboard itself is the conformity assessment.
- Readiness status.
- Evidence status.
- Open legal or technical decisions.
- Vulnerability and remediation status.
- Reporting readiness.
- Support-period milestones.
- Conformity-assessment status.
Build the Readiness System Around Reviewable Records
Whether the manufacturer starts with spreadsheets, document templates or dedicated software, the underlying model should remain the same. Each product should have a controlled record of scope, classification, risk, requirements, evidence, components, vulnerabilities, documentation, conformity route and support status. This makes migration to dedicated CRA software easier later because the organisation has already structured the decisions and evidence the software needs to manage.
- Use stable product identifiers.
- Assign owners.
- Record decisions and evidence together.
- Keep version history.
- Review open gaps regularly.
- Preserve exportable evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.