Same goals, different clocks: What Red Hat’s 2025 Risk Report reveals about global compliance gaps

In April 2026, Red Hat’s Product Security team published its annual Risk Report . I encourage everyone involved in building, shipping, securing, or regulating software to read it–not just for the vulnerability counts, but for what the data collectively says about the modern security environment we’re all operating in.

Here’s the short version: 3,781 security advisories were issued in 2025, an almost linear upward trend year over year. Software supply chain attacks increased 54% compared to 2024. We tracked active exploitation of vulnerabilities that were first disclosed years earlier—including a Linux kernel flaw from 2021 that only appeared in CISA’s Known Exploited Vulnerabilities catalog in October 2025. Attribution for the vast majority of supply chain attacks? Unknown. Eighty-eight percent of incidents left no definitive fingerprints.

This isn't just a Red Hat story, it’s something that applies across the entire industry. Every organization building and shipping software operates in this environment, and the data makes a compelling case that the regulatory pressure we’re seeing globally isn’t overreach, it's a response to a measurable reality.

The wave of security regulation we’re seeing represents a strong and widespread response to emerging threat data, including:

• The European Union’s (EU) NIS2 and Cyber Resilience Act (CRA)

• The US Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA)

• National frameworks across Asia-Pacific, such as Singapore’s Cybersecurity Act and India's DPDP Act

• In the Americas, Canada's OSFI I-CRT Framework and Brazil's LGPD proactive enforcement resolutions 

But the risk report data also prompted a question I’ve been working through in my thinking about compliance program design: if the major security frameworks around the world share the same fundamental goals, why does operating across multiple regulatory jurisdictions create so much more friction than that shared purpose should suggest? Cyber crime is a global problem so additional friction for the good guys just helps the bad guys. 

The answer, I think, isn’t in the goals. It’s largely in the clocks—the specific legal definitions that determine when an obligation takes effect, how awareness is measured, and what evidence counts as sufficient. Frameworks that agree almost entirely on the destination frequently disagree on the departure time. And those misaligned clocks quietly force organizations into what I’d call "compliance forks"—parallel programs, parallel infrastructure, and parallel documentation all pointed at the same security outcome but running on different regulatory timers depending on the jurisdiction. 

CRA, with its newly introduced Single Reporting Platform (SRP), coming into effect on September 11, 2026 is the most current and prominent example of where this plays out. Two specific trigger divergences are worth examining, not as a critique of the regulation’s intent, but as a practical question about how global compliance frameworks can work better together.

The timer trap

CRA’s reporting obligations begin September 11, 2026, well before the regulation takes full effect on 11 December 2027. From that date, manufacturers must file an initial "early warning" to the European Union Agency for Cybersecurity (ENISA) within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a fuller notification within 72 hours, and a final report within 14 days.

That first 24-hour trigger is part of a broader EU pattern: The tiered early-warning model runs across EU frameworks. The EU’s Network and Information Security Directive (NIS2) also requires a 24-hour early warning, but it’s triggered by awareness of a significant incident—one that meets an impact threshold, such as several operational disruptions or considerable damage. The Digital Operational Resilience Act (DORA) requires initial notification within 4 hours, but from the moment of formal classification as a major incident, not from detection. CRA’s 24-hour early warning for actively exploited vulnerabilities is the most aggressive of these triggers. All of them sit against a different  global standard—most organizations already operate under a 72-hour framework anchored to confirmed awareness.

Same goal: timely, accurate incident reporting. Different clocks. And more than that, each clock has a different definition of what starts the countdown. The regulators have taken note of how this operational friction burdens legitimate actors. In response, the European Union has introduced the recent "omnibus" measures, which aim to mitigate these specific challenges. 

The established frameworks anchor the clock to confirmed awareness—you’ve determined something bad happened. The EU early warning model triggers from the moment you become aware of a potentially exploited vulnerability. In a real security operations environment, that often means the moment an alert fires. That’s likely before triage is complete, before verification, and before you know whether it’s a false positive, a minor probe, or a serious incident in progress. 

The 24-hour reporting trigger creates a burden on the global open source ecosystem, which most information technology depends on, and where the trigger's application varies for open source software stewards. While manufacturers must continuously monitor for vulnerabilities throughout a product’s lifecycle, open source software stewards are only required to report actively exploited vulnerabilities to the extent they are involved in software development, and severe incidents affecting the infrastructure they provide. Because a steward’s scope of development or support is often not formally defined with upstream maintainers, Red Hat is leading efforts in communities like the Open Source Security Foundation (OpenSSF) and the Eclipse Open Regulatory Compliance (ORC) to help collaboratively shape security best practices and define standards, helping open source projects achieve the highest levels of quality, safety, and widespread industry adoption, while adhering to the CRA vulnerability management principles.

The Red Hat Risk Report illustrates how complex that determination actually is in practice. In 2025, the average time from public disclosure to a first fix for a "Critical" vulnerability was 12 days, and that’s with 25 years of mature process and a world-class product security team. For "Important" vulnerabilities, the average was 24 days. These aren't failures—they reflect the genuine complexity of validating fixes, coordinating across upstream projects, and testing before release. Determining whether a vulnerability is being actively exploited is similarly complex work that can't be done in hours. 

The attribution picture makes this even clearer. Of the 6 Linux kernel vulnerabilities added to CISA’s Known Exploited Vulnerabilities catalog in 2025, 5 were originally disclosed in prior years and only confirmed as exploited much later. One of them was CVE-2021-22555, a Netfilter subsystem flaw first disclosed in 2021, which only appeared in the KEV catalog in October 2025–4 years after initial disclosure. 

When does the 24-hour clock start on a vulnerability that was publicly disclosed in 2021 but only confirmed as actively exploited 4 years later? CRA’s implementation guidance will need to answer that, and the answer matters significantly for any manufacturer actively monitoring their threat landscape. The stakes around the definitional gap are intensifying: Anthropic’s Mythos model recently identified 3,900 high- or critical-severity open source vulnerabilities in a single research effort, demonstrating that AI is compressing the window between “publicly disclosed” and “actively exploited” in ways the existing trigger definitions were not designed to handle. 

This isn't a hypothetical edge case, it's the normal state of threat intelligence. A reporting framework anchored to confirmed impact gives organizations the verification window needed to file accurate, actionable reports rather than preliminary alerts that may prove to be noise. That’s not a lower standard, it’s a more useful one for regulators and defenders alike. 

Talking to our industry peers, we’ve already noted concerns leaning towards reporting everything right away just to be on “a safe (and compliant) side.” Doing so would overwhelm ENISA itself with a lot of not-yet-confirmed notifications. Defining “awareness” consistently across major frameworks so the reporting clock starts at the same moment everywhere is one of the clearest wins available in global compliance harmonization. That said, we appreciate ENISA’s work to talk to industry experts and provide guidance (covered further, below). 

The patching paradox

The second clock misalignment is less about timers and more about philosophy, but it carries just as much operational weight for any organization that sells products across U.S. and European markets.

Traditional Common Criteria certification validates a specific product at a specific version. By design, it's a snapshot. Patching a certified product can affect the evaluated configuration boundary, potentially requiring assurance maintenance activity or re-evaluation.

The EU’s new Common Criteria-based cybersecurity certification scheme (EUCC), which can serve as a conformity pathway for CRA critical product categories, takes the opposite approach. It introduces mandatory patch management and vulnerability handling as lifecycle requirements. Organizations must demonstrate that you can update the product without breaking its security properties. The obligation is continuous, not static.

Both frameworks build on the same underlying technical standard—ISO/IEC 15408, Common Criteria. The security goals are shared. But their incentive structures point in opposite directions. One rewards holding the codebase still. The other rewards are updating it constantly.

Operating systems, container platforms, and network infrastructure products fall squarely in scope for both. For organizations managing products in these categories, the practical result is overhead: engineering effort is directed at maintaining versions at different lifecycle stages for different compliance contexts, rather than at security improvement. That’s a compliance cost that generates no additional security for consumers. The bad guys are rubbing their hands together in glee.

Why the well-prepared feel this most

Here’s the counterintuitive consequence of misaligned clocks: the organizations most affected are precisely the ones doing the right things.

A company that isn’t tracking active exploitation doesn’t have an ambiguous awareness moment. They simply don’t know when the clock starts. A company that doesn’t patch continuously doesn’t have a certification branching problem, they have a single, static codebase that happens to satisfy the snapshot mode.

Trigger misalignment creates friction proportional to security maturity. The better your threat intelligence, the sooner your reporting clock starts, and the more precisely you need “awareness” defined. The more aggressively you patch, the harder it is to maintain a certification snapshot. 

The regulations were designed to raise the floor, but some of their specific trigger mechanisms inadvertently tax the ceiling.

Same goals. Better clocks.

None of this is an argument against CRA or against regulation in other geos. The Red Hat Risk Report data makes the case for both. A 54% increase in supply chain attacks isn't a problem the industry solves voluntarily at scale. Mandatory transparency obligations, lifecycle security requirements, and accountability for vulnerability handling are the right direction. The report’s own conclusion—that compliance should be a natural outcome of good security engineering, not a separate reactive exercise—is the exact design philosophy CRA aims to institutionalize globally.

According to the 2026 Linux Foundation CRA Awareness and Readiness Report, 66% of companies remain unfamiliar with the CRA and only 41% expect to be fully compliant by December 2027. Additionally, it's estimated that each organization is spending an average of $258,000 in labor costs per release cycle maintaining private versions of software instead of contributing to upstream projects. This general unawareness creates a lot of myths about how to react to vulnerabilities and what to report, creating unnecessary anxiety and budget threats. The regulation doesn’t require manufacturers to patch every vulnerability immediately—obligations are proportionate to risk. 

The Red Hat Product Security Risk Report 2025 data shows why that calibration matters: of 5,478 CVEs tracked last year, only 9 (0.16%) were confirmed as actively exploited in the wild. CRA’s focus on the small subset of vulnerabilities that represent real, present danger is sound design. The structural question isn’t the risk-based remediation framework, it’s making sure the trigger definitions for the reporting clock align with how organizations actually determine which vulnerabilities belong in that high-urgency category.

The request is specific—harmonize the triggers, not just the goals.

The industry is already moving in this direction at scale. IBM and Red Hat’s Lightwell initiative represents a $5 billion commitment to AI-powered vulnerability identification and remediation across the open source ecosystem, which is in part a direct response to the reality that AI models like Anthropic’s Mythos can now surface thousands of vulnerabilities in a single research effort. Red Hat Hardened Images builds a zero-CVE foundation into the enterprise infrastructure at the container layer. The engineering infrastructure to find and fix vulnerabilities faster is being built. The regulatory trigger definitions need to keep pace with how that work actually gets done.

The frameworks that work best across jurisdictions share a design principle—they define outcomes, anchor obligations to verified impact, and allow organizations to demonstrate compliance through evidence that carries weight across systems. That’s the model worth building toward. Align reporting timelines around confirmed impact across EU frameworks, NIS2, DORA, CRA, and their global counterparts. Define “awareness” consistently so the clock starts at the same moment everywhere.

The bad guys (threat actors) don’t have to follow any agreements or moral norms and they don’t adjust their approach based on which regulatory jurisdiction they’re targeting. The best version of global compliance infrastructure is one that doesn’t require defenders to adjust theirs either.

Encouragingly, the EU is already signaling movement on this. ENISA’s welcome approach to Single Reporting Platform (SRP) consolidates incident reporting across NIS2, GDPR, DORA, and other EU frameworks, building on the CRA’s SRP as the foundation. The single entry point intends to restrict reports to basic text entries rather than sensitive exploit data, and strictly banning file uploads to prevent malicious actors from submitting malware to test the system's defenses. Additionally, the platform will be safeguarded by 3 independent layers of security testing. This approach within the EU is the right model. The next step is extending it globally.

What’s next?

If you’re working through CRA readiness or thinking about how your compliance posture holds up across multiple jurisdictions, Red Hat’s CRA hub is a good starting point for understanding our approach. And if you haven’t read the 2025 Red Hat Product Security Risk Report yet, it’s worth the time. Finally, check out our blog on the CRA's impact on open source security and CRA Stewardship Guidelines for Open Source Projects, where we urge the broader industry to unite with us in collaboratively securing and supporting the global open source ecosystem in the new challenging regulatory era. Our CRA team would love to hear from you!