The EU Cyber Resilience Act: What Changes, and the Deadlines That Are Already Running

For years, cybersecurity was something you added to a product if your customers asked for it. In the European Union, that era is ending. A new law now treats security as a condition for selling a product at all, and the first hard deadline has already passed.

The law is the Cyber Resilience Act. It applies to any product with digital elements sold in the EU, from industrial controllers to consumer gadgets to standalone software. If a product connects to a network or another device, it almost certainly falls in scope. For companies used to thinking of cybersecurity as optional, this is a real shift, and the clock is already running on parts of it.

What Actually Changes

The core change is simple to state and hard to absorb. Under the Cyber Resilience Act, cybersecurity becomes a market access requirement. A product that is not secure by design cannot legally be placed on the EU market, the same way a product that fails a safety test cannot.

Software gets the CE mark for the first time. The mark that used to live on machines and electronics now applies to digital products too, and it signals that the product meets the new security requirements.

The second big change is that compliance never ends. Before the CRA, a manufacturer could certify a product and move on. Now, placing a product on the market opens a maintenance obligation that runs for a minimum of five years, with security updates provided free of charge for at least ten. Security becomes a commitment across the life of the product, not a box ticked at launch.

Two Kinds of Obligations

The law splits into two halves, and companies tend to prepare for one and forget the other.

The first half covers the product itself before it reaches the market: secure default settings, encrypted communications, access control on every interface, software integrity checks, and resilience against denial-of-service attacks. These are design requirements, baked in before the first unit ships.

The second half covers what happens after launch. Manufacturers must keep a Software Bill of Materials for each product, run a formal process for handling vulnerabilities, publish a disclosure policy, and push out patches without undue delay. This operational side is heavier than it looks on paper, because it demands a standing capability, not a one-time effort.

Not Every Product Follows the Same Route

The CRA sorts products into four categories, and the category decides how hard the road is.

Most basic connected devices fall into the Default class and can self-assess. Products like routers, smart cameras and smart locks fall into Important Class I, where self-assessment works only if a harmonized standard has been applied. Industrial IoT gateways and firewalls fall into Important Class II and require a third-party notified body, with no exceptions. At the top, hardware security modules and smart meter gateways need full EU cybersecurity certification.

Knowing your class early matters, because it drives cost, timeline, and whether you need an outside body involved at all.

The Standards Gap

Here is the practical catch. The CRA relies on harmonized standards as the main route to proving conformity, but as of mid-2026 no harmonized standards for the CRA have been published in the Official Journal of the EU.

For companies aiming to self-assess under Class I, this creates a real gap. Without a published standard to apply, the presumption of conformity those standards normally provide is not yet available. In the meantime, manufacturers lean on sector references like EN 303 645 for consumer IoT, IEC 62443 for industrial systems, and EN 18031 for radio equipment, and they document their own mapping to the CRA’s requirements until the official standards arrive.

The Deadlines That Are Already Running

This is where many companies are behind, because the first obligation is already live.

Since 11 September 2026, the vulnerability reporting duty under Article 14 applies. When a manufacturer learns that a vulnerability in its product is being actively exploited, it must notify its national CSIRT and ENISA within 24 hours of discovery, file a full notification within 72 hours, and submit a final report within 14 days. This applies to products already on the market, not just new ones, which is what catches companies off guard.

Those windows are tight, and meeting them takes a process set up in advance. The detail of where and how to file, and to which authorities, matters enough that it is worth understanding the mechanics of reporting vulnerabilities before an incident forces the question.

The next date is 11 December 2027, when full CRA compliance is required for every product placed on the market. That is the deadline most companies think of as “the CRA deadline,” and it covers the full set of design and lifecycle obligations.

After that, on 11 June 2028, existing type-examination certificates issued under previous frameworks expire. Products relying on older certificates will need to be brought under the new regime by then.

What To Do Now

The mistake is reading December 2027 as the only date that matters and treating everything as a 2027 problem. The reporting obligation is already in force, and it applies to products you sold months or years ago.

A sensible order of work is to confirm which of your products fall in scope, identify the class each one lands in, and stand up a vulnerability handling and reporting process now, since that is the piece the law already demands. The design and documentation work can follow on the longer runway toward December 2027.

The CRA is one of the most significant product laws the EU has passed in years, and its timeline is not waiting for anyone to be ready. The companies that treat it as a live obligation rather than a future one are the ones that will avoid a scramble when enforcement sharpens.