Cyber Resilience Act 2026: Full Enforcement Is 2027, but Your First Deadline Is This September

Quick Answer: The Cyber Resilience Act (CRA) — the EU's first law setting mandatory cybersecurity requirements for products with digital elements — entered into force in December 2024 and applies in full from 11 December 2027. But the 2027 date is the reason most teams have done nothing. Here is the part that changes the maths: the reporting obligations for actively exploited vulnerabilities and severe incidents start on 11 September 2026, and rules for notifying conformity assessment bodies began on 11 June 2026. Non-compliance carries fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. The CRA covers any manufacturer placing hardware or software with digital elements on the EU market, including companies based outside the EU.

The mistake is reading "full application in December 2027" as "I have eighteen months to think about it." Secure-by-design cannot be retrofitted in a sprint. The engineering, the software bill of materials, and the vulnerability-handling process all have to exist before the product ships — which means the real lead time started running a while ago.

The CRA phases in, and the phasing is where the planning happens. Treating it as a single 2027 event is how teams miss the obligations that arrive first.

The 11 September 2026 date is the one to circle. From that point, if your product has an actively exploited vulnerability or you suffer a severe incident, you must file an early warning within 24 hours and a more detailed notification within 72 hours. A reporting obligation with a 24-hour clock is not something you stand up the week before — it needs a defined process, named owners, and a tested channel, all in place ahead of time.

The CRA applies to products with digital elements — meaning hardware and software whose intended or foreseeable use includes a direct or indirect data connection to a device or network. That is a wide net: connected devices, embedded systems, firmware-driven products, operating systems, browsers, password managers, and a great deal of ordinary software.

It applies across the supply chain — to manufacturers, importers, and distributors — and it applies regardless of where you are based. A company outside the EU that places a digital product on the EU market is in scope, the same extraterritorial logic the GDPR established.

There are boundaries worth knowing. Pure Software-as-a-Service is generally outside the CRA, because the CRA is a product law rather than a services law — although remote data processing solutions that are necessary for a product to function can be pulled back in. Certain sectors already covered by their own regimes (most medical devices, aviation) are carved out. And non-monetised open-source software released outside a commercial activity is treated differently, with lighter obligations for open-source stewards.

The CRA turns two ideas that used to be best practice into legal obligations: the product must be secure by design, and the manufacturer must handle vulnerabilities across the product's whole life. In practice that breaks down into concrete duties.

One detail that surprises teams: documentation and evidence must be retained for ten years after a product is placed on the market, or for its support period, whichever is longer. Compliance is not a launch-day event — it is a decade-long obligation attached to every product you sell.

The CRA is the product-security piece of a larger EU architecture. NIS2 secures the organisations that run critical infrastructure and services. DORA secures operational resilience in the financial sector. The CRA secures the products themselves — shifting responsibility onto whoever places them on the market rather than leaving security to the end user.

For a company that builds software, this matters in a very practical way. The same engineering discipline — secure development, dependency visibility, vulnerability management, incident reporting — feeds all three regimes in different vocabularies. If you sell a connected product to an organisation that falls under NIS2, your CRA conformity is part of how that customer demonstrates its own supply-chain security. The frameworks reinforce each other, and the firms that plan for them together spend far less than the firms that treat each one as a separate fire drill.

The harmonised technical standards that will make CRA conformity straightforward are still being finalised, with key deadlines through late 2026. Waiting for perfect standards before you start is the trap — the foundational work does not depend on them. Three moves matter most right now.