Time-to-exploit has collapsed: remediation strategy now lags reality

At a glance

What this is: Pixee argues that vulnerability exploitation is now moving faster than conventional patch programmes, with active weaponisation often arriving within days of disclosure.

Why it matters: For IAM and NHI practitioners, the lesson is that remediation models must account for standing exposure windows, not just patch status, because compromise can precede closure and persist after fixes land.

By the numbers:

• Time-to-exploit has fallen from roughly 32 days in 2024 to 5 days today, according to Pixee.
• 32.1% of vulnerabilities were exploited on or before the day they were publicly disclosed, according to Pixee.
• 50-61% of vulnerabilities had exploit code weaponized within 48 hours, according to Pixee.

Context

Time-to-exploit now defines the real control window for vulnerability management. When adversaries can study patches, weaponize fixes, and compromise systems before many teams finish triage, severity scores and quarterly patch cycles stop being reliable decision tools. The operational problem is not just faster attackers, but slower remediation models built for a different pace of exploitation.

That creates a governance problem for security teams across cloud, infrastructure, and identity-adjacent systems. If compromise can occur before patching finishes, then the control question shifts from whether a system is patched to whether exposure was present long enough for attackers to act and persist. In practice, that means remediation, detection, and containment need to be linked rather than treated as separate workstreams.

Key questions

Q: What breaks when patching is slower than exploit weaponisation?

A: The assumption that remediation will finish before abuse does. When weaponisation happens faster than the patch cycle, exposure reports and backlog management cannot prevent live exploitation. Security teams need a control that can stop attacker-controlled behaviour at execution, because a vulnerability can remain present even after a patch is approved but before it is deployed.

Q: Why do fully patched systems still need compromise hunting?

A: Because a patch only removes the vulnerable condition from that point forward. If attackers exploited the flaw earlier, they may have already established persistence, altered access paths, or planted tooling that survives the fix. Compromise hunting verifies whether the system was owned during the exposure window, which patch status alone cannot show.

Q: How do security teams know whether Teams remediation is working?

A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction. If detection is happening but content stays visible long enough to be clicked, the control is not effective enough. Audit trails should show fast, consistent containment.

Q: When should teams treat a vulnerability as an incident response problem as well as a patching problem?

A: Treat it as both when there is evidence the issue may already have been exploited, when the asset is publicly exposed, or when the impact could include partial or total control of the system. In those cases, patching alone is not enough. Teams need containment, validation, and forensic review before the case is closed.

Technical breakdown

Why patch diffing shortens the exploitation window

Patch diffing is the process of comparing software before and after a fix to identify the changed logic, then using that information to reproduce the vulnerable condition. When release notes, binaries, or firmware updates expose the fix path, attackers no longer need to discover the flaw independently. They can reverse-engineer the patch, isolate the vulnerable code path, and build an exploit from the delta. That is why a published fix can become an attack roadmap within hours, especially for high-value targets where public updates are monitored continuously.

Practical implication: Treat patch release as exposure disclosure and accelerate detection on newly fixed assets immediately.

Why fully patched systems can still be compromised

A patch closes a vulnerability only from the point it is applied. If an attacker exploited the flaw before remediation completed, they may already have established persistence, planted backdoors, or altered access paths. That means patching and compromise removal are different problems. The article’s Fortinet example shows this clearly: emergency mitigation was needed after devices remained reachable, which implies remediation must include hunting for post-exploitation artefacts rather than assuming the patch itself removes attacker control.

Practical implication: Pair every urgent patch with compromise hunting and explicit persistence checks on exposed systems.

Why remediation velocity matters more than patch percentage

Patch percentage is a lagging compliance measure. Remediation velocity is the control that matters when exploitation timelines collapse, because it measures how quickly exposure is actually reduced under active threat. When organisations can only clear a fraction of their backlog each month but attackers can weaponize within days, the gap between theoretical control and actual risk keeps widening. The operational model has to prioritise exploitability, exposure scope, and containment speed over raw completion rates.

Practical implication: Rebuild vulnerability reporting around time-to-remediation for active threats rather than fleet-wide patch completion.

Threat narrative

Attacker objective: The attacker objective is to convert a newly disclosed vulnerability into durable access before defenders can finish patching, then retain that access after mitigation.

1. Entry occurs when attackers monitor patch releases, diff the code or firmware changes, and identify the vulnerable condition faster than defenders can complete remediation.
2. Escalation follows when the exploit is weaponized against exposed systems that are still running the vulnerable release or a flawed partial fix.
3. Persistence is established when attackers implant backdoors or other artefacts designed to survive patching, upgrades, and even factory resets.
4. Impact is continued compromise after remediation, because the organisation may believe the issue is closed while attacker access remains in place.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exploitability now outranks severity as the practical decision variable: the gap between disclosure and weaponization has become too short for severity-led queues to protect most environments. CVSS still helps with triage, but it does not tell teams where active adversaries are likely to strike first. Security programmes that continue to optimise for the highest score instead of the most exploitable condition will keep missing the real exposure window. Practitioners should treat exploitability intelligence as the primary remediation signal.

Patch compliance is not a security outcome: a fully patched estate can still be compromised if attackers arrived before the fix or if the fix was incomplete. That is the control failure this article exposes, and it is especially relevant to identity-adjacent systems where access paths can persist independently of version state. The governance assumption that 'patched means clean' has become unsafe. Practitioners should align patching with post-exploitation validation, not with closure reporting.

Time-to-remediation is becoming a core governance metric for cyber resilience: when exploitation windows compress to days, monthly or quarterly cadence reporting loses decision value. The named concept here is remediation lag debt, the accumulated risk created when response speed cannot match exploitation speed. The debt grows fastest where teams measure completion instead of exposure reduction. Practitioners should report how quickly active exposure is closed, not how many tickets are done.

Operational reality now demands converge-and-hunt behaviour: remediation and compromise hunting can no longer be separate functions. If an attacker may already be in place before a patch lands, then containment has to verify both the vulnerability fix and the absence of persistence. That changes incident handling across infrastructure, cloud, and identity-linked platforms. Practitioners should assume patching is a control input, not a conclusion.

From our research library:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Remediation lag debt: organisations now accumulate risk every time patch cadence is slower than exploit cadence, because attackers can convert disclosure into access before routine change windows open. That makes exposure reduction a governance priority, not just an operations metric.

The shift toward exploitability-led remediation means vulnerability teams need tighter coordination with detection and incident response. When a patch is incomplete or arrives after exploitation, the control question becomes whether persistence was removed, not simply whether the package version changed. The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

Identity-linked infrastructure is especially exposed because access paths can outlive the patch itself. When remediation lags, attackers can keep footholds alive through persistence, service access, or other control bypasses that were established before closure. Practitioners should align patch response with validation of who or what still has access after the fix.

For practitioners

• Prioritise by exploitability, not only severity Rank vulnerabilities using active exploitation, public proof-of-concept availability, and asset exposure so the first work goes to what attackers can use now.
• Hunt for compromise after emergency patching Run targeted validation for persistence, backdoors, and changed access paths on systems exposed during the exploit window, even when the vulnerable version is gone.
• Measure remediation velocity for active threats Track the time between disclosure, mitigation, and verified exposure closure for critical vulnerabilities rather than relying on fleet-wide patch completion percentages.
• Separate patching from compromise closure Treat patch application, configuration change, and incident eradication as distinct work items so a fixed system is not mistaken for a clean system.

Key takeaways

• Time-to-exploit has compressed enough that patch compliance no longer tells leaders whether the environment is actually safe.
• The article’s evidence shows both pre-disclosure exploitation and post-patch persistence, which means remediation must include hunting as well as fixing.
• Teams that want better outcomes need to measure exposure closure speed, not just how much of the fleet eventually receives the patch.

Key terms

• Time-to-Exploit: The period between discovery of a vulnerability and its first practical use by an attacker. In AI-assisted attack environments, that period can shrink to the point where human review no longer fits inside the response window, making automation and pre-authorised containment essential.
• Patch diffing: The process of comparing software before and after a fix to infer what changed and where the vulnerable logic may still exist. Attackers use it to accelerate exploitation, especially when they can reuse the same weakness in adjacent code paths or related products.
• Remediation velocity: The speed at which an organisation can move a finding from validation to verified closure. It is a practical measure of security execution, not just detection maturity, and it often depends on asset ownership, change control, and the surrounding access model.
• Post-Exploitation Persistence: The techniques attackers use to remain inside a system after initial compromise, such as scheduled tasks, new accounts, backdoors, or hidden tunnels. Persistence turns a one-time exploit into ongoing access and often precedes lateral movement or data theft.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org resources that connect identity governance to the broader security disciplines your programme depends on.