The EU clock that starts on Friday

17 September 2026 · Carl Heaton · Security Commentary

If your business puts a product into the European Union, a connected device, an installed application, a piece of firmware, a legal clock starts on Friday and nobody sent you a letter about it.

From 11 September, when you become aware that a vulnerability in one of your products is being actively exploited, you will have 24 hours to raise the alarm with a European authority. Not 24 working hours. Not once you have understood it. Twenty-four hours from becoming aware.

What actually changes

The EU Cyber Resilience Act is a broad law about the security of products with digital elements, and most of it does not apply until December 2027. The reporting obligation was deliberately pulled forward by more than a year, and the European Commission confirms it applies from 11 September 2026.

It is not one deadline but three, and the trade coverage has mostly reported only the first. The Commission's own guidance sets out the sequence for an actively exploited vulnerability:

Within 24 hours of becoming aware: an early warning.
Within 72 hours: a full notification.
Within 14 days of a fix being available: a final report. For a severe incident rather than a vulnerability, the final report is due within one month.

The second correction worth making: you do not report to ENISA directly, as several write-ups suggest. You notify the national computer security incident response team, the CSIRT, in the country where your business has its main establishment, and the information reaches ENISA at the same time. That CSIRT then shares it with its counterparts in every country where your product is sold.

Who this catches

Three questions settle it, and most readers will stop at the first.

1. Do you place a product on the market, or provide a service?

The Act covers "products with digital elements", which the Regulation defines as a software or hardware product, including components sold separately. A product is something supplied for distribution or use. A service is something you run on the customer's behalf.

Software delivered purely as a service is not covered. This is the boundary most likely to be reported wrongly. Cloud counts only when it is what the Regulation calls a remote data processing solution, meaning software the manufacturer designed for their own product and without which the product cannot do one of its jobs. The Regulation's example is the cloud functionality a smart home device needs so you can control it remotely.

Recital 12 is explicit about the other direction:

"cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the scope of this Regulation. Directive (EU) 2022/2555 applies to cloud computing services and cloud service models, such as Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS)."

That takes out most of what UK technology businesses sell into Europe: subscription web applications, web hosting, managed cloud, infrastructure services. They are services, and they point at NIS2 rather than here.

What remains, and is caught: software a customer downloads, installs, or runs themselves, whether desktop, mobile, or on their own servers. Connected hardware. Firmware. A component you supply that goes into someone else's product. Any of those with essentially any network connectivity.

2. Are you the manufacturer of it?

The reporting duty in the Act falls on the manufacturer, not on everyone in the chain. The Regulation defines a manufacturer as whoever develops or manufactures a product, or has it developed for them, and markets it under their own name or trademark.

Two consequences worth knowing. If you commission a product and sell it as yours, you are the manufacturer even though somebody else built it. And if you resell or distribute somebody else's product unchanged and under their name, this particular clock is not yours, though the Act places other, lighter duties on importers and distributors.

3. Does it reach the EU market?

You do not need to be based in the EU, or have an office there. The test is whether the product is supplied for distribution or use on the Union market in the course of commercial activity.

The phrase that catches people out is in the definition: "whether in return for payment or free of charge". A free tier, a community edition, or a no-cost utility that anyone in the EU can download is still being made available on the market. Charging nothing does not put you outside the Act.

Free and open-source software is treated separately. The Act creates a lighter regime for open-source software stewards, foundations and similar bodies that support open-source development, and does not put them under the full manufacturer obligations. Publishing a library on GitHub in your own time is not what this law is aimed at. Selling a commercial product that happens to be open source is a different matter.

Worked examples

A Sheffield firm selling an installed Windows application to a customer in Dublin: in scope, they are the manufacturer and it is a product on the EU market.
The same firm running that application as a hosted subscription instead: not in scope here, that is a service, and NIS2 is the relevant regime.
An agency building a website for a French client: not in scope, it is a service delivered to one client, not a product placed on a market.
A hardware maker shipping a connected sensor to Germany through a distributor: in scope, and the manufacturer holds the reporting duty, not the distributor.
A UK company that commissions an app from a contractor and sells it under its own brand in the EU: in scope as the manufacturer, despite not writing the code.
A firm giving away a free desktop utility that EU users download: in scope, because "free of charge" is explicitly included.
A managed service provider looking after European clients' infrastructure: not in scope here, that is a service.

If you do both products and services, you are in both conversations, with different regulators and different clocks.

The number that should focus attention

Breaching the reporting obligation sits in the Act's top penalty tier. The Regulation itself sets fines of up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.

Most coverage quotes the €15 million and stops. "Whichever is higher" is the part that matters: the fixed sum is not a ceiling a large manufacturer can treat as the cost of ignoring the rule.

The Act does contain proportionality language for micro and small enterprises, and member states are encouraged to support smaller manufacturers with training. That reduces the administrative burden. It does not create an exemption from the reporting duty.

What to do about it

The 24-hour clock is short enough that you cannot invent a process once it starts. Almost all of the work is done in advance.

Write down your answer to the three questions above, and the date. Most readers will conclude they are out of scope. That conclusion is worth recording, because the useful artefact is a dated note saying who decided and why, not a memory of having thought about it once.
Know which CSIRT is yours. For a UK business the answer depends on where your main establishment in the EU is, or on where you first placed the product on the market. Establish that now. Looking it up under pressure is exactly what the 24-hour window does not allow.
Define what "becoming aware" means in your business. The clock starts when you know, and knowledge usually arrives somewhere unglamorous: a support ticket, a researcher's email, an alert nobody triaged. Somebody needs the authority to say "this one counts" without waiting for a meeting.
Write the early warning template before you need it. A first report at 24 hours is not a full analysis. It says what the product is, what you know, and that you are investigating. Having a form with the fields already agreed turns a frightening deadline into a task.
Check your inbound route works. If a researcher finds a flaw in your product, can they reach you? A monitored security contact address, and a published policy saying what you do with a report, is what turns an outside discovery into something you can act on inside a day. Ours is at /security.txt if you want a pattern to copy.
Keep a record of the decision either way. If you conclude you are not in scope, or that a given vulnerability is not being exploited, write down who decided and on what basis. That record is the difference between a defensible judgement and an unexplained silence.

This is a reporting obligation, not a technical standard, and it will be met or missed on ordinary organisational things: who is watching the inbox, who can make a call at short notice, and whether anyone has read the form before the day it matters.

How Steelwise can help

Working out whether the Act catches your products, which authority you would notify, and what your first 24 hours would actually look like is a short, well-defined piece of work. Get in touch if you would like a hand with yours.