Since 11 September, a Bug in Your Product Can Start a 24-Hour Clock

Since 11 September, one part of the EU Cyber Resilience Act applies in full. If you sell software in the EU, or a machine with software in it, and you learn that someone is actively exploiting a vulnerability in it, you have 24 hours to send an early warning to your national CSIRT and to ENISA. A fuller notification follows within 72 hours. A final report is due within 14 days of a fix being available, or within a month for a severe incident.

Most of the regulation applies only from December 2027, which is why many teams have filed it under “later”. The reporting duty is the exception. It applies now, and it covers products already in your customers’ hands. Missing it can cost up to €15 million or 2.5% of worldwide turnover.

The detail that matters most for anyone who works with a development partner: the clock starts when the manufacturer becomes aware. Not when the people who wrote the code do.

What the first day looks like

Take a made-up but ordinary case. A software vendor sells a warehouse app to a few hundred companies. On a Saturday morning, one customer’s IT department writes to the support address: they have seen someone use a flaw in the app’s login to read stock data, and they think others are being targeted too.

Someone has to read that email on Saturday, not on Monday. The Commission’s guidance says the clock starts once you are reasonably certain, after a first assessment, that exploitation is happening. That assessment needs a person who can make it.

Within the first few hours, that person needs answers to three questions. Which versions of the app are out there and which customers run them. What is inside those versions, down to the libraries and their versions. And who can build, test and ship a fix, and how fast. The early warning itself does not need a fix. It needs facts, and the facts are only quick to find if they were written down before the incident.

If the code came from a partner, every one of those answers runs through them. On a Saturday.

The clock does not care who wrote the line

Many software vendors and machine builders ship code they did not write themselves: a white-label app, an agency’s front end, a module from a former freelancer. Under the CRA, the duties stay with whoever puts the product on the market under their name.

We are often on the other side of that arrangement. We built and maintain a native Android warehouse and production app for a software vendor, sold under the vendor’s own brand to its Sage 100 customers. The vendor is the manufacturer. If something in that app were exploited, the vendor’s 24 hours would depend on how fast we could answer those three questions.

Our support tiers were not designed with the CRA in mind. Reading them again with it in mind, the difference between them comes down to who answers on a Saturday: business hours, extended hours, or near round the clock. For a product that falls under the CRA, business hours is no longer enough, and that belongs in the conversation before a client picks a tier.

What has to exist before the email arrives

A list of the components in every release, generated by the build rather than assembled by hand when something happens. The CRA formally requires this kind of documentation from December 2027, and the BSI’s technical guideline describes what a good one contains. But the reporting duty started in September, and without the list, a 24-hour answer is a guess.

A named person who reads the support channel outside office hours and is allowed to start the report. An agreement with your development partner that covers response times, access to the build history, and who drafts the technical part of the notification. And a way to get a fix onto installed devices, because the final report asks what you did about it.

Bespoke software built for a single client, or a pure online service, is treated differently, and where the line falls for a particular system is a question for legal advice. A product you sell to many customers, or a machine you ship with software inside, is the clear case.

If your product contains code we wrote, we would rather have this conversation now than on a Saturday. If it contains code someone else wrote, the same conversation is worth having with them. Either way, talk to us.