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 software or connected products sold into the European Union.
• Vendors have as little as 24 hours to report a flaw being actively exploited to ENISA, the EU's cybersecurity agency.
• The requirement applies whether the vendor is based in Europe or not, so US and UK companies are in scope.
• The real bottleneck is knowing exactly which version of your product shipped to which customer and when a bug was first spotted internally.
• Penalties for non-compliance can reach 2.5% of global turnover.

What is actually changing on September 11?

A new EU law starts biting. The Cyber Resilience Act says any company selling software or a connected device into Europe must tell regulators within 24 hours when they learn a flaw is being actively abused.

Reports go to ENISA, 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 comms team signs off. Awareness.

Why is this harder than it sounds?

Because most software companies genuinely don't know what they shipped. That's the uncomfortable truth the CRA is about to expose.

A modern product is a stack of open-source libraries and third-party components assembled by a build pipeline that changes weekly. Ask a typical engineering team which exact version of a logging library went out last March and you'll get a shrug and a promise to check the build logs.

The failure mode isn't malice. 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's exposed. Twenty-four hours isn't enough time for that. We reported on 25 August how AI can now find serious flaws within hours, but the human systems for acting on them haven't kept pace; the CRA assumes a speed that most vendor processes can't match.

Who does the rule apply to?

Anyone selling into the EU. 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.

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

What are the deadlines and penalties?

Here's the shape of it in one place.

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

What should vendors actually do now?

Start with the boring stuff. Get a real SBOM pipeline running: every build produces a machine-readable list of what went into it, stored somewhere you can query in an hour. 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. The post-mortem, if you get this wrong, will say the report sat unread while the clock ran down.

Our coverage of the defence sector on 21 August found a similar gap between confidence and proof: vendors said they felt ready for new security rules while their ability to demonstrate it on paper was getting worse. Expect the same dynamic here.

If you can't answer "what shipped, and when did we know?" in an hour today, the CRA will make that gap very expensive next September.