CRA compliance checklist: 12 steps

CRA implementation falls into two phases: by 11 September 2026 you need reporting readiness – product inventory, contact point and a 24h/72h runbook. By 11 December 2027 you build the evidence: risk assessment, SBOM, secure defaults, update process, technical documentation and declaration of conformity.

The 12 steps below are sorted by urgency. They do not replace a legal review of your case but give you a sound order of work.

Phase 1: by 11 September 2026

1. Product inventory: all products with digital elements you make available in the EU – including versions still running at customers. Reporting also covers legacy products.
2. Clarify roles: record who the manufacturer is for each product. Agencies will find scenarios in CRA for agencies.
3. Set up a contact point: publish a fixed address for vulnerability reports (e.g. security.txt) and a coordinated vulnerability disclosure policy.
4. Runbook and on-call: who detects, who assesses, who reports within 24h and 72h? Define deputies and templates – details in CRA reporting.

Phase 2: by 11 December 2027

1. Determine the product category: default, important (class I/II) or critical – see CRA product categories. Approach a notified body early if needed.
2. Cybersecurity risk assessment: documented, per product, updated on changes (Art. 13).
3. SBOM: machine-readable, per release, automated – guide in how to create an SBOM.
4. Due diligence on third-party components: check and monitor open-source and purchased components – see open source under the CRA.
5. Secure by default and Annex I Part I: secure default configuration, access protection, data minimisation, reduced attack surface, logging.
6. Support period and update process: define the support period (generally at least five years), secure and where possible automatic security updates.
7. Technical documentation (Annex VII): product description, design and development, risk assessment, vulnerability handling, applied standards, test reports, support period.
8. Conformity assessment, EU declaration of conformity, CE: run the procedure for your category, issue the declaration, affix the CE mark, provide user information per Annex II.

What goes into the user information

Annex II requires, among other things: manufacturer name and contact, the vulnerability contact point, the product's intended purpose, known risks, where the SBOM can be accessed (if the manufacturer makes it available), the end date of the support period and guidance on secure installation and use. The end of support must be clearly visible at the time of purchase.

Template

A structured version of this checklist with owners, status and evidence fields is available on our CRA checklist page. Use it as a working list for your product team.

Common gaps

• Only the current release in view: reporting also covers older versions in the field.
• SBOM without process: a one-off list does not help when it counts.
• No end of support communicated: without a defined period you can neither plan costs nor meet Annex II.
• Documentation at the end: evidence is hard to reconstruct. Collect it during development.
• Waiting for standards: harmonised standards are in progress; the obligations apply regardless.

Who does what? Roles in the company

In small companies one person holds several roles. What matters is that every step has a named owner.

A realistic roadmap

For a mid-sized company with few products, a quarter-by-quarter sequence works well: first establish reporting readiness, then automate SBOM and component checks, then create the risk assessment per product and finally assemble the technical documentation. Bring class II products forward, because external assessment takes extra time.

Example: software house with three products

A software house with a desktop product, a mobile app and a server component starts with one runbook and one contact point for all three. SBOM generation and vulnerability matching are set up identically in all pipelines. Risk assessments and support periods, however, are defined per product because usage and lifetime differ.

Example: agency with a client portfolio

An agency works through the checklist twice: once for its own products, once as a service list for clients. For client projects it focuses on the steps it can deliver technically – SBOM, updates, component checks – and hands the evidence to the manufacturer.

Using the checklist in your team

The checklist only pays off if it is maintained regularly. A short fixed meeting every two weeks works well, where the team reviews status, blockers and next steps per product. Every completed step gets evidence: a document, a pipeline log, an SBOM file or minutes.

• Status: open, in progress, done – with date.
• Evidence: link to the concrete artefact, not just a tick.
• Next review: risk assessments and SBOMs age; define when they are rechecked.

That way the technical documentation grows along the way instead of being assembled under time pressure at the end.

Work through it with Nuowei

Nuowei (beta, launch November 2026) maps these steps as a per-product work list and links them to evidence collected automatically from repository and pipeline. Join the waitlist.