The CRA compliance checklist for indie developers and small teams

Why this list exists

The CRA is 100+ pages of regulation. For a small software team, the actionable core fits on one page. This is that page — each item mapped to the article that requires it, ordered so the cheap, high-value work happens first.

Time budget honesty: a default-class product with a modern build pipeline can get from zero to 'defensible' in roughly one to two weeks of part-time work. The items below add up to that.

Do this week (each under an hour)

• ▸Publish a security.txt at /.well-known/security.txt with a working contact (Annex I Part II(6)). Use our free generator.
• ▸Publish a coordinated vulnerability disclosure policy — SECURITY.md in the repo plus a page on your site (Annex I Part II(5)). Also generatable in minutes.
• ▸Add SBOM generation to your CI: syft or cdxgen emitting CycloneDX JSON on every release, stored as a build artifact (Annex I Part II(1)).
• ▸Turn on dependency vulnerability alerts (GitHub Dependabot/OSV-Scanner in CI) so 'we didn't know' never happens (Annex I Part II(2)).

Do this quarter

• ▸Write down your incident reporting process: who detects, who decides it's 'actively exploited', who files, who is backup. One page. Rehearse it once — the 24-hour clock is unforgiving (Art. 14).
• ▸Run a lightweight threat model of your product and write the outcome into a risk assessment doc (Art. 13(2)-(3)).
• ▸Start a technical documentation file: architecture overview, risk assessment, test evidence, SBOM references (Art. 31 + Annex VII). A well-kept folder beats a fancy tool.
• ▸Define and publish your support period per product — the default expectation is at least 5 years (Art. 13(8)).
• ▸Audit your update channel: are updates signed? Can you ship a security-only fix without bundling features? Free of charge? (Annex I Part I(2)(c), Part II(7)-(8)).

Before 11 September 2026

The reporting obligations apply from this date regardless of when the rest of the CRA bites. If an actively exploited vulnerability in your product or a severe incident hits after this date, you must file an early warning within 24 hours via the ENISA Single Reporting Platform, a notification within 72 hours, and a final report after remediation.

• ▸Register on the ENISA Single Reporting Platform as soon as onboarding opens (ENISA is publishing instructions and dry-run support).
• ▸Wire your vulnerability monitoring to an alerting channel someone actually reads on weekends.
• ▸Pre-draft your early-warning template so a 3 a.m. incident starts from 80% done. Our deadline calculator generates one.

Before 11 December 2027

Full application: you may not place non-conforming products on the EU market after this date. For default-class products (most apps, games, plugins, tools) the conformity route is internal control — you self-assess against Annex I, complete the technical file, sign the EU Declaration of Conformity, and affix the CE marking.

• ▸Complete the Annex I self-assessment and close the gaps it finds.
• ▸Finalize the technical documentation (Annex VII) — 10-year retention.
• ▸Issue the EU Declaration of Conformity (Annex V) and apply CE marking rules to your product listing/packaging.
• ▸Important/critical class (Annex III/IV) products: book a notified body early — capacity in 2027 will be the bottleneck.

What you can safely ignore

Enterprise GRC suites, ISO 27001 certification (helpful, not required), consultants selling 'CRA gap analyses' that produce a PDF of what this page already told you. The CRA asks for engineering hygiene plus paperwork discipline — both automatable, neither requiring a compliance department.