CRA readiness checklist for software and connected-product manufacturers
Cyber Resilience Act readiness is operational: a product inventory with owners, an SBOM per version, continuous vulnerability matching with exploitation signals, a rehearsed Article 14 workflow with awareness discipline, a coordinated disclosure policy, a defined support period per product and technical documentation you can hand over. This checklist lists each item with the evidence that proves it.
By the Vellaci teamPublished Updated 5 min readOperational guidance, not legal advice
Key facts
- Since 11 Sep 2026
- Article 14 reporting applies; maintain an active awareness, response and evidence workflow
- By 11 Dec 2027
- Full conformity: classification, risk assessment, Annex VII documentation, conformity route, CE marking
- Continuous
- SBOM per release, vulnerability handling, security updates, disclosure
Local checklist
Track your team's next steps
Mark items as you review them. Your selections stay in this browser and are not sent to Vellaci; status means progress, not legal compliance.
Loading saved progress…
Governance
| Item | Why | Evidence to keep |
|---|---|---|
| Product inventory with owners and lifecycle states | Every obligation attaches to a product; unknown products are unmanaged risk | Registry export with owner, security owner, state, versions |
| Preliminary CRA scope assessment per product | Determines whether and how the regulation applies | Assessment record with reasoning and date |
| Classification with reasoning and approver | Sets the conformity route | Classification record, Annex reference, approver |
| Named roles: product owner, security owner, assigned representative, compliance lead | Article 14 runs on people who can act within hours | Runbook, org chart, deputies |
SBOM and vulnerability handling
| Item | Why | Evidence to keep |
|---|---|---|
| SBOM per supported version, generated in the release pipeline | Annex I Part II(1); the base for triage | SBOM files with checksums bound to versions |
| Continuous matching against OSV/advisories, KEV and EPSS | Exploitation evidence arrives after release | Matching job logs, findings with intelligence provenance |
| Triage with mandatory reasons and remediation ownership | Annex I Part II(2): remediate without delay | Decision history per finding |
| Fixed releases linked to findings; VEX for non-affected | Evidence of remediation and of due diligence | Release notes, VEX documents |
| Regular security testing | Annex I Part II(3) | Test reports with scope and date |
Disclosure and updates
| Item | Why | Evidence to keep |
|---|---|---|
| Published CVD policy and security.txt on every product domain | Annex I Part II(5)–(6) | Policy versions, security.txt with expiry |
| Intake process with acknowledgement and handling SLAs | A policy needs a working mailbox | Intake log, response times |
| Security advisories for fixed vulnerabilities | Annex I Part II(4) | Advisory archive |
| Secure, free update mechanism per product | Annex I Part I and Part II(7)–(8) | Update mechanism description, signing procedures |
Incidents and reporting
| Item | Why | Evidence to keep |
|---|---|---|
| Awareness rule defined and trained | Every Article 14 deadline runs from it | Written rule, training record |
| Assigned representative and deputy with ENISA platform access | Weekend early warnings happen | Access confirmation, deputy roster |
| Incident and vulnerability reportability review with rationale | Human decision on record | Review records including not-reportable decisions |
| Server-computed deadlines and alert thresholds | Calendars do not survive incidents | Case records with deadline history |
| Rehearsed 24 h / 72 h workflow with submission evidence | A drill finds the missing password before the regulator does | Drill reports |
| User communication template | Art. 14(8) | Template and sent examples |
Support and documentation
| Item | Why | Evidence to keep |
|---|---|---|
| Support period defined, justified and published per product | Art. 13(8); Annex II | Support period record with rationale; product page |
| Cybersecurity risk assessment per product | Art. 13(2)–(3) | Assessment mapped to Annex I Part I |
| Technical documentation assembled per Annex VII | Art. 31 | Sectioned documentation with evidence links |
| Retention of documentation and updates for ten years | Art. 13(9), 13(13) | Retention policy, archive |
| Conformity route chosen; notified body engaged where needed | Art. 32; capacity is scarce | Procedure decision, body correspondence |
How to use this checklist
Assign an owner and an evidence location to each item, then review progress at a cadence that fits your release and support cycles. Two rules keep the checklist useful. First, an item is established only when the evidence exists and can be retrieved; a policy nobody can find still needs work. Second, the 'why' column paraphrases the regulation for operational planning; where an item does not apply to a specific product, preserve the product-specific reasoning and have the conclusion reviewed. The interactive list at the top saves only review ticks in this browser; it is not a compliance score or a shared company record.
Sequence
- Now: inventory, scope, owners, SBOM pipeline, vulnerability matching, CVD policy and security.txt.
- Now (Article 14 reporting has applied since 11 September 2026): maintain the awareness rule, assigned representative, reporting runbook, rehearsals and submission evidence.
- 2026–2027: classification, risk assessment, support periods, Annex VII documentation, conformity route and notified body.
- By 11 December 2027: apply the full requirements to products placed on the market from that date, and to earlier products where the regulation's substantial-modification rule applies; complete the relevant conformity route and documentation.
- Continuously: SBOM per release, triage, updates, advisories, documentation reviews, quarterly drills.
Frequently asked questions
- Where should a small team start?
- With the SBOM pipeline and the Article 14 reporting runbook. The SBOM makes component exposure measurable; the runbook supports obligations that have applied since 11 September 2026. Vellaci's free assessment ranks operational gaps in about eight minutes.
- How do we prove readiness to a customer or an auditor?
- With records, not statements: the registry export, SBOMs with checksums, decision histories, drill reports, the CVD policy and support periods. A readiness score is a management view; the evidence behind each item is what convinces.
- We have dozens of products. Where is the leverage?
- In the shared processes: one SBOM pipeline pattern applied to every build, one triage workflow, one runbook, one documentation template. Product-specific work — classification, support period, risk assessment — then becomes filling in a structure rather than inventing one. Start with the products on the EU market with the longest expected use; they carry the most obligation-years.
- What if our reporting workflow was not ready on 11 September 2026?
- Article 14 applies from that date. Put a workable process in place promptly: define how awareness is confirmed and recorded, assign an accountable representative and deputy, maintain access to the official reporting platform, rehearse the deadline workflow and preserve evidence of decisions and submissions. Get qualified advice on event-specific reportability questions.