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, reports that the mean time to exploit vulnerabilities dropped to an estimated -7 days. Mandiant measures time to exploit as the average time taken to exploit a vulnerability before or after a patch is released, and counts zero-days in that average, so a negative figure means that, on average across the vulnerabilities it tracked, exploitation came before the patch. This is a finding about the vulnerabilities Mandiant observed being weaponized across its investigations, not a claim about any particular reader’s exposure. The finding 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 executive branch agencies to remediate the highest-risk vulnerabilities, those that are publicly exposed, listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, automatable by an attacker, and capable of giving total control of the system, within three days, and to carry out a forensic triage of the asset to assess whether it is 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 check for whether the system was used before it was patched. The KEV catalog shows a live example of that compression: a ConnectWise ScreenConnect vulnerability, CVE-2026-84869, added on September 11, 2026 with a due date of September 14, three days later, and marked for forensic triage.

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. The checklist 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. The response 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 patch report ranks a patched, unmonitored system above an unpatched, monitored one. Their real risk can be the other way around. 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 necessary, rather than 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 can be reduced

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 keeps paying off. A faster patch cycle only shortens the window.