# The EU CRA's 24-Hour Clock Starts Thursday. Most Vendors Aren't Ready.
Two days. That's what software vendors selling into the EU market have left before the Cyber Resilience Act's vulnerability reporting requirements go live on September 11. The new rules give companies as little as 24 hours to notify authorities after discovering an actively exploited flaw in a product with digital components. And the central question the CRA will force every vendor to answer — sometimes under legal pressure — is one that most software organizations genuinely cannot answer today: *What exactly shipped, and when did you first know it was broken?*
Those two questions are not as simple as they sound.
---
## The 24-Hour Standard Is Not a Typo
For context, GDPR gives companies 72 hours to report a personal data breach to regulators. The CRA's 24-hour window for actively exploited vulnerabilities is tighter by design — the EU's signal that passive disclosure timelines of the past are over. An additional 72-hour window follows for a more complete vulnerability report, with a final detailed notice due within 14 days. But that first 24-hour notification is the one that will define whether a company is in compliance or in violation from day one.
The rule applies to any product with digital elements placed on the EU market — which covers an enormous footprint. Embedded firmware, connected devices, enterprise software, SaaS products with downloadable clients — the scope is deliberately wide. Vendors who've been treating CRA as a 2025 problem and kicking it down the road are going to find themselves kicking it directly into a live regulatory wall this week.
---
## "What Shipped" Is Harder Than It Sounds
Here's where the technical reality collides with legal obligation. When a critical vulnerability surfaces in a widely used open-source dependency, the question "do our products contain this?" is rarely trivially answered. The lesson was written in fire with Log4Shell in December 2021. Within days of that disclosure, security teams across thousands of organizations were frantically tearing through their own software inventories, many discovering for the first time that they genuinely didn't know what was inside their own products.
The problem hasn't gone away. Modern software is an aggregation of hundreds or thousands of transitive dependencies. A Java service might pull in 300 packages. Each of those packages pulls in others. A vendor who built a shipping product two years ago and hasn't maintained a Software Bill of Materials — a structured inventory of every component — may not be able to tell you within 24 hours whether the vulnerable package is in their codebase, let alone in which product versions they shipped.
SBOM adoption has grown since Log4Shell, but adoption is uneven, and most organizations are still better at generating SBOMs for new projects than for legacy software that's been in production for years. Those legacy products are often the ones running on the most critical infrastructure.
---
## The Liability Trap Hidden in "When Did You Know"
The discovery timeline question is potentially more dangerous than the inventory question, because it carries legal weight that the inventory question alone doesn't.
If a CVE was published against a component in your product six months ago and you're only reporting it to the EU now — after it becomes actively exploited — the question "when did you know?" becomes a liability determination. Did your security team receive scanner alerts? Did your dependency management tooling flag it? Did a customer file a bug report that, in retrospect, looks like exploitation? Each of these events can constitute "discovery" in a regulatory or legal sense, even if no human consciously connected the dots at the time.
This is the same dynamic that's played out in SEC cybersecurity disclosure enforcement in the US — where the question isn't just whether you disclosed, but whether you disclosed *promptly* from the point of actual or constructive knowledge. The CRA doesn't have the same enforcement infrastructure as the SEC, but the European Cyber Resilience Act's penalties can reach up to €15 million or 2.5% of global annual turnover, whichever is higher. That's enough to focus legal minds.
---
## What Vendors Need to Do Before Thursday, and After
There's no patching this gap in two days. But there are concrete prioritization decisions companies should be making right now.
Immediate triage:
Structural work that can't wait:
The companies most exposed are mid-size independent software vendors who don't have dedicated product security teams — the kind of company that has a CISO but no one whose specific job is tracking vulnerability discovery timelines and coordinating regulatory notification. Those organizations are going to need external tooling and process help faster than they probably anticipated.
---
## HackWire Analysis
The framing from ActiveState — a company that sells software composition analysis tooling — is accurate, but it undersells the structural shift the CRA represents. This isn't just a compliance checkbox. The EU is systematically dismantling the soft convention that software vendors could sit on vulnerability knowledge until it was convenient to disclose.
The 24-hour window for active exploitation is the sharp edge, but the broader arc is toward mandatory transparency about the entire lifecycle of how a flaw went from "theoretical CVE" to "actively exploited" while living inside a product. That arc runs directly into a problem the industry has consistently kicked down the road: the absence of durable, accurate software inventories.
Log4Shell revealed that vulnerability response at scale requires knowing what's in your software — not just what you think is in it. The CRA now creates regulatory and financial pressure to solve that problem permanently, not just in response to the next high-profile CVE. Vendors who have invested in SBOM generation, automated SCA in CI/CD pipelines, and formal vulnerability triage processes are meaningfully better positioned than those who haven't, and not because they'll necessarily suffer fewer vulnerabilities — but because they'll be able to demonstrate discovery timelines with evidence rather than guesswork.
There's also a tension worth watching: the 24-hour notification requirement creates incentive to delay internal acknowledgment of a vulnerability to avoid triggering the clock. That's exactly the wrong behavior, and EU regulators almost certainly anticipate it. Expect guidance that defines constructive knowledge broadly, and enforcement actions that focus on companies whose notification timelines look suspiciously slow relative to public CVE disclosure dates.
— HackWire Editorial
---
## Related Coverage