CRA readiness checklist for software teams

1. Establish the product and regulatory scope

Start with the exact product placed on the EU market, its versions, remote data processing functions, intended purpose, foreseeable use, and the legal entity placing it on the market. The CRA primarily addresses manufacturers, but importers, distributors, and open-source software stewards have distinct duties.

Document classification assumptions and exclusions - classification follows core functionality, and the reasoning belongs in the file. Do not infer conformity-assessment class solely from a vulnerability scan or repository technology.

2. Build the risk assessment into engineering

The manufacturer’s cybersecurity risk assessment should inform planning, design, development, production, delivery, and maintenance - the dedicated risk-assessment guide breaks the expectation down. Keep threat models, architecture boundaries, security requirements, test results, and accepted-risk decisions connected to product versions.

• Named product and version scope
• Assets, trust boundaries, threats, and reasonably foreseeable use
• Essential-requirement mapping
• Residual risk and approval record

3. Make the supply chain explainable

Identify direct and transitive components, capture exact release versions, and preserve a machine-readable SBOM. Pair component data with due-diligence evidence: update monitoring, known-vulnerability review, exploitability decisions, and corrective releases.

4. Operationalise vulnerability handling and reporting

A SECURITY.md file is useful evidence, but it is not the whole process. Define intake, triage, remediation, coordinated disclosure, customer communication, support-period ownership, and CRA reporting escalation - vulnerability handling covers the working loop.

From 11 September 2026, reporting obligations apply for actively exploited vulnerabilities and severe incidents. The Commission describes an early warning within 24 hours, a main notification within 72 hours, and later final reports through the Single Reporting Platform; the full Article 14 timeline explains every stage.

5. Assemble and maintain the technical evidence

Create an evidence index that links each claim to a controlled artifact. Retain snapshots per release and record why changes alter-or do not alter-the risk assessment. Structure helps: Annex VII sets out the sections reviewers expect. A continuously maintained evidence package is more defensible than a last-minute document exercise.