The EU Cyber Resilience Act: what the 2026 deadline means for anyone who ships software

If your business makes or sells software, connected devices, or anything with digital elements into the EU, a new regulation now governs how secure those products have to be — and it has a clock that most businesses are reading wrong. The EU Cyber Resilience Act sets binding cybersecurity requirements across the entire lifecycle of a product, from design to end of support. Its headline deadline is December 2027, but the date that actually bites first is in 2026, and meeting it depends on work that has to start well before then.

What the CRA is

The Cyber Resilience Act is an EU regulation that applies to almost any “product with digital elements” placed on the EU market — software, IoT devices, operational technology, networking equipment, embedded systems, and much more. It entered into force in December 2024 and introduces obligations that run across the whole product lifecycle: secure-by-design engineering, a software bill of materials, coordinated vulnerability handling, and the duty to provide security updates for the product’s expected lifetime. Crucially, it reaches manufacturers based outside the EU if their products reach the EU market, so “we’re not an EU company” is not an exemption.

The dates that matter

The CRA phases in. Full application — secure-by-design requirements, conformity assessment, CE marking, technical documentation and the rest — applies from 11 December 2027. But the obligation that lands first is vulnerability and incident reporting, which applies from 11 September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national authorities on a strict clock: an early warning within 24 hours, a fuller notification within 72 hours, and a final report after a patch is available. This reporting duty applies even to products already on the market, not just new ones.

That September 2026 date is the one businesses underestimate, because they anchor on the 2027 headline. The reporting obligation is closer, and it is unforgiving.

The hidden dependency

Here is the part that catches people out. To report an exploited vulnerability within 24 hours, you have to know what is in your products — which components, which versions, which dependencies. That requires a software bill of materials and an automated way to track vulnerabilities against it. The full software-bill-of-materials obligation is technically a 2027 requirement, but you cannot meet the 2026 reporting duty without that capability already in place. So the practical readiness date is earlier than either headline suggests: the foundations have to exist before the reporting clock starts.

This is also a supply-chain problem. Your products contain components and libraries from others, and your ability to comply depends on visibility into them — which is exactly the kind of dependency mapping that should be defined up front, in the spirit of getting a specification right before you build.

Who is in scope, and what it costs to get wrong

The scope is deliberately broad. If your product has digital elements and reaches the EU market, you are likely in scope, whether you are a software vendor, a device manufacturer, or a business that embeds software in what it sells. Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher — penalties in the same territory as the GDPR, which signals how seriously the EU takes this. For a product business, this is not a peripheral compliance matter; it is a condition of selling into the EU at all.

The CRA sits alongside the EU’s other cybersecurity regimes rather than replacing them. It complements NIS2, which governs the security of organisations rather than products, and overlaps in spirit with the operational-resilience expectations of DORA for financial entities. A business may find itself in scope of more than one, and the underlying engineering discipline largely serves all of them.

What to do now

The work breaks into a sensible order. First, establish whether your products are in scope — which, for most businesses that ship anything digital into the EU, they are. Second, build the foundations the 2026 reporting duty depends on: a software bill of materials and a vulnerability-handling process, so you can identify and report exploited vulnerabilities on the required clock. Third, work towards the 2027 requirements — secure-by-design practices, conformity assessment, documentation and lifetime security updates — which are larger and benefit from lead time. None of this is achievable as a last-minute scramble, which is precisely why the September 2026 date should be on the plan now.

The CRA turns product security from good practice into a legal obligation with real penalties, and the first deadline is closer than the headline suggests. Let’s work out whether you’re in scope and what readiness actually requires.

Start a Conversation

This is general information about the technology dimension of the regulation, not legal advice. For a formal view of your CRA obligations, take advice from a qualified legal adviser.