The EU's New 24-Hour Bug Reporting Rule Starts September 11. Most Vendors Aren't Ready.

Key points

• The EU Cyber Resilience Act's vulnerability reporting rules take effect on 11 September 2026, covering any software or connected product sold into the European Union.
• Vendors will have as little as 24 hours to report a flaw that is being actively used by attackers to ENISA, the EU's cybersecurity agency.
• The requirement applies whether the vendor is based in Europe or not, so US and UK software companies are in scope too.
• The practical bottleneck is not the report itself, it is knowing exactly which version of your product shipped to which customer and when a bug was first spotted internally.
• Fines for non-compliance can reach 15 million euros or 2.5% of global turnover, whichever is higher.

What is actually changing on September 11?

A new EU law starts biting. It is called the Cyber Resilience Act, or CRA, and it says any company selling software or a connected gadget into Europe must tell regulators within 24 hours when they learn a flaw in their product is being actively abused by criminals.

A follow-up report is due within 72 hours, and a full technical writeup within 14 days. The reports go to ENISA, which is the EU body that coordinates cybersecurity across member states.

The clock starts the moment the vendor becomes aware of the problem. Not when the fix ships. Not when the marketing team is comfortable. Awareness.

Why is this harder than it sounds?

Because most software companies genuinely do not know what they shipped. That is the uncomfortable truth the CRA is about to expose.

In practice, a modern product is a stack of open-source libraries, third-party components, and internal code, assembled by a build pipeline that changes weekly. Ask a typical engineering team which exact version of a logging library went out in the release last March, and you will get a shrug and a promise to check the build logs.

The failure mode here is not malice. It is that Software Bills of Materials, the ingredient lists that record what went into each release, are still treated as a compliance chore rather than an operational tool. When a bug like Log4Shell lands, teams spend days grepping through Jenkins output to work out who is exposed. Twenty-four hours is not enough time for that.

Who does the rule apply to?

Anyone selling into the EU, full stop. A US SaaS vendor, a UK IoT startup, a German embedded systems firm: all in scope if their product ends up in a European customer's hands.

As first reported by BleepingComputer, guidance from vendor ActiveState stresses that the hard problem is provenance, meaning being able to prove what code shipped, when, and to whom. Without that, the 24-hour clock is unwinnable.

What are the deadlines and penalties?

Here is the shape of it in one place.

The fines are on the same tier as GDPR, the EU's data protection law. Regulators have shown they will use them.

What should vendors actually do now?

Start with the boring stuff. Get a real SBOM pipeline running, meaning every build produces a machine-readable list of what went into it, stored somewhere you can query in an hour, not a week. Tag every release with the exact commit and dependency versions.

Then wire your internal bug tracker to a disclosure workflow with named humans on call. When a researcher emails security@ at 2am on a Sunday, someone needs to see it before Monday standup. One thing the post-mortem will say, if you get this wrong, is that the report existed in someone's inbox for 48 hours before anyone noticed.

Operational takeaway: if you cannot answer "what shipped, and when did we know?" in an hour today, the CRA will make that gap very expensive next September.