When you can’t patch: A practical guide to interim mitigation

The median time to fully remediate a CISA KEV vulnerability, a known exploited vulnerability that attackers are already using, is 43 days. Only 26% are fully closed. Between 60% and 70% remain open at day seven, regardless of maturity, investment, or tooling, all according to Verizon's 2026 Data Breach Investigation Report.

These stats make it clear that this is not a detection problem. It is a result of the volume of vulnerabilities colliding with the operational reality of compatibility testing, change approvals, and maintenance windows. Add the complexity of environments built on legacy systems and business-critical production workloads to the mix, and teams are left balancing two equally legitimate goals: reducing security risk and ensuring uptime.

Virtual patching is a practical solution that acts as an interim mitigation between both. Where an actual patch requires compatibility testing, change approval, a maintenance window, and a rollback plan, a virtual patch places an enforcement layer in front of the vulnerable component and blocks the known exploit path without modifying the application code, all while preserving uptime. It buys the organization time to validate and deploy the vendor patch safely.

What it does not do is remove the vulnerable code. Three possible scenarios arise during routine vulnerability management:

• The vendor knows about the vulnerability's presence and has published interim mitigation guidance ahead of or along with the fix. The mitigation works as a supported work-around that blocks the known exploit path until the patch can be tested and applied.
• A zero-day vulnerability for which no official patch is available is present. When the vulnerability and its exploit path are known, the vendor or security providers often publish a virtual patch as interim mitigation.
• If the vulnerability remains completely unknown to defenders, a targeted virtual patch cannot exist. In such cases, what you fall back on is broader hardening policies: least privilege, strict input validation, allowlisting, segmentation, exploit prevention, OS and application hardening, etc. These are proactive controls that should be at the foundation of any security architecture to reduce the overall attack surface, regardless of what your vulnerability management system looks like.

What to do when a vulnerability cannot be immediately patched

Since a virtual patch is a time-bound compensating control and not the closure of the vulnerability, it should be removed when the official patch is applied. This means that virtual patching cannot operate in an apply-once-and-forget model.

The risk of missing the actual patch is real when mitigations are:

• Applied manually
• Recorded in separate tools
• Left without an owner and expiry condition

Chances of the mitigation getting revoked for some reason, either accidentally or manually, are high, leaving the system vulnerable. An automated workflow that orchestrates the remediation workflow addresses this problem.

Today, most virtual patching is either sold at the network traffic layer, through WAFs and IPSs or within an endpoint management system. Wherever it belongs, for the vulnerability to truly close, the workflow needs context. Which interim control needs to be applied and for how long depends on insights like the installed version of the vulnerable component, whether a patch or a mitigation exists, whether the affected component is actually in use, and by whom. Endpoint management tools provide this context.

The workflow should be designed such that:

• The vulnerabilities with an available patch get the patch after usual testing.
• Until the testing process is completed, its virtual patch is applied.
• Those without a patch but with a published virtual patch get the interim mitigation too.
• Those with neither get compensating controls most suitable to mitigate the specific vulnerability: a host firewall rule, a restricted service or feature, hardened configuration, an application control policy, or an updated exploit prevention rule.

When a vulnerability is fixed by applying its patch, it gets closed when the applied policy is deemed stable. But when a virtual patch is applied to a vulnerable component and verified, the vulnerability needs to be retained in an “interim mitigated” state and not closed as a remediated vulnerability.

An owner and a deadline should be assigned for the permanent fix until it is officially closed. This ensures that the escalation path is properly defined.

And when the official patch is available, it should be tested and deployed. Today, this can be made autonomous to reduce the mean time to remediate. The virtual patch should only be rolled back when the vulnerability is confirmed to be closed with the official patch and there are no employee experience-related side effects.

This is a feedback-loop-based automation, where the system learns and corrects its policy based on the outcome. Say that the official patch is tested and rolled out, but the applied patch is not stable; the system measures its impact from endpoint telemetry, learns that the employee experience is affected, and rolls back the patch. Now the vulnerability is still open. So the system applies the virtual patch again until the cause for disruption is identified and fixed.

Handled this way, virtual patching naturally becomes a bridge between detection and permanent remediation.

Unsupported legacy systems are the honest exception, and they should be documented as one: explicit risk acceptance, continuous monitoring, and periodic review, rather than being marked remediated. Read more on the response track for legacy systems here.

Response paths for different vulnerabilities

A 2026 report by Mandiant revealed that the mean time to exploit vulnerabilities dropped to an estimated minus seven days—not seven days after the patch is available, but seven days before it even exists. The time between vulnerability detection and remediation is the attacker's window of advantage. And in a landscape where AI-assisted vulnerability research and exploit development are compressing time to exploit, that window can no longer be measured comfortably in days.

This means your vulnerability management should operate not only quickly but also efficiently. And to achieve this, you need to build intelligent workflows, not speed up your manual processes. The objective is to ensure that every unresolved vulnerability has an active control, an owner, an expiry condition, and a path to permanent remediation.