CRA compliance checklist for software companies (2026–2027)
A phased, source-cited CRA checklist for software companies: what to do now, what the reporting obligations require, and what the full application of the Regulation asks for.
The EU Cyber Resilience Act has two dates that matter to a software company: 11 September 2026, for the reporting obligations, and 11 December 2027, for everything else (Article 71 of Regulation (EU) 2024/2847). Working backwards from those dates, here is the checklist — phased, and with the article of the Regulation behind every item, so you can verify rather than trust.
A warning before the list: most CRA content is written for device manufacturers. This checklist is for companies whose product is software — commercial applications, developer tools, components, and hybrid SaaS with shipped parts.
Phase 0 — Now: answer the two questions everything depends on
☐ Determine whether you are in scope. The CRA covers products with digital elements made available on the EU market in the course of a commercial activity (Articles 2 and 3). Pure browser-only SaaS is generally out; shipped components and the cloud processing they depend on are generally in. The boundary cases — hybrid SaaS, monetised open source, SDKs — are exactly that: cases. (Two-minute scope check here.)
☐ Determine your role. You are a "manufacturer" if you develop the product — but also if you sell someone else's product under your own brand, or substantially modify a product and place it on the market (Articles 21 and 22). Importers and distributors have their own, lighter duty lists (Articles 19 and 20). Role determines everything downstream, including who files the reports of Article 14.
☐ Classify your product. Most software is "default" class. But if your product appears in Annex III — password managers, VPNs, identity and access management, browsers, operating systems, SIEM, boot managers, PKI software, among others — it is an "important" product (class I or II), and your conformity assessment route changes substantially (Article 32). Annex IV lists "critical" products, mostly hardware-adjacent.
☐ If you white-label: start the supplier conversation now. All the evidence you will need — risk assessment, SBOM, vulnerability handling, support commitments — must come from your supplier by contract, and your negotiating leverage largely disappears once the deadline has passed.
Phase 1 — Reporting readiness: in force since 11 September 2026
☐ Build vulnerability visibility. You cannot report what you cannot see. Annex I Part II requires identifying and documenting the vulnerabilities and components in your product, including an SBOM in a machine-readable format covering at least top-level dependencies. Generating one is a solved problem (CycloneDX or SPDX); keeping it per release is the discipline that matters.
☐ Prepare the Article 14 workflow. The clock is in force since 11 September 2026: actively exploited vulnerability → early warning in 24h, notification in 72h, final report within 14 days of a fix; severe incident → 24h / 72h / one month. Decide now who classifies, who drafts, who submits via the single reporting platform (Article 16), and who informs users (Article 14(8) — a duty of its own). Draft the notification templates before you need them.
☐ Stand up coordinated vulnerability disclosure. Annex I Part II requires a CVD policy and a contact channel for reporting vulnerabilities. A policy page and a monitored security contact are the minimum credible version.
Phase 2 — Through 2027: engineering and evidence
☐ Apply the essential requirements to your development. Annex I Part I: secure-by-default configuration, no known exploitable vulnerabilities at release, protection of data confidentiality and integrity, attack-surface minimisation, secure update mechanisms — with automatic security updates as the default where applicable. Map each requirement to how your product implements it, and record the evidence; "we do this" without evidence will not survive an assessment.
☐ Decide and document your support period. At least five years in the general case, or the expected use time if shorter — with the reasoning documented (Article 13(8)). Security updates you release must remain available for at least 10 years or the support period, whichever is longer (Article 13(9)).
☐ Run and document a cybersecurity risk assessment. Required by Article 13(2)-(3), included in your technical documentation, and updated during the support period. This is the document that ties every other decision together.
Phase 3 — 11 December 2027: the formal layer
☐ Assemble the technical documentation. Annex VII specifies the contents: product description and intended purpose, architecture, the risk assessment, SBOM, vulnerability handling processes, support-period reasoning, standards applied, test reports, and the EU declaration of conformity.
☐ Complete the conformity assessment. Default products can generally self-assess (internal control, module A). Important class I products can only self-assess if harmonised standards are applied in full (Article 32(2)) — and those standards are still being developed, with published timelines slipping. Watch this: it silently decides whether you will need a third party. Class II and critical products have stricter routes.
☐ CE marking and declaration of conformity. The final, visible step (Article 13(12)) — and the one that is purely mechanical if the previous phases were real.
The honest summary
Phases 0 and 1 are cheap and urgent. Phase 2 is where the real work lives, and it is mostly good engineering you would want anyway. Phase 3 is paperwork that becomes easy or impossible depending on whether Phases 1-2 left evidence behind. Companies that treat the CRA as a December 2027 project will discover in late 2027 that evidence cannot be created retroactively.
→ Start with the two-minute scope check — verdict, role, product class, and the dates that apply to your case, with cited sources.
This article is general information about Regulation (EU) 2024/2847, not legal advice. Sources: Regulation (EU) 2024/2847 (EUR-Lex, Official Journal) — Articles 2, 3, 13, 14, 16, 19-22, 32, 71 and Annexes I, III, IV, VII; European Commission CRA guidance. Last reviewed: August 2026.
This is an automated regulatory assessment for orientation purposes, not legal advice. Final scope and classification depend on the specifics of your product and applicable guidance.