SecPoint CRA Readiness Checklist
A practical checklist for vendors, importers, distributors, integrators, and buyers preparing for the EU Cyber Resilience Act.
This checklist is not legal advice. It is a practical tool for organizing CRA readiness work and collecting evidence across product classification, secure development, SBOM, vulnerability handling, support, technical documentation, conformity assessment, and CE marking.
Practical rule: CRA readiness is not about proving that a product is perfect. It is about proving that the vendor can identify risk, reduce risk, handle vulnerabilities, update the product, communicate clearly, and document the process.
CRA Readiness Checklist
| Done | Checklist Area | Question To Answer | Evidence To Prepare |
|---|---|---|---|
| Product scope | Have all digital elements been identified, including firmware, apps, APIs, remote processing, update systems, and components? | Product scope map | |
| Product classification | Is the product standard, important Class I, important Class II, or critical under CRA? | Classification memo | |
| Economic operator role | Are you manufacturer, importer, distributor, authorised representative, open-source steward, or buyer? | Role and responsibility assessment | |
| Risk assessment | Have product function, exposure, threat level, user impact, and consequences been assessed? | Cybersecurity risk assessment | |
| Secure-by-design | Are security requirements built into architecture, access control, configuration, logging, update design, and data protection? | Security design review | |
| Secure development | Do you use SSDLC, code review, dependency control, security testing, release gates, and build integrity controls? | SSDLC process evidence | |
| SBOM and component control | Do you know which components, versions, suppliers, identifiers, and dependencies are inside each release? | SBOM or software component list | |
| Open-source due diligence | Do you track open-source components, licenses, maintainers, known vulnerabilities, update status, and end-of-life risk? | Third-party component review | |
| Vulnerability intake | Can customers, researchers, partners, and internal teams report vulnerabilities through a controlled channel? | Security contact, disclosure policy, intake log | |
| Vulnerability handling | Do you validate, score, prioritise, mitigate, patch, test, disclose, and learn from vulnerabilities? | PSIRT or equivalent process | |
| Reporting readiness | Can you identify actively exploited vulnerabilities and severe incidents and meet CRA reporting timelines? | Reporting procedure and escalation path | |
| Secure updates | Can users receive and install security updates securely, preferably separated from feature updates where practical? | Update mechanism and patch policy | |
| Support period | Is the support period defined, justified, communicated, and backed by engineering capacity? | Support policy and end-date statement | |
| Technical documentation | Can you show design, risk assessment, standards, tests, component list, support basis, and conformity evidence? | Technical documentation file | |
| Conformity route | Do you know whether self-assessment, harmonised standards, common specifications, certification, or notified body assessment is needed? | Conformity assessment plan | |
| CE marking evidence | Can you draw up the EU Declaration of Conformity and support CE marking with evidence? | Declaration of Conformity and CE file | |
| Supplier contracts | Do supplier, OEM, white-label, and distributor agreements support security updates, vulnerability notification, and evidence sharing? | Contract and supplier review | |
| Operational ownership | Will the process continue when key employees change role, leave, or when the product is updated? | RACI matrix, backup owners, and governance review |
Common Pitfalls
| Pitfall | Result | Better Practice |
|---|---|---|
| Underestimating support period | Patching and update obligations become impossible to sustain | Define support policy before market placement |
| Poor open-source control | Unknown vulnerable components remain inside the product | Use SBOM, SCA, supplier review, and vulnerability feeds |
| Only scanning, no process | Findings exist but no one owns remediation or reporting | Connect scanning to PSIRT and engineering workflows |
| No organisational anchoring | CRA readiness depends on individuals instead of a repeatable process | Create product security ownership, RACI, and management review |