Use the checklist as an evidence index. Every completed item should point to a decision, document, system record, test or responsible owner. Items that are not applicable should contain reasoning. High-risk unresolved issues such as uncertain scope, uncertain classification, missing risk assessment or missing vulnerability processes should be escalated rather than hidden inside an overall completion percentage.
1. Establish Product Ownership and CRA Governance
Start by assigning responsibility for CRA implementation at both programme and product level. Product security, engineering, legal, compliance, quality and support teams can each own different evidence, but one controlled record should show who is responsible for the product's CRA decisions and open actions. Readiness work becomes unreliable when obligations sit between teams with no accountable owner.
- Assign a CRA programme owner.
- Assign a product owner for each product family.
- Assign owners for risk, vulnerability, documentation and conformity work.
- Create an escalation route for unresolved legal or technical decisions.
2. Build and Control the Product Inventory
List the software and hardware products the manufacturer makes available on the Union market, including separately supplied components where relevant. Record product families, versions, intended purpose, remote data processing, market status and support status. The inventory should be controlled enough that a product cannot disappear from the compliance programme merely because a business unit uses a different product name or versioning scheme.
- List products and product families.
- List relevant separately supplied components.
- Record versions or models.
- Record intended purpose.
- Record remote data processing relationships.
- Record market and support status.
3. Record the CRA Scope Decision for Each Product
For each inventory item, record whether it is a product with digital elements within CRA scope, whether an exclusion or special rule may apply and what facts support the conclusion. Keep the reasoning rather than only a yes or no field. Scope decisions can change when product functionality, distribution model, remote processing or sector-specific legislation changes.
- Record in-scope or out-of-scope conclusion.
- Record the legal and factual reasoning.
- Identify relevant exclusions or sector-specific rules.
- Review scope after material product changes.
4. Complete Product Classification
Determine whether the product remains in the default category or falls within an important class I, important class II or critical product category. Classification matters because it can change the available Article 32 conformity route. Record the product functionality and legal category used for the decision rather than relying only on the selected label.
- Record the product category.
- Record the category basis.
- Identify important or critical product descriptions where relevant.
- Connect classification to conformity planning.
5. Complete the Article 13 Cybersecurity Risk Assessment
Article 13 requires a cybersecurity risk assessment associated with the product and requires its outcome to influence planning, design, development, production, delivery and maintenance. Confirm that the assessment reflects intended purpose, reasonably foreseeable use, assets, threats, attack scenarios, product architecture, remote processing and relevant third-party dependencies. It should produce traceable risk-treatment decisions rather than only a generic risk score.
- Identify product assets and security objectives.
- Identify threats and attack scenarios.
- Assess risks.
- Record treatment decisions.
- Connect controls to identified risks.
- Define triggers for reassessment.
6. Map Annex I Part I Product Requirements
Review Annex I Part I against the product and risk assessment. For each applicable requirement, identify the design or technical controls and the evidence supporting them. Where a requirement is considered not applicable, preserve the justification because Article 13 requires a clear explanation in the technical documentation for essential cybersecurity requirements considered not applicable.
- Map applicable product-security requirements.
- Link design controls.
- Link test evidence.
- Record not-applicable justifications.
- Track unresolved evidence gaps.
7. Review Third-Party Components and SBOM Readiness
Confirm that third-party components have been identified and that due diligence is integrated into product-security work. Check whether the SBOM can represent the relevant software components and dependencies and whether it can be maintained as versions change. The SBOM should support vulnerability handling and technical documentation rather than exist as a one-time export.
- Identify third-party components.
- Record component versions.
- Record supplier or maintainer information.
- Maintain SBOM data.
- Connect component vulnerabilities to affected products.
8. Establish Annex I Part II Vulnerability Handling
Confirm that the manufacturer can identify, document, prioritise, remediate and disclose vulnerabilities throughout the support period. The process should cover internally discovered vulnerabilities, external reports and relevant third-party component information. It should also include secure update distribution and the testing needed to confirm remediation.
- Maintain vulnerability intake channels.
- Triage and prioritise product vulnerabilities.
- Remediate in relation to product risk.
- Maintain coordinated vulnerability disclosure processes.
- Distribute security updates securely.
- Retain remediation evidence.
9. Prepare Article 14 Reporting Readiness
The Article 14 reporting obligations apply from 11 September 2026. Confirm that security and incident-response teams can recognise a potential actively exploited vulnerability or severe incident affecting product security, establish when the manufacturer became aware, gather the required information and escalate quickly enough for the applicable reporting stages. The readiness workflow should distinguish reportability assessment from ordinary incident handling.
- Define Article 14 escalation criteria.
- Record awareness time.
- Identify affected products and versions.
- Maintain reporting contacts and access.
- Preserve the reporting decision record.
10. Assemble Article 31 and Annex VII Technical Documentation
Confirm that the technical documentation describes the product, intended purpose, relevant software versions, architecture, design and development information, cybersecurity risk assessment, vulnerability-handling processes, SBOM, relevant standards or specifications and test reports as applicable. The documentation should be built from controlled evidence and updated where appropriate rather than assembled once and abandoned.
- General product description.
- Relevant versions.
- Architecture and design evidence.
- Cybersecurity risk assessment.
- Vulnerability-handling evidence.
- SBOM.
- Standards or specifications.
- Test reports.
11. Select the Article 32 Conformity Assessment Route
Determine which conformity assessment procedure is available for the product based on classification and the Article 32 conditions. Record whether the product can use Module A internal control or requires Module B followed by C, Module H or an applicable certification route. Where third-party assessment is required, include notified-body planning in the readiness programme.
- Record the selected conformity route.
- Record why it is available.
- Identify notified-body involvement where required.
- Track assessment evidence and findings.
12. Prepare User Information and Support-Period Evidence
Check the information and instructions required for the product and document the support-period decision. The manufacturer should be able to explain the support period, disclose the relevant end date and maintain the vulnerability-handling capability expected during that period. User-facing security information should remain consistent with the technical and support model actually delivered.
- Record support-period reasoning.
- Record and disclose the support end date.
- Prepare required user instructions.
- Align support operations with the disclosed period.
13. Review Continued Conformity and Change Management
Readiness does not end at market placement. Confirm that product changes, development-process changes, supplier changes, architecture changes, vulnerabilities and new security information can trigger review of the risk assessment and conformity evidence. A product that was ready at launch can become poorly documented later if the operational change process is disconnected from CRA evidence.
- Define change-review triggers.
- Update risk assessment where applicable.
- Update technical documentation where appropriate.
- Maintain conformity evidence for supported products.
14. Treat Open High-Risk Decisions as Blockers
Some gaps should not be hidden inside a high overall readiness percentage. Unresolved product scope, uncertain important or critical classification, missing cybersecurity risk assessment, missing vulnerability handling or an undecided conformity route can undermine the rest of the programme. Flag these issues as explicit blockers with owners and target resolution dates.
- Unresolved scope.
- Unresolved classification.
- Missing risk assessment.
- Missing vulnerability process.
- Missing technical documentation.
- Unresolved conformity route.
15. Close the Checklist With Evidence, Not a Percentage
A useful completion review asks whether the manufacturer can show the evidence behind each important decision and requirement. A readiness percentage can help programme management, but the closing record should identify product-specific evidence, open findings, accepted residual risks, review approvals and the next review trigger. That creates a defensible readiness record without misrepresenting the checklist as the conformity assessment itself.
- Attach evidence to completed items.
- Record open findings.
- Record review and approval.
- Record next review trigger.
- Keep the legal conformity conclusion separate.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.