The Exploitation Time Collapse

Executive Summary

Patch management has functioned as the cornerstone of enterprise vulnerability programs for three decades. The conceptual foundation is simple: when vendors disclose vulnerabilities, organizations apply patches before attackers can develop working exploits. That window—the time between disclosure and exploitation—provided the operational slack that patch management programs were engineered to fill.

That window has closed. According to Google’s M-Trends 2026 report, the mean time to exploit a vulnerability is now estimated at negative seven days, meaning exploitation is occurring, on average, a full week before patches exist [1]. VulnCheck’s State of Exploitation 2026 analysis found that 28.96% of Known Exploited Vulnerabilities catalogued in 2025 were first exploited on or before the day their CVE was publicly published—an increase from 23.6% the prior year [2]. CrowdStrike’s 2026 Global Threat Report documents a 42% increase in zero-day vulnerabilities exploited prior to public disclosure [3]. Exploitation is no longer racing patches to the finish; in a significant fraction of cases, it crosses the finish line before the race begins.

Meanwhile, enterprise patching timelines have not kept pace. Qualys’s 2026 enterprise remediation benchmark found that the mean time to remediation for complex enterprise applications—Java, .NET, Citrix Workspace App, and comparable systems that require compatibility testing and enforce strict operational continuity requirements—averaged five months and ten days [4]. Even under the most aggressive reasonable interpretation, that figure cannot be reconciled with an exploitation environment measured in days or hours.

This paper examines the mechanics of the exploitation time collapse, traces the structural constraints that prevent enterprise patching cycles from meaningfully compressing, and proposes a post-patch security posture built around the assumption that organizations will routinely operate vulnerable software for extended durations. The core argument is not that patching should be abandoned—it remains essential—but that it must be demoted from its role as the primary preventive control and recognized for what it has become: a resilience measure that eventually reduces exposure, not a prevention mechanism that closes risk before exploitation occurs.

The transition requires organizations to elevate runtime detection, enforce zero trust network architecture, deploy compensating controls as first-line defenses, and establish Vulnerability Operations as a permanent organizational function capable of coordinating response at a speed that patch management alone cannot achieve.

Introduction: A Framework Designed for a Slower World

The enterprise patch management discipline took its modern form in the early 2000s, shaped by a series of incidents that demonstrated the catastrophic consequences of unpatched vulnerabilities. The Slammer worm of January 2003 infected hundreds of thousands of Microsoft SQL Server instances within ten minutes of release—but it exploited a vulnerability for which a patch had been available for six months [5]. The lesson encoded into the industry was actionable and specific: if organizations could deploy patches within thirty days of disclosure, they would close the window that worms and mass exploitation campaigns required to spread. This insight hardened into the CIS Controls patch management benchmark, the NIST patch guidance framework, and dozens of enterprise vulnerability management policies that specify 30-day SLAs for critical findings and 90-day SLAs for high-severity findings [6][7].

Those benchmarks were calibrated to the threat environment of 2005 to 2015, when the mean time from CVE publication to first known exploitation was measured in weeks to months. The 30-day critical SLA made sense in a world where, as longitudinal M-Trends tracking shows, attackers typically needed four to eight weeks to develop working exploits for newly disclosed vulnerabilities [1], and where successful mass exploitation campaigns tended to follow rather than precede patch availability. An organization that could consistently apply critical patches within thirty days was, statistically, applying them before the majority of exploitation attempts.

That world no longer exists. The acceleration of exploit development—driven initially by the professionalization of offensive security research, expanded by the commoditization of exploit frameworks like Metasploit, and dramatically amplified in the past two years by AI-assisted vulnerability analysis—has compressed the time from CVE publication to working public exploit from weeks to days, and in a growing number of cases to hours or less. The 30-day critical SLA, once a reasonable approximation of adequate response, is now a target that routinely fails to prevent exploitation. And the 90-day high-severity SLA, which was already a conservative figure in its original context, has become operationally disconnected from the exploitation timeline for most categories of vulnerability.

Understanding why patch management frameworks can no longer serve their original purpose requires examining two parallel phenomena. The first is the exploitation timeline itself—how rapidly the window between disclosure and exploitation has collapsed, and why that collapse is likely structural rather than temporary. The second is the enterprise patching environment—the genuine operational constraints that prevent organizations from compressing patch deployment timelines below a floor that remains well above the current exploitation window. Both phenomena are real, both are accelerating in the same adverse direction, and both must be understood to design a security posture that functions in their presence.

The Collapse of the Exploitation Window

The Math Has Inverted

The evolution of exploitation timelines over the past decade represents one of the most significant structural changes in the threat landscape. Longitudinal tracking by Mandiant, which maintains one of the most comprehensive datasets of exploitation activity across its incident response practice, shows a consistent and accelerating trend. The mean time to exploit a disclosed vulnerability—the mean elapsed time between public CVE disclosure and confirmed exploitation in the wild—has declined from approximately 63 days in 2018 to a figure that crossed zero in 2024 and was estimated at negative seven days in M-Trends 2026 [1].

A negative mean time to exploit requires some unpacking. It does not mean that every vulnerability is exploited before its patch is released. Rather, the distribution of exploitation timelines has shifted so far toward zero—and so many high-profile vulnerabilities are now being exploited in the zero-day window before public disclosure—that the mean of the distribution has inverted. The practical implication is that for the class of vulnerabilities that attract serious attacker attention, which are precisely the vulnerabilities enterprise patch programs prioritize, the patch-before-exploit model is no longer statistically viable.

This inversion is corroborated by multiple independent measurement frameworks. VulnCheck’s 2026 analysis tracked 884 entries from the CISA Known Exploited Vulnerabilities catalog [12] with confirmed first-time exploitation evidence in 2025. Of those, 28.96% were exploited on or before the date their CVE was published [2]. That figure is not a rounding error or a measurement artifact; it represents roughly one in three of the most consequential vulnerabilities of the year being actively exploited before defenders received the minimum signal—a CVE ID—required to begin patch prioritization. CrowdStrike’s parallel finding of a 42% year-over-year increase in zero-day exploitation prior to public disclosure confirms the directionality of the trend across a different measurement methodology [3].

The N-Day Reality

Vulnerabilities exploited before disclosure—true zero-days—represent the most dramatic expression of the problem, but they are not the only dimension of the collapse. The complementary problem is the fate of vulnerabilities that are disclosed with patches available, but where those patches require extended testing cycles before deployment. These are called N-days in the practitioner literature: vulnerabilities for which a patch exists but has not yet been deployed. In the traditional model, N-days were understood to be less dangerous than zero-days because the patch was available; defenders simply needed to deploy it quickly.

That distinction has become nearly meaningless at current exploitation timescales. When a vendor publishes a security advisory alongside a patch, adversaries with automated scanning and exploit-generation pipelines can test the patch to identify what changed, engineer an exploit that targets the patched condition, and—in documented cases—have that exploit in active use against unpatched systems within hours. This process—patch-diffing followed by rapid weaponization—means that the publication of a patch simultaneously serves as a public advertisement of the vulnerability’s exploitable mechanics. Every day an enterprise system remains unpatched after a patch’s publication is a day in which that organization is exposed to exploitation by actors who read the same advisory their defenders did.

CrowdStrike’s 2026 data documents that the average time between an adversary’s initial access to a compromised environment and its first lateral movement—the “eCrime breakout time”—was 29 minutes, with the fastest recorded case completing in 27 seconds [3]. This figure is relevant to the patching discussion because it quantifies how quickly an attacker can convert a single successful exploitation into broad network access. Once a successful exploitation occurs against an unpatched system, the time available before broad compromise is measured in minutes, not days—which is why the post-patch architecture must include detection at the same timescale. Organizations that tolerate unpatched windows measured in weeks or months are not simply accepting elevated exposure on that specific system; they are accepting the possibility that a single successful exploitation will, within half an hour on average, become a multi-system compromise from which recovery is far more costly and time-consuming than patching would have been.

The Compression Is Accelerating, Not Stabilizing

Nothing in the current trend line suggests that the exploitation window will stabilize or reverse. CrowdStrike documented a 65% reduction in average eCrime breakout time between 2024 and 2025 [3]—attackers are moving 65% faster from initial access to lateral movement than they were the prior year. VulnCheck’s year-over-year comparison shows the percentage of vulnerabilities exploited before disclosure rising from 23.6% to 28.96% [2]. The forces driving this acceleration—described in detail in the following section—are structural rather than cyclical, and they are intensifying. Organizations that calibrate their patch management programs to the exploitation environment of 2022 or 2024 are already fighting a past war.

The Structural Constraints of Enterprise Patching

Why Faster Patching Alone Cannot Close the Gap

If the exploitation window now measures hours to days for the most critical vulnerabilities, why do enterprise patching cycles continue to measure weeks to months? The answer is not primarily a failure of organizational discipline or prioritization, though those factors exist. The answer is that enterprise patching operates under genuine structural constraints that impose a floor on remediation timelines, and that floor is unlikely to fall below days for the most complex systems regardless of how urgently organizations prioritize the work.

The first and most significant constraint is compatibility testing. Enterprise environments are not homogeneous systems that can be patched atomically; they are ecosystems of interdependent applications, middleware layers, custom integrations, and vendor-certified configurations that can behave unpredictably after a security update alters the underlying platform. A patch to the Java runtime, the .NET framework, or the Citrix Workspace App—all cited in Qualys’s remediation benchmark as contributors to the five-month-plus average MTTR—must be tested against the organization’s application portfolio before deployment [4]. In environments with hundreds of business-critical applications, that testing cycle takes weeks even when conducted aggressively. Organizations that shortcut this process risk patch-induced outages that can exceed the business impact of the vulnerabilities they were trying to close.

Change Management and Operational Continuity

The second structural constraint is change management. Enterprises operating in regulated industries, or those running infrastructure that supports continuous business operations, govern system modifications through formal change management processes. A change advisory board review, a maintenance window, a staged deployment with rollback capability, and a post-deployment monitoring period are not bureaucratic inefficiencies; they are rational risk management practices for systems where an unplanned outage has financial and operational consequences measured in tens or hundreds of thousands of dollars per hour. These processes impose minimum timelines that do not compress easily even when urgency is clear and organizational will is strong.

Qualys’s 2026 benchmark illustrates the outcome of these dynamics in measured form: across complex enterprise applications, the mean time to remediation is 5 months and 10 days [4]. This is not a figure derived from organizations that are negligent about patching; it is a figure derived from the largest patch deployment dataset in the industry, reflecting what actually happens when real-world operational constraints are applied to real-world systems. The 40 million of the 150 million patches tracked by Qualys that were deployed autonomously—without human intervention—were overwhelmingly routine, low-risk updates to commodity software like web browsers and runtime components, not the complex enterprise application patches where the MTTR problem is most acute [4].

Regulated Industry and Vendor Certification Constraints

A third category of constraint affects organizations in industries subject to regulatory oversight of system changes—healthcare, financial services, critical infrastructure, defense—where patches to certified configurations must go through vendor re-certification or regulatory approval processes before deployment. In these environments, the limiting factor is not the organization’s own testing capacity but the cadence of vendor certification cycles, which operate on timescales of months regardless of the severity of the underlying vulnerability. An organization running medical imaging software, a trading platform, or an industrial control system may have a fully tested, approved patch in hand and still be unable to deploy it because the vendor has not yet re-certified the patched configuration for production use.

The Complexity Tax

All of these constraints share a common characteristic: they scale with system complexity. A web browser can be patched in seconds via automated push deployment. An enterprise ERP system requires weeks of regression testing, change management review, staged deployment, and post-deployment validation. The systems that carry the longest MTTR figures are precisely the systems that house the most sensitive data and execute the most consequential business processes—the systems that adversaries have the strongest incentive to target.

This is the fundamental irony of the complexity tax: the systems most valuable to attackers are the systems where patching is most operationally constrained, and where the gap between exploitation capability and remediation capacity is widest. A security strategy built primarily around patching cannot efficiently close this gap, because the same properties that make these systems difficult to patch also make them attractive targets.

AI as an Exploitation Accelerant

The Research Landscape

The academic study of AI-assisted vulnerability exploitation has moved rapidly from theoretical proof-of-concept to production-ready capability in the span of approximately two years. In a landmark 2024 study, Fang and colleagues demonstrated that GPT-4, given only a CVE description and publicly available documentation, could autonomously exploit 87% of tested one-day vulnerabilities across a curated test set of 15 vulnerabilities selected for their documentation quality—while every other AI model tested achieved 0% [8]. The significance of this finding was not only the success rate but the automation: the GPT-4 agent required no human guidance beyond the initial CVE description, and the exploit generation required no manual step between disclosure and working proof-of-concept. At 2024 API pricing, this capability could be exercised for approximately $8.80 per successful exploit—a cost that has continued to decline as AI inference pricing has fallen.

That figure—the cost to autonomously develop a working exploit from a public CVE—represents a fundamental disruption of the economics of exploit development. Before AI-assisted pipelines, developing a reliable exploit for a complex vulnerability required hours to days of work from a skilled security researcher, limiting the number of CVEs that could realistically be weaponized in a short timeframe and providing defenders some natural advantage through scarcity of attacker resources. When the cost falls to single-digit dollars per vulnerability and the timeline falls to minutes, that natural advantage disappears entirely.

The Industrial Scale of AI-Assisted Offense

The Fang et al. research established that AI could exploit individual vulnerabilities. Subsequent work has demonstrated exploitation at industrial scale. The DARPA AI Cyber Challenge, which concluded in 2025, produced seven finalist AI systems that collectively patched 43 of 54 synthetic vulnerabilities across more than 54 million lines of code—and discovered 18 previously unknown real-world flaws in the same codebase [9]. CSA’s AI Vulnerability Storm position paper, published in April 2026 and drawing on primary research conducted with Anthropic and Mozilla, documents that the Mythos model generated 181 working Firefox exploits in a single session, compared to 2 exploits produced under the same conditions by Claude Opus 4.6 [10]. In a parallel defensive engagement, Mozilla applied the same Mythos capability to Firefox and identified 271 vulnerabilities, three of which warranted CVE assignment [10]. These figures describe a capability that has moved from research demonstration to operational deployment by well-resourced threat actors.

The implications for the exploitation-patching gap are direct. AI-assisted exploit pipelines allow adversaries to convert CVE publications—each of which now arrives as a detailed technical description of a vulnerability’s mechanics—into working exploits at a speed that was operationally impossible before 2024. The publication of a patch is simultaneously the publication of an exploit template, and the time required to convert that template into a working weapon is now measured in minutes for AI-capable actors. Every day an organization spends in change management review or compatibility testing after a patch’s release is now a day of exposure to adversaries who received the same advisory and have already finished weaponizing it.

The Economic Asymmetry

The AI-assisted exploitation advantage is not merely technical; it is economic. Defenders bear the full operational cost of patching: testing time, change management overhead, staff time, and downtime risk. These costs scale with system complexity and do not compress in response to urgency. Attackers, by contrast, have been able to dramatically reduce their cost per exploit attempt through automation, while their primary constraint—access to systems to attack—has expanded with the growth of internet-connected infrastructure. The result is a widening gap between attacker operational economics and defender operational economics that AI has made structural rather than cyclical.

CrowdStrike’s 2026 data on breakout times illustrates how this economic advantage translates operationally: adversaries with AI-assisted tooling move from initial access to lateral movement in an average of 29 minutes, with the fastest cases completing in 27 seconds [3]. This is not a pace that any human-governed response process—ticket triage, approval workflows, escalation paths—can match. Organizations that have not pre-authorized containment actions and pre-positioned automated response capabilities are structurally unable to respond within the window that separates initial access from broad compromise.

The Framework Failure: When SLAs Become Fiction

The Mismatch in First Principles

Traditional patch management SLAs are built on an implicit empirical assumption: that the SLA window is shorter than the exploitation window for the class of vulnerabilities to which the SLA applies. A 30-day critical patching SLA is defensible only if critical vulnerabilities are typically not exploited within 30 days of disclosure. A 90-day high-severity SLA is defensible only if high-severity vulnerabilities are typically not exploited within 90 days.

Both of those assumptions have been falsified by current exploitation data. The mean time to exploit is now negative for the highest-priority vulnerability classes. VulnCheck’s analysis of 2025 exploitation activity found that 28.96% of Known Exploited Vulnerabilities were exploited on or before the day of CVE publication—before any patching SLA could possibly be initiated [2]. For the class of vulnerabilities that drive major enterprise security incidents, the 30-day SLA is not merely insufficient; it fails to engage the problem at all, because exploitation has already occurred before the SLA clock starts.

The Compliance Illusion

Organizations that measure their patch management program success by SLA compliance—the percentage of vulnerabilities remediated within the specified window—may be generating accurate compliance metrics that describe an essentially irrelevant quantity. A program that consistently achieves 95% SLA compliance on a 30-day critical patching cycle is demonstrating that 95% of critical patches are deployed within 30 days of disclosure. It is saying nothing about whether those deployments occurred before exploitation, because for a growing fraction of critical vulnerabilities, exploitation happens before the patch window opens.

This compliance illusion creates a governance problem that extends beyond security program design. Boards of directors, audit committees, and regulators who use patch SLA compliance as a proxy for vulnerability risk posture may be receiving signals that accurately reflect process adherence while substantially overstating actual risk reduction. An organization that is 95% compliant with a 30-day SLA and is operating 100% of the time in the post-exploitation window for the most critical vulnerabilities has a security program that passes its own metrics while failing at its fundamental purpose.

The Liability Question

The legal and regulatory implications of the exploitation time collapse are beginning to emerge in enforcement actions and litigation. Regulators have historically accepted patch management SLAs as evidence of reasonable care in vulnerability management. As the exploitation timeline data demonstrating negative MTTE becomes more widely understood, the question of what constitutes a reasonable standard of care will evolve. An organization that relies on a 30-day patching SLA as the centerpiece of its vulnerability management program, in a documented environment where 30% of high-profile vulnerabilities are exploited before disclosure, faces increasing difficulty arguing that such a program reflects current industry knowledge. Legal scholars and practitioners are beginning to ask whether organizations that fail to adopt available AI defensive capabilities face heightened negligence exposure—a question that patching programs calibrated to 2015-era timelines have not yet confronted.

Toward a Post-Patch Security Architecture

Reframing Patching’s Role

The argument of this paper is not that organizations should stop patching. Patching remains essential. Unpatched vulnerabilities accumulate over time, expand the organization’s exploitable attack surface, and eventually contribute to breaches even in organizations with strong detective and responsive controls. The argument is that patching must be recognized for what it has become in the current threat environment: a necessary resilience measure that reduces long-term exposure, not a preventive control that closes risk before exploitation occurs. This reframing has practical consequences for how security programs are designed, funded, and measured.

The primary implication is that security programs cannot rely on the patch gap as the window within which defenses operate. They must assume, by default, that for any significant vulnerability in their environment, active exploitation attempts may occur before the patch is deployed—in many cases before it exists. Every detective, containment, and response capability must be evaluated not against the question “will we patch before exploitation?” but against the question “can we detect, contain, and respond after exploitation, while still running the vulnerable software?” That is a harder problem than traditional patch-centric security, and it requires a materially different architecture.

Runtime Detection as a Primary Control

The most important shift in a post-patch security architecture is the elevation of runtime detection from a supplementary layer to a primary control. This means deploying endpoint detection and response (EDR), network detection and response (NDR), and extended detection and response (XDR) capabilities calibrated not to patching timelines but to exploitation timelines. Detection tools must be able to identify the indicators of post-exploitation activity—lateral movement, credential access, discovery and enumeration, data staging—within the 29-minute average breakout window that current attacker tooling achieves [3].

This calibration requirement has significant implications for detection engineering. A detection rule that takes several days to deploy after a new exploitation technique is documented is not operating within the relevant response window. Organizations that have centralized, automated detection content deployment—where new rules can be tested and pushed to production in hours after a new technique is observed—are positioned to respond to exploitation before adversaries achieve broad compromise. Those that rely on periodic, manually approved detection rule updates are operating at a cadence that is incompatible with the threat environment.

Critically, runtime detection must be paired with pre-authorized containment. If detecting exploitation requires human approval before isolation or blocking actions can be taken, then the detection capability does not operate within the relevant response window regardless of detection speed. Pre-authorized, automatically triggered containment responses—isolating a compromised host, blocking suspicious lateral movement, invalidating credentials showing anomalous usage—compress the response timeline to match the attacker’s operational tempo.

Zero Trust Architecture as a Structural Mitigant

Zero trust network architecture addresses a different dimension of the exploitation time collapse problem. In a network architecture built around perimeter-based trust, a single successful exploitation event can provide an adversary with access to broad network resources, because the compromised system’s position inside the perimeter grants implicit trust to its subsequent network communications. In a zero trust architecture, where every resource request is evaluated against identity, device posture, and behavioral context regardless of network position, the damage from a successful exploitation is contained to the minimal resources accessible to the compromised identity on the specific device at the time of compromise.

Zero trust does not prevent exploitation, but it changes the consequence of exploitation from potentially unlimited lateral access to bounded, policy-governed access. In a threat environment where the 29-minute breakout time means organizations cannot reliably contain attackers through incident response after initial access is achieved, architectural controls that structurally limit what an attacker can do with that access are not optional enhancements—they are primary risk reduction mechanisms.

Continuous Exposure Management

The replacement for traditional patch management metrics is a continuous exposure management discipline that measures actual risk reduction rather than process compliance. Continuous exposure management asks different questions than traditional patch SLA tracking. Instead of measuring whether patches were deployed within the SLA window, it measures the residual exploitability of the organization’s attack surface at any given point in time, accounting for both the presence of unpatched vulnerabilities and the compensating controls in place to limit their exploitability.

Practical continuous exposure management combines several capabilities. Exploit Prediction Scoring System (EPSS) scores, which estimate the probability that a given CVE will be exploited in the wild based on technical and contextual factors, provide a more accurate prioritization signal than CVSS severity scores alone and allow organizations to focus patching urgency on vulnerabilities with the highest exploitation probability rather than the highest theoretical severity [11]. Active attack surface reduction—systematic removal of unused software, services, and exposed interfaces that expand the exploitable footprint without providing business value—reduces the patch workload by reducing the number of components requiring patching. And compensating control verification—regularly confirming that EDR, WAF, IPS, and segmentation controls are functioning and covering the organization’s highest-priority unpatched exposure—provides the actual risk reduction that SLA compliance metrics only approximate.

Vulnerability Operations as an Organizational Function

The AI Vulnerability Storm position paper introduced the concept of Vulnerability Operations (VulnOps) as a permanent organizational function operating at machine speed, distinct from the traditional vulnerability management function that operates at the cadence of scan-patch-verify cycles [10]. VulnOps is relevant to the exploitation time collapse because it addresses the coordination problem that traditional vulnerability management is not designed to solve: when exploitation is occurring before or simultaneous with disclosure, the organization’s response needs to begin before patching is even a viable option.

A VulnOps function with AI-assisted detection of exploitation indicators, pre-authorized containment playbooks, and real-time integration between threat intelligence feeds and defensive control updates can operate within the exploitation window in ways that human-governed patch management processes cannot. This does not require eliminating human decision-making from the response chain; it requires pre-authorizing the decisions that must be made faster than human review allows, and reserving human judgment for the exceptions and escalations that require contextual assessment.

Recommendations

Immediate Actions

Security and risk leaders should begin by auditing the foundational assumptions of their current patch management program against the exploitation timeline data documented in this paper. Specifically, programs should verify whether their current SLA structure—30 days for critical, 90 days for high-severity—was designed with any empirical grounding in historical exploitation timelines, and whether those timelines remain valid. For organizations where the answer is that the SLAs were inherited from prior frameworks without independent calibration, the first priority is establishing a measurement program that tracks the organization’s actual patch deployment timelines against the exploitation timelines for relevant vulnerability classes.

Within the current patching program, risk-based prioritization based on EPSS scores should replace or augment CVSS-only prioritization [11]. CVSS scores measure theoretical severity; EPSS scores measure the probability of observed exploitation in the wild. For the subset of vulnerabilities where exploitation is imminent or active, EPSS-driven escalation outside the normal SLA window—treating the most imminently exploitable vulnerabilities as operational emergencies regardless of their CVSS score—is the correct risk management response.

Near-Term Transformations

In the twelve-month horizon, organizations should re-evaluate their detection and response capabilities against the breakout times documented in current threat reporting. A useful exercise is to run tabletop scenarios in which an adversary achieves initial access on a system running an unpatched known vulnerability and ask: within how many minutes can the organization detect the exploitation, confirm it, and take containment action? If the answer is longer than 30 minutes for a high-value system, the organization is operating outside the window that current adversarial tooling requires to achieve lateral movement.

Organizations should also develop a compensating controls catalog that maps specific vulnerability classes to the detective and preventive controls that reduce their exploitability even in the absence of patches. A critical vulnerability in a web application that cannot be patched within 30 days due to compatibility testing requirements may be mitigated by a WAF rule deployed within hours of the CVE’s publication. A remote code execution vulnerability in an internal service may be mitigated by segmentation rules that prevent external access to the vulnerable port. Compensating controls do not eliminate risk, but they are deployable at a timescale compatible with the exploitation window in ways that patching often is not.

Strategic Posture Shifts

At the strategic level, organizations should invest in zero trust architecture as a structural response to the exploitation time collapse. Zero trust does not accelerate patching, but it structurally limits the consequence of the patching gap by ensuring that a successful exploitation on one system does not automatically grant access to the broader environment. The investment in zero trust is difficult to justify as a patching complement when the exploitation window is measured in months; it becomes essential when the window is measured in minutes to hours.

Organizations should also recognize that patching velocity—while valuable—has a ceiling imposed by operational constraints that cannot be engineered away for complex enterprise systems. The five-month MTTR for complex enterprise applications documented in the Qualys benchmark is not a reflection of inadequate urgency; it is a reflection of the real cost of safe, reliable patch deployment in complex environments [4]. Security programs that set SLA targets below that floor without providing commensurate resources and risk tolerance for patch-induced outages are setting themselves up for compliance theater rather than genuine risk reduction. The correct response to an irreducible patching floor is not to pretend it doesn’t exist; it is to design security programs that operate effectively within the floor’s constraints.

CSA Resource Alignment

This paper’s findings connect directly to several active Cloud Security Alliance research and framework initiatives.

CSA’s AI Control Matrix (AICM) v1.0.3 addresses the intersection of AI capabilities and security controls across multiple domains relevant to the exploitation time collapse. The Threat and Vulnerability Management (TVM) domain within AICM provides a framework for evaluating AI-assisted vulnerability detection and prioritization capabilities, and its controls for autonomous response and continuous monitoring align with the post-patch architecture described in this paper. The Security Logging and Monitoring (LOG) domain’s requirements for detection coverage and response time targets are directly applicable to the runtime detection primacy argument. Organizations implementing AICM controls will find that several TVM requirements implicitly recognize the inadequacy of traditional patch-only vulnerability management and point toward the compensating controls and continuous monitoring posture advocated here.

The CSA MAESTRO threat modeling framework, developed to address AI-specific attack surfaces and the unique risk profile of agentic AI systems, provides complementary guidance for organizations deploying AI-assisted defensive capabilities. MAESTRO’s attention to the trust boundaries, data flow integrity, and privilege escalation risks in AI pipelines is directly relevant to organizations implementing AI-assisted VulnOps functions, where the speed advantages of automation must be balanced against the risk of adversaries manipulating the AI’s threat intelligence inputs or exploit detection logic.

CSA’s AI Vulnerability Storm position paper, published April 2026, provides the strategic context within which this paper’s operational findings sit [10]. The AI Vulnerability Storm paper documents the Mythos-class AI capabilities that have compressed exploit development to hours, the Project Glasswing coordinated disclosure initiative, and the organizational transformations required to operate security programs at machine speed. This paper on the exploitation time collapse provides the empirical grounding—the measurement data on exploitation windows and remediation timelines—that motivates the architectural recommendations in the AI Vulnerability Storm.

The Cloud Security Alliance’s Zero Trust guidance, part of the broader CCM and STAR program ecosystem, provides detailed implementation frameworks for the zero trust architecture recommended in this paper’s post-patch security architecture section. Organizations seeking to implement the structural segmentation and identity-based access controls described here should reference CSA’s Zero Trust Advancement Center publications, which provide cloud-specific implementation guidance that aligns with the risk model described in this paper.

Conclusion

The exploitation time collapse is not a new threat trend that organizations can plan to address in a future roadmap. It is the current state of the exploitation environment, documented by multiple independent measurement frameworks over multiple years, and accelerating in the direction that makes traditional patch management increasingly insufficient as a primary preventive control. The mean time to exploit is negative. The percentage of vulnerabilities exploited before disclosure is rising. The enterprise patching cycle for complex applications averages five months and ten days. These three facts, taken together, describe a structural gap that patching alone cannot close.

The security programs built for the 2010 threat environment—where the patch window was weeks to months, exploitation timelines were measured in the same units, and a disciplined patch management program could reasonably expect to close most risk before exploitation occurred—were well-designed for their era. They are not well-designed for the present. Adapting them requires recognizing that patching remains necessary but has been overtaken by exploitation speed, that runtime detection and automated response must function as primary controls rather than backstops, and that zero trust architecture changes the consequence of the exploitation gap even when the gap itself cannot be closed.

Organizations that make this transition will find that their security programs are more resilient, more accurately measured, and more honestly aligned with the actual risk environment than programs that continue optimizing for a patch-before-exploit model that the threat data has repeatedly falsified. The goal is not to stop patching; the goal is to stop pretending that patching is enough.

References

[1] Google Threat Intelligence / Mandiant. “M-Trends 2026.” Google Cloud Security Blog, 2026.

[2] Garrity, Patrick. “State of Exploitation 2026.” VulnCheck, January 21, 2026.

[3] CrowdStrike. “2026 Global Threat Report.” CrowdStrike, 2026.

[4] Qualys. “Enterprise Patch and Remediation Benchmark 2026.” Qualys Blog, April 20, 2026.

[5] Moore, D., Paxson, V., Savage, S., Shannon, C., Staniford, S., and Weaver, N. “The Spread of the Sapphire/Slammer Worm.” CAIDA, February 2003.

[6] Center for Internet Security. “CIS Controls v8.” CIS, May 2021.

[7] NIST. “SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning.” NIST, April 2022.

[8] Fang, R., Bindu, R., Gupta, A., and Kang, D. “LLM Agents can Autonomously Exploit One-Day Vulnerabilities.” arXiv preprint arXiv:2404.08144, 2024.

[9] DARPA. “AIxCC Final Event Results.” Defense Advanced Research Projects Agency, 2025.

[10] Evron, G., Mogull, R., Lee, R.T., et al. “The ‘AI Vulnerability Storm’.” Cloud Security Alliance, May 1, 2026.

[11] FIRST. “Exploit Prediction Scoring System (EPSS).” Forum of Incident Response and Security Teams, 2025.

[12] CISA. “Known Exploited Vulnerabilities Catalog.” Cybersecurity and Infrastructure Security Agency, continuously updated.