Patching Faster Is Not the Answer: Why Vulnerability Management Needs a Risk-Informed Reset

There is a conversation happening inside security organizations right now that rarely makes it into public discourse. It goes something like this: the volume of vulnerabilities keeps growing, the tools keep finding more, the exploitation window keeps shrinking, and the patching backlog keeps getting longer. And yet, when someone asks whether the organization is more or less exposed than it was last year, nobody has a confident answer.

That conversation is why we formed a workgroup to integrate FAIR-based risk analysis with Continuous Threat Exposure Management (CTEM). We are practitioners, risk professionals, and security leaders who have been living inside this problem. What we have concluded is both sobering and clarifying: the industry's instinctive response to an accelerating threat landscape (i.e., find more, faster, and patch more, faster) will not work. A fundamentally different, multipronged approach is needed; one that:

• prioritizes better, based on understanding the actual exposure (both the technical attack path and to the business) so that effort is focused on business risk reduction;
• makes better use of controls, including both remediations (eliminating a defect) and mitigations (eliminating or reducing the risk without fixing a defect); and
• moves faster by increasing the remediation and mitigation throughput via automation, reduction of manual steps, process improvement, etc.

In this post, we’ll make the case for fusing FAIR and CTEM to address the rapidly evolving business risk we’re all facing.

The Clock Is Already Gone

ZeroDayClock.com tracks a single data point that frames everything else: the median time from vulnerability disclosure to first observed exploit. In 2018, that number was 771 days. By 2023, it had fallen to 6 days. By 2024, it was under 4 hours. By 2025, the majority of exploited vulnerabilities were being weaponized before public disclosure.

Read that again. The sequence that vulnerability management programs are built around (i.e., disclose, notify, patch, remediate) now describes events that, in many cases, happen after exploitation has already begun. The process was designed for a world where defenders had months to respond. That world is gone.

And the trajectory is not stabilizing. The emergence of AI models capable of autonomously discovering and exploiting software vulnerabilities — demonstrated concretely by Anthropic's Claude Mythos Preview and the corresponding defensive program, Project Glasswing — points toward further compression, not relief. ZeroDayClock projects that the median time-to-exploit will be under one hour by the end of 2026. Some in our workgroup suggested this moment might be transitional, a storm to survive before defensive AI catches up. That may be true. But a strategy cannot be built on a hypothesis, and the near-term reality demands a clear-eyed response.

What Our Workgroup Agrees On

Before getting to solutions, we want to be honest about the constraints. These are not problems that will be fixed in the next budget cycle. They are the conditions that any realistic approach has to work within.

Asset inventory will continue to lag. Asset management has been the number one foundational challenge in security for a decade. It is not going to be solved in time to matter here. Organizations will be making risk decisions with incomplete, partially stale information about what they own, where it lives, who owns it, and how critical it is.

Patch management will not keep pace. This is a nuanced point. Mature organizations are actually reasonably good at pushing patches at scale for standard systems such as desktops and service operating systems, which often get updated almost automatically. The real problem is more specific: determining which scanner findings are actually applicable and reliable, managing the small but critical set of systems that cannot be patched blindly, and handling cases where no patch exists or cannot be applied without significant operational risk. Regression fear, change-window constraints, legacy dependencies, and ownership ambiguity mean that even clearly identified vulnerabilities often go unaddressed for weeks or months. And not all vulnerabilities can be patched; end-of-life systems, unsupported software, and embedded components often create permanent exceptions.

Not everything can be fixed, and that is not a failure. This is perhaps the most important mindset shift the industry needs to make. As one workgroup member put it, security teams are stewards of limited resources. Recognizing that and managing accordingly is not negligence. Trying to patch everything indiscriminately when the data needed to prioritize is imperfect leads to wasted effort and misplaced urgency. We must not fix things that don’t matter while leaving more significant exposures unaddressed.

The research burden is often larger than the patching burden. A point that came up forcefully in our workgroup: teams are often not overwhelmed by patching per se. They are overwhelmed by the task of determining which scanner findings are real. An Apache vulnerability flagged on a Red Hat system may not be applicable as reported. An outdated browser version on an unused profile generates a finding but no meaningful risk. The volume of work required to assess applicability, before any patching decision is made, is where many programs are actually breaking down.

Threat intelligence will always lag exploitation. By the time actionable intelligence reaches a security team, exploitation may already be underway for the most time-sensitive findings. This is not an argument against threat intelligence. It is an argument against relying on it as the primary filter.

The Actual Problem: We Do Not Know What Matters Most

Given these constraints, the core challenge is not finding more vulnerabilities or patching faster. The core challenge is knowing which vulnerabilities, in which environments, against which threat actors, with which business consequences, represent the exposures that most deserve attention right now.

That is a risk question, not a scanning question.

The vulnerability management discipline has historically addressed this with severity scores, such as CVSS ratings, that measure the intrinsic exploitability characteristics of a software defect. Those scores are not useless, but they are radically insufficient. They do not tell you whether the asset is reachable by a capable threat actor. They do not tell you whether compensating controls reduce the effective exposure. They do not tell you whether successfully exploiting the vulnerability would produce a $50,000 problem or a $50 million one. And they treat each finding as an independent unit of risk, when in reality an asset with five critical vulnerabilities may see no meaningful risk reduction from patching any one of them, because the remaining four still provide viable attack paths to the same outcome.

That last point deserves emphasis. Risk across multiple vulnerable assets works like a parallel circuit: current takes the path of least resistance. Remediating one path while others remain open may produce precisely zero improvement in the organization's actual exposure. A severity-ranked remediation queue cannot see this. A scenario-level risk analysis can.

What a Risk-Informed Approach Actually Requires

Our workgroup's view, which continues to evolve, is that exposure management should be built around a broader, more precise definition of exposure than "vulnerabilities the scanner found." Exposure is the intersection of four things: a vulnerability, understood as a defect in, or absence of, a control; a specific threat with assessed capability and intent; asset context, including whether the asset is reachable, how critical it is, and who owns it; and business impact, or what it would actually cost the organization if a loss event occurred.

None of those four elements can be derived from a scanner alone. All four are necessary for a prioritization decision that reflects actual risk.

This framing also recognizes that vulnerabilities do not affect risk in a single uniform way. A misconfigured firewall that exposes an asset to a broader threat population primarily affects how often threat actors can reach that asset. An unpatched software defect primarily determines whether a threat actor who reaches the asset succeeds. A defective backup system primarily affects the cost of a successful attack. These are different problems requiring different responses, and a CVSS score cannot distinguish among them.

Perhaps most importantly, a risk-informed approach shifts the question from "which CVEs do we patch first" to "what underlying control failures are generating the most exposure across our portfolio, and what is the highest-leverage fix?" A platform that is end-of-life across hundreds of systems is not a collection of individual CVEs. It is a single root cause producing exposure across a large set of scenarios. Addressing it at the source — upgrading the platform — collapses exposure across every affected scenario simultaneously, at a fraction of the effort required to chase the individual findings it generates.

Connecting Risk Analysis to Exposure Management Operations

The FAIR+CTEM workgroup is developing a framework that connects FAIR, the international standard for quantitative cyber risk analysis, with Continuous Threat Exposure Management (CTEM) to operationalize this risk-informed approach.

The connection matters because FAIR and CTEM solve different problems. FAIR provides the analytical model: a rigorous, financially grounded way to assess what exposure actually means in terms of probable loss. CTEM provides the operational rhythm: a continuous, business-aligned cycle of scoping, discovery, prioritization, validation, and mobilization. CTEM also represents an evolution of traditional vulnerability management, which (as noted above) focuses on determining the actual exposure level (at least relatively) of each vulnerability instance (e.g., reachable, not otherwise mitigated, validated as exploitable).

The lesson is that FAIR and CTEM should be complementary. CTEM without FAIR during prioritization defaults to severity scores. FAIR without CTEM's operational structure produces an analysis that sits in a risk register rather than driving action.

One of the workgroup's clearest insights (thus far) is that financial quantification, i.e., expressing risk in terms the business understands, is what ultimately makes mobilization possible. As one practitioner in our group described it, when remediation decisions exceed the bounds of normal operations and require senior leadership engagement, the conversation has to happen in dollars. Technical teams speak fluently about what can go wrong. They are often less equipped to say how likely it is to actually happen, and what it would cost when it does. FAIR provides that translation.

Our group also agreed that full financial quantification is not necessary for every finding — that would be neither practical nor necessary. Applied selectively, at the scenario level, and particularly for high-stakes decisions that require organizational mobilization, it provides the language that moves remediation from a security team's backlog into a business decision with funding, authority, and accountability behind it.

What the Workgroup Is Building

The white paper this workgroup is developing will provide practical guidance on how to integrate FAIR-based risk analysis with a CTEM program, from initial scoping driven by existing risk scenarios, through discovery targeted at the right exposure types, to prioritization anchored to financial impact, validation that tests what actually matters, and mobilization supported by the language of risk and consequence.

We are not arguing that this is easy. Asset data will be imperfect. Threat intelligence will lag. Patching will fall short. Those are the conditions on the ground, and any approach that requires solving them first is impractical. What we are arguing is that working with imperfect data, using principled methods to make defensible decisions under uncertainty, and focusing effort on the exposures that most threaten the business, rather than the findings with the highest CVSS scores, is both achievable and necessary.

The exploitation clock is not slowing down. The organizations that navigate this environment best will not be those that respond fastest to everything. They will be those who respond most precisely to the right things.