A negative exploit window needs a pre-patch control
When exploitation starts before a patch exists, a patch SLA is too late. Give every exposed critical dependency a tested containment action that can run first.
Mandiant's 2026 incident data puts the estimated mean time to exploit at negative seven days. On average, exploitation was already under way before a patch existed.
A faster patch SLA cannot close a window that starts before disclosure. My rule is that every internet-facing critical dependency needs a tested containment action that can run without waiting for the vendor: isolate it, disable the exposed service, restrict the route or replace the dependency temporarily.
Mandiant's negative seven days is a portfolio signal
M-Trends 2026 draws on more than 500,000 hours of Mandiant investigations conducted in 2025. Exploits remained the leading initial infection vector at 32% of intrusions, and estimated mean time to exploit fell to negative seven days.
That does not mean every vulnerability is a zero-day or every disclosed flaw is already weaponised. It is a portfolio-level signal that patch availability can no longer be assumed to begin the defender's clock. For edge devices in particular, Mandiant describes limited telemetry and persistence that can survive ordinary remediation.
ReversingLabs adds a second timing problem. Its September analysis argues that a published patch can localise the changed code for an attacker. That is vendor analysis, not an independent incident dataset, but the mechanism is straightforward: a diff narrows where to look just as defenders begin testing the fix.
A patch SLA needs a companion control
Keep the patch SLA. It still measures a real operational constraint after a fix becomes available. Add a separate field for what happens before that moment.
I would put one control card beside each exposed critical dependency: owner, containment action, trigger, maximum business impact, evidence to preserve and restoration test. The action should be executable from a current runbook, not reconstructed during the incident.
This is editorial judgment, not a Mandiant requirement and not a control I tested against the cited incidents. Google and Mandiant's April 2026 defensive guidance supports the underlying mechanisms: segmentation, identity-based access, continuous asset discovery, limited connectivity and automated, deterministic containment.
The useful acceptance test is deliberately awkward. Assume the vendor says, “No patch yet.” Can the owner identify every exposed instance, apply the containment action, prove the path is blocked, preserve the evidence and restore service without inventing a new plan?
This is different from patch throughput
I have argued before that security agents should be scored on accepted patches rather than exploit trophies, and that vulnerability claims need a CVE ledger. Those are checks on whether discovery became a verified fix.
This is the other side of the timeline. When the fix does not exist, the control is exposure reduction. A team can have excellent patch throughput and still fail this test because its most important appliance cannot be isolated without taking half the business with it.
The number to track is therefore not only mean time to patch. Track the percentage of critical exposed dependencies with a containment action rehearsed in the last quarter, and the measured time to apply and verify it. A stale runbook is not coverage.
What's in it for you
- Turn “wait for the patch” into a named fallback with an owner and trigger.
- Find dependencies whose isolation cost is unacceptable before an incident finds them for you.
- Separate patch throughput from the ability to survive the pre-patch window.
When exploitation can arrive before the fix, containment is part of patch management—not the emergency workaround after it fails.
