When the patch loses the race

Mandiant’s M-Trends 2026 report, grounded in over 500,000 hours of frontline incident investigations conducted in 2025, found that the mean time to exploit had dropped to an estimated -7 days: exploitation is routinely occurring before a patch is even released. This is a finding about the vulnerabilities Mandiant observed being weaponized across its investigations, not a claim about any particular reader’s exposure. It establishes that patch speed, even a perfect patch speed, is no longer sufficient by itself as a control for that class of vulnerability.

CISA’s own posture has moved with the same pressure. In June 2026, the agency issued Binding Operational Directive 26-04, which requires federal civilian agencies to remediate the highest-risk vulnerabilities, those that are publicly exposed, actively exploited, automatable, and capable of total system control, within three days, plus a forensic check of whether the system was already compromised. The directive applies to federal agencies, not the private sector, but the timeline it sets is a useful marker: a three-day remediation window with a built-in assumption that some of what gets patched has already been used. Our own review of CISA’s Known Exploited Vulnerabilities catalog found a live example of that compression: a ConnectWise ScreenConnect vulnerability added on September 11, 2026 with a due date of September 14, three days later.

Our patch-report checklist still holds, and it is not the whole answer

Our guide to what a patch report does and does not prove covers the evidence to ask for: inventory coverage, exploited-vulnerability priority, aging exceptions, ownership, and independent verification. That checklist answers whether the patching process is working as claimed. It does not answer a separate question: what happens during the window when a vulnerability is known, exploited, and not yet patched, however short that window has become or however well the process performs.

Reduce what is reachable, not just what is current

If exploitation can arrive before the fix, the response is not to patch faster than is realistically achievable. It is to reduce how much is exposed to begin with, so that a delayed patch is a smaller problem when it happens. Two of our recent guides describe specific versions of this: our guide to RMM tool allowlisting and default-deny reduces what can run at all, and our guide to edge-equipment ownership reduces what is reachable from the internet in the first place. Both are attack-surface reduction, done before a specific vulnerability is even known, rather than remediation done after.

Ask what would catch a vulnerability that got in ahead of the patch

Since patch timing cannot be the only control for the fastest-moving vulnerabilities, ask what detects unexpected activity on a system regardless of whether it has been patched yet. A patched system with no monitoring and an unpatched system with active monitoring do not carry the same risk, even though a patch report treats them as opposites. Ask your provider what would flag unusual behavior on a critical system in the gap between disclosure and patching, not just how quickly the patch itself gets applied.

A short set of questions

• Which systems are internet-exposed, and could any of them be made not internet-exposed?
• Which running software or remote-access tools on those systems are actually necessary, versus merely present?
• What detects abnormal activity on a critical system independent of patch status?
• When a vulnerability is disclosed for software you run, how quickly would you know whether it was already being exploited before you patched it?

Match the response to what is actually reducible

Not every system can be taken off the internet, and not every tool can be removed. Start with the shortest, most concrete list: the handful of systems and tools where exposure could genuinely be reduced without breaking something the business needs. A smaller attack surface is a standing improvement, not the deferred maintenance a faster patch cycle can substitute for.