The EU CRA's Real Question: What Shipped, and When Did You Know?

Recorded: Sept. 8, 2026, 9:01 p.m.

Original

News

Featured
Latest

Microsoft September 2026 Patch Tuesday fixes 966 flaws, 2 zero-days

Adobe fixes critical Magento zero-day exploited to backdoor servers

ShinyHunters hackers claim breach of Florida "DAVID" DMV database

August updates trigger 0xc0000409 errors on Windows Server 2016

DoppelCart fraud network uses 119,000 fake shops to steal credit cards

The EU CRA's Real Question: What Shipped, and When Did You Know?

Hackers breach F5 BIG-IP APM devices to deploy Linux rootkit

Microsoft releases Windows 10 KB5122878 extended security update

Tutorials

Latest
Popular

How to access the Dark Web using the Tor Browser

How to enable Kernel-mode Hardware-enforced Stack Protection in Windows 11

How to use the Windows Registry Editor

How to backup and restore the Windows Registry

How to start Windows in Safe Mode

How to remove a Trojan, Virus, Worm, or other Malware

How to show hidden files in Windows 7

How to see hidden files in Windows

Webinars
Downloads

Latest
Most Downloaded

Qualys BrowserCheck

STOPDecrypter

AuroraDecrypter

FilesLockerDecrypter

AdwCleaner

ComboFix

RKill

Junkware Removal Tool

Deals

Sponsored by ActiveState

September 8, 2026
04:24 PM
0

What a maintainer's disclosure inbox already knows about the question the EU Cyber Resilience Act is about to ask every software vendor.
Written by: Shane Warden, Principal Architect, ActiveState
Last year, someone submitted a vulnerability report to a security address for a free software project I help to review. The report followed our reporting guidelines, with a GPG signature and proper responsible disclosure ceremony, addressed only to the people who should have seen it.
It contained 95 vulnerabilities, purportedly. We took it seriously, because that security process exists for exactly this reason.
Yet something felt off, because how many human security researchers would compile a list 95 long and keep going instead of stopping at three or four and asking for a longer engagement.
Two or three of the 95 turned out to be real. That's a low percentage, and it didn't matter, because we still had to work through all 95 to find the two or three that did. Then came the second email: pay $100,000, or the report would go public with Heartbleed-style press.
The report itself was inflated. The threat behind it was not, because the blast radius of a disclosure like that is every deployment of the affected software an attacker can find by scanning the open internet for who's still running it.
I’m not the only person who’s seen this, and I think the problems open source maintainers are wrestling with now are the problems other enterprises will encounter very soon. The informal reality of volunteers becomes the operational reality of the entire software world.
On September 11, 2026, something adjacent to what I just described stops being a volunteer's problem and becomes a legal one for a very large number of companies.
The EU Cyber Resilience Act's reporting obligations take effect then: any manufacturer with a product with digital elements sold into the EU has to notify ENISA within 24 hours of learning a vulnerability in that product is being actively exploited, with a fuller report inside 72 hours.
The part of the law that actually mandates how you build and maintain the product, the engineering requirements, starts to apply on December 11, 2027.
That gives us fifteen months of "tell us fast" before the rest of the law requires us to prove that we’ve built things right.
Our CEO, Abby Kearns, wrote about that gap recently: for the length of that runway, the CRA is functionally a visibility requirement, not a security one. I agree! I've lived this part personally: "what shipped, and when did we first know there was a problem with it" is not a question compliance teams are going to be answering for the first time in September.
Every open source maintainer with a disclosure process already answers this question, informally, under pressure, with whatever tooling they cobbled together themselves, because nobody built it for us.
The challenge is knowing what actually shipped
We've collectively watched this scramble before. When the US issued Executive Order 14028 in 2021 and started requiring software bills of materials (SBOMs) from federal vendors, a lot of organizations generated an SBOM the way you'd generate any compliance artifact: once, under deadline pressure, accurate for the exact moment it was produced and stale by the time anyone asked to see it again.
A document generated last March that nobody has touched since doesn't tell you what you're running today. It tells you what you were running in March. The EU CRA is more explicit than that executive order was. Article 13 wants the SBOM current.
That gap is bigger than most teams expect. 98% of applications contain open source components (Black Duck, 2026 Open Source Security and Risk Analysis Report), so nearly every manufacturer selling into the EU has to answer this, not a handful of edge cases.
Manufacturers now have to prove what shipped and when they knew about it, with a legal clock ticking. The industry's own numbers on how long a fix takes to land aren't encouraging either: average time to remediate a high or critical application vulnerability runs about 55 days (Edgescan, 2026 Vulnerability Statistics Report).
The EU CRA enforcement will live in the gap between a 24-hour early warning and 72-hour full notification clock and that remediation baseline (European Commission, Cyber Resilience Act Article 14 reporting obligations).
Organizations close that gap in two ways. Some are building the muscle in house: instrumenting their own pipelines to regenerate SBOMs automatically, standing up a documented vulnerability-handling process with a named owner, treating provenance as a property of the software supply chain you build, not a report you assemble under audit pressure.
Others are deciding that re-deriving provenance for every open source component they consume, across every language ecosystem their teams touch, isn’t a core technical skill, so they consume already-vetted, already-attested components instead so the provenance question is answered before the component ever enters a build.
Both approaches work, but it’s risky to find out in month fourteen of the runway that "we'll be compliant" didn’t have the backing of "we can actually answer the question when asked."

Most teams can only answer 2 of these 5 EU CRA questions. What about yours?
The EU Cyber Resilience Act's reporting clock starts September 11, 2026, and most security and engineering teams can only answer two or three of the five questions regulators will actually ask.
Get the CRA Readiness Assessment security and engineering leaders are using to find their gaps before ENISA does.
Get the Readiness Assessment

Most engineers I talk to want to focus on building great software, not adding deep introspection into their software supply chains.
We built ActiveState's Curated Catalogs to close that gap: open source components across 12 language ecosystems, delivered with immutable, build-time provenance, and remediated against contractual SLAs, 5 business days for critical severity once an upstream fix exists, 10 for high, 30 for the rest.
That complements your existing process, and it removes "who put this in our build, and when" from the list of questions your team has to answer by hand on a 72-hour clock.
I don't know yet how strictly ENISA will enforce the letter of Article 14 in its first year, and I'm skeptical of anyone who tells you they do with confidence. I do know that the 95-item report I described earlier didn't wait for a regulation to force the question. It just asked me, with a deadline and a price tag attached, whether I actually knew what I was running and how fast I could prove it.
The EU CRA is about to ask every manufacturer selling into the EU the same question, at scale, with a clock ticking down to legal enforcement.
Don’t wait for September 11. Pick a product your team shipped 6 months ago, and time how long it takes someone to tell you what's in it and when you first knew about the last critical CVE inside it. If that takes longer than 72 hours, you already have your answer.
Author
Shane Warden, Principal Architect, ActiveState
Shane Warden is Principal Architect at ActiveState, where he has worked for almost seven years. He has been active in open source since the late 1990s and is a practicing maintainer with direct responsibility for his own project's security disclosure process.
Sponsored and written by ActiveState.

ActiveState
Cyber Resilience Act
Cybersecurity
ENISA
European Union
Vulnerability Report

Previous Article
Next Article

Comments have been disabled for this article.

Popular Stories

OpenAI admits it didn't disclose rogue AI wiki hijacking incident

BigBear Microsoft 365 phishing service bypassed MFA at 258 organizations

Over 5,400 hacked sites serve ClickFix payloads stored on the blockchain

Sponsor Posts

CTI Starter Kit + 2026 SANS CTI Survey

Unify ransomware protection and recovery for every client

Find your gaps before an auditor does. Check your EU CRA readiness in 5 questions.

See how attackers exploit passkey enrollment, and why hardware-bound biometrics raise enterprise identity assurance.

Main Sections

News
Webinars
VPN Buyer Guides
SysAdmin Software Guides
Downloads
Virus Removal Guides
Tutorials
Startup Database
Uninstall Database
Glossary

Community

Forums
Forum Rules
Chat

Useful Resources

Welcome Guide
Sitemap

Company

About BleepingComputer
Contact Us
Send us a Tip!
Advertising
Write for BleepingComputer
Social & Feeds
Changelog

Username

Password

Remember Me

Not a member yet? Register Now

Reporter

Help us understand the problem. What is going on with this comment?

Spam

Abusive or Harmful

Inappropriate content

Strong language

Other

Read our posting guidelinese to learn what content is prohibited.

Submitting...
SUBMIT

The upcoming European Union Cyber Resilience Act (CRA) introduces significant reporting obligations for manufacturers regarding their products sold within the EU, fundamentally shifting the focus from vulnerability disclosure to product provenance. This regulation forces organizations to answer the question of what software shipped and when they first became aware of potential issues, creating a challenge that current operational realities do not easily address. The core issue stems from the discrepancy between informal security practices, such as those employed by open source maintainers who manage disclosures under pressure, and the forthcoming legal mandates for demonstrable accountability.

The CRA establishes specific reporting timelines that create an immediate operational tension. Manufacturers must notify ENISA within twenty-four hours of learning about an actively exploited vulnerability, and provide a full report within seventy-two hours. Furthermore, the requirements concerning how products were built and maintained will become legally enforceable starting in December 2027. This creates a critical window—a runway lasting fifteen months—during which regulators demand visibility into the product's history without yet requiring the proof of correct engineering practices. The author notes that for this period, the CRA functions primarily as a visibility requirement rather than a strict security mandate, highlighting the inherent latency between discovering a problem and meeting legal accountability requirements.

A major barrier to compliance is the process of determining what actually shipped and when knowledge was acquired. The concept of a Software Bill of Materials (SBOM), while a necessary tool, has proven problematic; organizations often generate SBOMs under deadline pressure, resulting in artifacts that are accurate only at the moment of creation and rapidly become obsolete. This contrasts with Article 13 of the CRA, which requires these materials to be current. Given that nearly ninety-eight percent of applications incorporate open source components, answering this question is not an edge case but a mandatory requirement for virtually every manufacturer entering the EU market. The enforcement mechanism will reside in assessing the gap between the rapid notification cycles and the actual average time required for remediation, which statistics suggest can be approximately fifty-five days for high or critical application vulnerabilities.

To bridge this substantial gap, organizations must adopt proactive strategies to establish verifiable provenance. One approach involves enhancing internal capabilities by instrumenting software pipelines to automatically regenerate accurate SBOMs and establishing documented processes for handling and owning vulnerability information across the supply chain. Another strategy is a shift in component sourcing: rather than attempting to track every open source dependency themselves, entities can opt to use pre-vetted, already attested components. This allows the provenance question to be answered before any component enters the build process, circumventing the retrospective tracking challenge. Both methods are necessary, but relying solely on hoping for future compliance is insufficient; organizations must assess their current readiness concerning the five core questions regulators will ask by establishing clear visibility into what they shipped and when they first knew about associated risks.