Twenty-four hours to report an exploited vulnerability

The EU Cyber Resilience Act has a date that deserves more attention than it is getting from teams outside Europe: 11 September 2026.

From that date — four days after this is published — manufacturers of products with digital elements sold into the EU must report actively exploited vulnerabilities to ENISA and the relevant national CSIRT within 24 hours of becoming aware of them.

The 24 hours is an early warning. A detailed notification follows within 72 hours, and a final report with a fix within 14 days. Full compliance — secure-by-design obligations, SBOM requirements, CE marking — arrives on 11 December 2027.

Twenty-four hours is not a lot of time to establish whether you are affected, and that is the part that turns a reporting rule into an engineering requirement.

The scope is wider than "software company"

"Products with digital elements" covers software, IoT devices, operational technology, medical equipment, networking gear and embedded systems. If it has code in it and it is placed on the EU market, it is in scope.

Crucially, this applies to products you shipped years ago. There is no grandfathering that exempts your existing estate. A product still on the market is a product you are reporting for.

For a studio that builds software for clients, the obligation typically lands through the client relationship — they are the manufacturer placing the product on the market, and they will need answers from whoever built it. In practice that means you.

Why the SBOM deadline is misleading

The formal software bill of materials requirement belongs to the December 2027 deadline, and a lot of coverage has filed it under "not urgent".

That reading does not survive contact with the 24-hour clock. To report an actively exploited vulnerability within a day, you must first be able to answer whether your product contains the affected component — and in which version, in which release, shipped to whom.

Without a component inventory, that question takes days of archaeology. With one, it takes minutes. So the SBOM is not a 2027 obligation with a 2027 deadline; it is the prerequisite for a 2026 one.

The requirement itself is modest: a machine-readable inventory covering at minimum top-level dependencies, kept in your technical documentation, handed over to market surveillance authorities on request. It does not have to be published. It does have to be current — an SBOM generated once and never regenerated is worse than none, because it will confidently tell you the wrong thing during an incident.

What this actually asks of an engineering team

Read as a compliance document it is intimidating. Read as engineering practice it is mostly things a careful team already wants.

Generate an SBOM in CI, per release, and store it with the artefact. The tooling here is mature — CycloneDX and SPDX are well supported and generation is a build step, not a project.

Know which versions are deployed where. Most organisations can answer this for their main product and not for the three things they shipped to clients in 2023.

Have a named path for vulnerability reports to reach a human quickly, and a decision-maker who can authorise a disclosure without a week of internal escalation. Twenty-four hours does not survive a committee.

Track end-of-life dependencies deliberately. A component no longer receiving security updates is a permanent open item, and under this regime it is one you have to reason about publicly.

The honest assessment

There is a reflex to treat every EU regulation as bureaucratic overhead invented by people who have never shipped software. Sometimes that is fair. Here I do not think it is.

The requirement is: know what is in your product, notice when part of it is being exploited, and tell someone quickly. Any team that cannot do those three things has a security problem that exists independently of whether Brussels wrote it down.

The genuine burden falls on organisations with large legacy estates and poor records, and that burden is real. But the direction — that shipping software carries an ongoing obligation to know what is inside it — is one the industry has been avoiding for a long time on the grounds that it is tedious.

ENISA's reporting platform goes live the same day the obligation does, which leaves no bedding-in period. If you sell into the EU, directly or through a client, the useful question this week is whether you could answer "is our product affected" in an afternoon, without guessing.