TL;DR: Patching windows are too slow for today's exploit pace, with Mandiant's M-Trends 2026 report estimating mean time to exploit at -7 days, according to Impart, so security teams are increasingly using virtual patching to contain active exposure before permanent remediation lands. The control only works when runtime visibility, testing, and rollback discipline are strong enough to avoid trading exploit risk for production breakage.
At a glance
What this is: This article argues that vulnerability management is being forced to invert its order, using virtual patching to reduce exploit risk before permanent remediation is possible.
Why it matters: IAM and security teams should care because the same runtime control mindset is increasingly relevant wherever exposure windows are shorter than change windows, including NHI, API, and agent-adjacent attack paths.
By the numbers:
- Mandiant's M-Trends 2026 report estimates current mean time to exploit is -7 days.
Context
Vulnerability management still assumes teams can identify a flaw, assign a service-level target, and patch before attackers materially benefit. That model breaks down when exploitation can begin before the fix exists or before production change is safe, which turns the real problem into runtime exposure management rather than simple patch scheduling.
That shift matters beyond classic application security. Where software, APIs, workloads, or non-human identities create fast-moving exposure, teams need a way to contain risk while permanent remediation waits for testing, coordination, or vendor release cycles.
Key questions
Q: What should security teams do first when a vulnerable service cannot be safely patched yet?
A: Start with a runtime mitigation that blocks the observed exploit path, not a broad rule that assumes every instance of the CVE behaves the same. Validate the control in monitor mode against live traffic, confirm it does not break legitimate use, and only then move it into enforcement while engineering finishes the permanent fix.
Q: Why does patching after disclosure often fail against active exploitation?
A: Because disclosure, validation, and production change all take time, while attackers may exploit the weakness before a safe fix is available. When exploit speed outruns remediation, the team needs a compensating control that reduces exposure immediately instead of waiting for the next deployment window.
Q: What are the signs that a virtual patch is too broad?
A: The clearest warning is that the rule stops suspicious traffic but also blocks legitimate requests, creates user-facing errors, or generates a large number of false matches in monitor mode. A good control should be narrow enough to target the exploit pattern and stable enough to survive production traffic.
A: Containment and remediation should run on separate clocks. Security should reduce the immediate attack path through traffic controls, while engineering handles the code fix, testing, and release process. That split avoids forcing production to absorb emergency change every time a vulnerability becomes active.
Technical breakdown
Why patch SLAs fail against active exploitation
Traditional vulnerability SLAs assume defenders can outrun attackers with a scheduled remediation window. When mean time to exploit is shorter than the time to patch, the SLA becomes an administrative target rather than a security barrier. Virtual patching changes the control point from the codebase to the traffic path, letting defenders block the observed exploit pattern while engineering works on the permanent fix. That is why runtime controls matter: they reduce immediate exposure without pretending the underlying flaw is gone. See the Zero-Day and Exploited Vulnerabilities Guide.
Practical implication: Prioritise runtime mitigation for vulnerable services that cannot be patched safely before exposure is already underway.
How Layer 7 visibility turns an abstract CVE into a specific attack pattern
A CVE describes a class of weakness, but effective mitigation depends on how that weakness appears in your own environment. Layer 7 inspection of HTTP and API traffic lets defenders see the request shapes, parameters, and sequences that distinguish exploitation from normal use. That context supports signatures, anomaly rules, and API-aware policy logic that are narrow enough to block malicious behaviour without collapsing legitimate functionality. In practice, the control is not just inspection. It is the translation of observed runtime behaviour into an enforceable response. See the Vulnerability Management Guide.
Practical implication: Instrument application and API traffic so mitigation rules are built from observed exploit behaviour, not generic vulnerability text.
Why virtual patches need testing, versioning, and rollback
A virtual patch that blocks malicious requests but also breaks customer traffic is a failed control, even if it stops exploitation. Teams therefore need monitor-only validation, comparison against legitimate traffic, and the ability to version and roll back policy changes. This is especially important when attackers adapt after the first rule lands. The governance problem is not only whether the rule stops an exploit. It is whether the organisation can prove the rule is safe, auditable, and reversible under production conditions.
Practical implication: Test every runtime mitigation in monitor mode first and require rollback-ready version control before enforcement.
Threat narrative
Attacker objective: The attacker wants to exploit a known weakness before defenders can safely ship a permanent patch.
- Entry occurs when an attacker targets a known vulnerability in a live application before the permanent fix is available or safely deployable.
- Escalation follows when the attacker uses the exposed request path or API behaviour to trigger the vulnerable code path in the specific environment.
- Impact is reduced when a runtime rule blocks the exploit path before the attacker can complete the attack against production systems.
Breaches seen in the wild
- ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.
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
Runtime mitigation is now a core vulnerability governance control, not a backup plan. The article's central point is that patch SLAs cannot be the only defensive measure when exploitation begins before safe remediation. That changes vulnerability management from a deadline problem into a containment problem. Practitioners should treat virtual patching as part of the operational control stack, especially where production change windows are slower than attacker timeframes.
Application runtime visibility is the named concept that separates theory from enforceable protection. The article shows that a CVE alone is too abstract to drive safe mitigation; defenders need request-level evidence from actual traffic to understand what an exploit looks like in their environment. That is the difference between broad blocking and precise enforcement, and it is why runtime context matters for API-heavy and cloud-native estates. Vulnerability Management Guide gives the wider prioritisation and SLA context behind that decision.
Security and engineering must stop sharing one remediation clock. The article argues for separating immediate exposure reduction from permanent code correction, which is the right governance model when change requires testing or coordination. This is especially relevant where workload, API, or non-human identity exposure can be mitigated in traffic before the underlying software change is ready. Practitioners should align security response with runtime containment while engineering owns the durable fix.
Virtual patching validates a broader shift toward response-at-speed in modern vulnerability management. The industry is moving toward controls that can act in hours, not weeks, because the exploit window has already collapsed. That does not eliminate patching, but it does make runtime protection a first-class option for active threats. The practical conclusion is clear: teams need policies that can mitigate first, then verify and remediate without waiting for a perfect deployment moment.
From our research library:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- 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: Vulnerability Management Guide
What this signals
Exploit-time governance: vulnerability management is shifting from patch scheduling to exposure control, because defenders can no longer assume the fix will arrive before exploitation begins. That means runtime protection, monitor-only validation, and rollback-ready enforcement are becoming normal parts of the response model rather than exceptions.
The practical implication is that teams need to measure how quickly they can turn observation into containment, not just how quickly they can approve a ticket. Where applications, APIs, and connected identities expose fast-moving attack paths, the control objective is to narrow the window between discovery and safe mitigation.
Manual remediation remains too slow for this model, and the average time to mitigate a leaked secret is 36 hours, according to the 2024 State of Secrets Management Survey. That figure reinforces the same programme lesson: if exposure moves faster than change, the control has to move closer to runtime.
For practitioners
- Implement monitor-only validation before enforcement Run proposed virtual patch rules against live traffic in observation mode first, then compare matches with legitimate requests before turning on blocking.
- Map each high-risk CVE to an observed request pattern Translate vulnerability descriptions into the specific endpoint, parameter, or request sequence that would indicate exploitation in your environment.
- Version and audit every mitigation rule Keep a record of rule changes, approvals, and rollback steps so production failures can be reversed quickly and reviewed later.
- Separate containment from permanent remediation Assign security to reduce immediate exploitability at the traffic layer while engineering continues the code change, testing, and release process.
Key takeaways
- Virtual patching shifts vulnerability response from a patch-first sequence to a containment-first sequence when exploitation can begin before remediation is safe.
- Runtime visibility is the difference between a generic CVE label and an enforceable control that matches the exploit in your environment.
- The control only works if teams validate it against real traffic, keep rollback options ready, and let engineering finish the permanent fix separately.
Related NHI Mgmt Group resources: Vulnerability Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Patch Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006 — Initial Access; Credential Access | Active exploitation and request-path abuse are the core threat behaviours in the article. |
| Recommendation — Map exploit patterns to initial-access and credential-access techniques so runtime controls target the observed attack path. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | The article is about limiting exposure through compensating controls while remediation is pending. |
| PR.PS-01 — Configuration Management | Virtual patches are policy controls applied to production services and need strong change governance. | |
| Recommendation — Use PR.DS-01 alongside runtime containment to reduce the impact of successful exploitation. Treat mitigation rules as controlled production changes and require auditability before enforcement. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article directly addresses prioritising and mitigating exploitable vulnerabilities faster than traditional patch cycles. |
| Recommendation — Align exposure triage, validation, and mitigation workflows to continuous vulnerability management. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article highlights API-aware runtime controls for vulnerabilities that surface in request handling. |
| Recommendation — Review API enforcement points and block unsafe request patterns that create exploitable misconfiguration windows. | ||
Key terms
- Virtual Patching: Virtual patching is a compensating control that blocks known exploit attempts without changing the vulnerable code itself. It usually sits at the network, gateway or application protection layer and is used to reduce exposure while a permanent software fix is tested and deployed.
- Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
- Monitor-Only Policy: A monitor-only policy records what a control would have blocked without actually enforcing it. Teams use it to validate accuracy against live traffic, reduce false positives, and decide whether a rule is safe enough to activate in production.
- Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control decisions to the wider security programme they run.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org