The 20-Hour Window

In 2018, the mean time between a disclosed vulnerability and confirmed exploitation in the wild was 2.3 years. If you could patch within a few months, you were, statistically, fine.

By 2024 that window had shrunk to 56 days. Tighter, but workable. Most teams could get there with a disciplined patch management program and reasonable SLAs.

In 2025, it dropped to 23 days.

Today, in 2026, we’re at 20 hours.

And that number is already months old. The real figure is likely shorter.

What This Actually Means

Let me be direct: patch management still matters. You should absolutely be patching, driving down your SLAs, and reducing dwell time wherever you can. None of that changes.

But we have crossed a meaningful threshold. Patching can no longer be treated as a primary or even secondary control for managing vulnerability exposure on internet-facing assets. The math simply doesn’t support it. A 20-hour window means that by the time most organizations are aware a patch exists, weaponized exploits are already in active use.

The mindset shift that has to happen is this: assume you have unpatched vulnerabilities on publicly accessible assets with known exploits in the wild. Not occasionally. Constantly.

Your security program needs to be built around that reality.

What “Built Around That Reality” Looks Like

Zero Trust Architecture

Stop treating the perimeter as a trust boundary. Continuously verify identity, enforce least-privilege access, and microsegment your environment so that a compromised asset doesn’t hand an attacker lateral movement across your network. A vulnerability exploited on an edge system should not be a path to your crown jewels.

Advanced WAF and Virtual Patching

Modern web application firewalls can deploy virtual patches within hours of disclosure, buying you time while you test and roll out the real fix. This is one of the most underutilized capabilities I see in mid-market security programs. Organizations spend heavily on scanning tools and comparatively nothing on runtime protection at the edge.

Exploit Prevention and Runtime Protection

Are you actually using the exploit prevention capabilities in your EDR? Memory protection, return-oriented programming (ROP) chain detection, and behavior-based blocking catch exploitation attempts regardless of whether the underlying vulnerability is patched. If your EDR is deployed but tuned to alert-only, you’re leaving a significant control on the table.

Continuous Monitoring and Detection

If you can’t patch before exploitation begins, you need to detect exploitation in real time. That means solid logging from internet-facing systems, tuned detection rules for known exploit patterns, and a SOC or MSSP that is actually watching and responding, not just collecting. Detection is not a checkbox. It’s an operational capability.

Hardening and Attack Surface Reduction

Reduce the attack surface on every internet-facing asset before a vulnerability is ever disclosed. Disable unnecessary services, close unused ports, enforce strict egress filtering, and treat every publicly accessible system as actively targeted. Because at 20 hours, it effectively is.

The Real Question

I’ve been hearing too many conversations lately where patch scanning and SLA reduction are treated as the complete answer to vulnerability management. They’re necessary inputs, not the program itself.

The real question has shifted: what happens in the hours between disclosure and exploitation?

That’s the window your program has to defend now. Detection, containment, virtual patching, and blast radius reduction aren’t advanced security concepts anymore. They’re table stakes.

Build your program accordingly.