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 is a low percentage, and it did not 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 is still running it. That informal reality of volunteers and open source maintainers is about to become 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 CRA Reporting Clock Starts in September 2026
The EU Cyber Resilience Act’s reporting obligations take effect on September 11, 2026. Any manufacturer with a product with digital elements sold into the European Union must notify ENISA within 24 hours of learning that a vulnerability in that product is being actively exploited. A fuller report must follow 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 the industry fifteen months of “tell us fast” before the rest of the law requires manufacturers to prove that they have built things right.
For the length of that runway, the CRA is functionally a visibility requirement, not a security one. “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 them.
What the CRA Actually Demands of Software Manufacturers
The EU CRA is not a vague aspirational document. Article 13 requires manufacturers to ensure that software bills of materials are current. Article 14 establishes the specific reporting timeline: 24 hours from becoming aware of an actively exploited vulnerability, with a complete report within 72 hours. These are concrete, measurable obligations. The regulation applies broadly to any product with digital elements — hardware and software — that is made available on the EU market. Nearly every company selling software, firmware, or connected devices into the EU falls under its jurisdiction.
The key question the CRA forces every manufacturer to answer is straightforward: what exactly shipped in your product, and when did you first know there was a problem with any component inside it? That question sounds simple. Answering it accurately, under a legal deadline, with data that can withstand regulatory scrutiny, is anything but.
What Does “Actively Exploited” Mean in Practice
One of the most challenging aspects of the CRA’s reporting obligation is determining when a vulnerability qualifies as actively exploited. The regulation does not require a manufacturer to prove exploitation beyond a reasonable doubt. It requires notification when the manufacturer becomes aware that exploitation is occurring. This means that intelligence feeds, CVE monitoring, customer reports, and internal security testing all feed into a decision tree that now carries legal weight. The threshold for reporting is lower than many teams assume. If a security researcher demonstrates a working exploit against your software, and you can confirm it, the 24-hour clock starts. There is no grace period for triage.
The 95-Item Report Problem: Vulnerability Inflation and the Cost of Triage
The 95-item vulnerability report I described is not an anomaly. It represents a growing pattern in the security research ecosystem. Automated scanning tools generate large numbers of potential findings. Researchers bundle them together to create pressure for payment. Even when the vast majority of findings are false positives or low severity, every single one must be investigated. The cost of triage scales with the number of reports, not the number of valid vulnerabilities. Under the CRA, this pattern becomes a legal liability. If even one of those 95 items turns out to be real and actively exploited, the manufacturer has 24 hours to notify ENISA after becoming aware. The clock does not pause while you sort through the noise.
The SBOM Challenge: Knowing What Actually Shipped
The software industry has collectively watched this scramble before. When the US issued Executive Order 14028 in 2021 and started requiring software bills of materials from federal vendors, a lot of organizations generated an SBOM the way you would 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 does not tell you what you are 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. According to the Black Duck 2026 Open Source Security and Risk Analysis Report, 98% of applications contain open source components. Nearly every manufacturer selling into the EU has to answer this question, not just a handful of edge cases. Manufacturers must now prove what shipped and when they knew about it, with a legal clock ticking.
A Featured Snippet: What Is the EU CRA Reporting Requirement
The EU Cyber Resilience Act requires manufacturers of products with digital elements sold into the European Union to notify ENISA within 24 hours of learning that a vulnerability in their product is being actively exploited, with a more detailed report due within 72 hours. This reporting obligation takes effect on September 11, 2026, while the broader engineering and compliance requirements become enforceable on December 11, 2027. The regulation mandates that software bills of materials remain current and that manufacturers maintain documented vulnerability handling processes.
The 55-Day Remediation Reality vs. the 72-Hour Reporting Clock
The industry’s own numbers on how long a fix takes to land are not encouraging for compliance. The average time to remediate a high or critical application vulnerability runs about 55 days, according to the 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. A manufacturer can comply with the reporting obligation by notifying ENISA within 24 hours that a vulnerability exists and is being exploited. That does not mean the vulnerability is fixed. The manufacturer still has to produce a remedy. But the transparency requirement means that every stakeholder knows the clock is running, and the pressure to remediate becomes both public and regulatory.
This gap creates a new kind of risk. If a manufacturer notifies ENISA of an actively exploited vulnerability, they have 72 hours to provide details. Those details will likely include which versions are affected, how the vulnerability works, and what mitigations are available. Attackers read these reports. The window between disclosure and patch availability becomes shorter and more dangerous. Organizations that cannot remediate quickly will face reputational damage, customer churn, and potential enforcement actions, even if they meet the letter of the reporting requirement.
How Organizations Are Closing the Vulnerability Visibility Gap
Organizations that are preparing for the CRA are closing the gap between the reporting clock and the remediation timeline in two principal 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, and treating provenance as a property of the software supply chain they build, not a report they assemble under audit pressure. This approach requires investment in tooling, training, and process engineering. It works best for organizations that have dedicated security teams and mature DevOps practices.
Others are deciding that re-deriving provenance for every open source component they consume, across every language ecosystem their teams touch, is not a core technical skill. They are choosing to consume already vetted, already attested components instead. This approach answers the provenance question before the component ever enters a build. It removes the burden of tracking dependencies across multiple ecosystems and reduces the surface area for vulnerability discovery.
The ActiveState Approach to CRA Compliance
ActiveState has built Curated Catalogs to close the gap: open source components across twelve language ecosystems, delivered with immutable, build time provenance, and remediated against contractual SLAs — five business days for critical severity once an upstream fix exists, ten for high severity, and thirty for the rest. This complements existing internal processes and removes “who put this in our build, and when” from the list of questions a team has to answer by hand on a 72 hour clock. The approach is designed for engineering teams that want to focus on building great software rather than adding deep introspection into their software supply chains.
The Bigger Picture: From Voluntary Disclosure to Legal Obligation
The informal reality of open source maintainers is about to scale into a regulatory framework that covers thousands of companies. For years, maintainers have answered the question of what shipped and when they knew about vulnerabilities using whatever tools they could assemble. Some projects have formal disclosure processes. Many do not. Those that do operate on trust, good faith, and the best efforts of volunteers. The CRA transplants that operational burden into a legal framework with deadlines, reporting requirements, and enforcement mechanisms.
The transition is not seamless. Many of the tools and practices that maintainers use are not designed to produce auditable records suitable for regulatory review. A GPG signed email thread is not a vulnerability management system. A GitHub advisory is not a current SBOM. The CRA does not care about good faith. It cares about documented, verifiable processes and timely notifications. The companies that sell products containing open source software must now answer for the provenance and security posture of every component, and they must do it on a clock.
Practical Advice: Test Yourself Before September 11
No one knows yet how strictly ENISA will enforce the letter of Article 14 in its first year of operation. Anyone who claims certainty on this point is overstating their knowledge. What is knowable is the current state of readiness across the industry. Pick a product your team shipped six months ago. Time how long it takes someone to tell you what is in it and when you first knew about the last critical CVE inside it. If that takes longer than seventy two hours, you already have your answer about whether your organization is prepared for the CRA reporting requirement.
The exercise is revealing because it cuts through abstractions. Most engineering teams believe they know what is in their products. Most compliance teams believe they have the documentation to prove it. The gap between belief and evidence is where enforcement risk lives. The 95 item vulnerability report I described earlier did not wait for a regulation to force the question. It asked me directly, with a deadline and a price tag attached, whether I actually knew what I was running and how fast I could prove it. The difference now is that the question is no longer coming from a single extortionist. It is coming from a regulator with statutory authority and the ability to impose penalties.
The Strategic Implications for Software Supply Chain Security
The CRA represents a fundamental shift in how software security is governed. It moves from voluntary best practices to mandatory legal requirements. It changes the calculus for open source consumption because the legal liability for vulnerabilities in those components rests with the manufacturer who ships them, not the maintainer who wrote them. This shift will likely accelerate consolidation around a smaller set of vetted, curated open source components. It will also drive investment in tooling that can generate and maintain current SBOMs automatically, because manual processes do not scale under regulatory deadlines.
For enterprises that sell into the EU, the CRA is not a compliance exercise to be delegated to a legal team. It is an engineering problem that requires changes to how software is built, tracked, and maintained. The fifteen month runway between the September 2026 reporting deadline and the December 2027 engineering compliance deadline is not a grace period. It is a window of exposure during which the reporting requirements are live but many organizations will not yet have the processes in place to generate the data those reports require. The organizations that use that window to build the infrastructure for visibility will be ready when the full weight of the regulation applies.
The informal reality of volunteers is now the operational reality of the entire software world. The question the CRA asks — what shipped, and when did you know — is the same question that open source maintainers have been answering under pressure for years. The difference is that the answer now carries legal consequences. The organizations that treat this as an engineering challenge rather than a paperwork exercise will be the ones that navigate the transition successfully. The ones that wait to find out how strictly ENISA enforces the rules will learn the answer the hard way, with a clock ticking and an auditor reading their 72 hour report.
