The EU Cyber Resilience Act Timeline: A Compliance Checklist for Software Vendors

If you sell software or smart hardware into the EU, the Cyber Resilience Act (CRA) is the regulation to take seriously over the next two years. It entered into force on 10 December 2024 and applies in stages:

• 11 September 2026 — vulnerability and incident reporting obligations begin: actively exploited vulnerabilities must be pre-notified to ENISA within 24 hours of awareness, with a fuller report within 72 hours.
• 11 December 2027 — the Act applies in full: any "product with digital elements" placed on the EU market must meet essential cybersecurity requirements and complete conformity assessment.
• The price of non-compliance: fines up to €15 million or 2.5% of global annual turnover, whichever is higher, plus forced market withdrawal.

Broader scope than you think

The CRA covers "products with digital elements" — operating systems, applications, SDKs, smart-home devices, industrial controllers, IoT: virtually any hardware or software that can connect, directly or indirectly (with carve-outs for domains covered by other regulation, such as cloud services and medical devices). The key point for non-EU vendors: there is no local-entity threshold. If the product reaches the EU market, manufacturer obligations land on you.

The four core obligations

One, security by design: secure default configuration, shipped without known exploitable vulnerabilities. Two, a vulnerability handling process: intake, remediation and free security updates across a support period of in principle no less than five years. Three, an SBOM: a machine-readable software bill of materials covering at least top-level dependencies — the clause that turns SBOM from best practice into legal requirement; see our complete SBOM guide for formats and tooling. Four, technical documentation and CE marking, with evidence retained for ten years.

Product classes determine your assessment path

The CRA tiers products by risk. Most ordinary software can use self-assessment. "Important" products (operating systems, password managers, VPNs, firewalls, security-relevant IoT) must apply harmonized standards or involve third-party assessment; a small set of "critical" products (smart cards, secure elements) faces stricter routes. Map your portfolio against the annexes first — the cost difference between paths is large.

On open source: read the exemption carefully

The exemption covers only non-commercial development and supply of open source. Two common situations are not exempt: integrating open-source components into a commercial product — the manufacturer obligations are yours (which is precisely why SBOM and composition analysis become mandatory plumbing); and commercializing open source through paid support or dual licensing. Pure SaaS is outside the CRA (it falls under NIS2), but remote data-processing features tied to a device remain in scope.

A six-point checklist

• Inventory products sold into the EU and classify them against the important/critical annexes.
• Build SBOM capability: generate and maintain SPDX/CycloneDX SBOMs per product with an SCA platform; cover source-less third-party deliverables with binary composition analysis.
• Clear the vulnerability backlog: "no known exploitable vulnerabilities at release" means pre-release scanning plus documented risk assessment.
• Stand up the reporting pipeline: a 24-hour window is brutally short — wire and rehearse discovery → triage → ENISA notification in advance.
• Define support policies: declare a support period per product and budget five years of security updates.
• Keep the evidence chain: from threat modeling to scan reports to fix records, fully auditable.

Two years sounds generous, but SBOM programs, response pipelines and five-year support commitments are not three-month projects. Start now and the timeline just about works.