There’s a number in Google Mandiant’s M-Trends 2026 report that should reorganize how you think about patching: the average time-to-exploit is now minus seven days. Not seven days after a patch ships. Seven days before one publicly exists.
That’s an average. Plenty of vulnerabilities still take longer to weaponize. But averages tell you where the center of gravity sits, and the center of gravity has moved to the wrong side of zero.
How fast it happened
The trajectory matters as much as the number. In 2018, Mandiant put the average time-to-exploit at around 63 days. A vulnerability would be disclosed, and defenders had roughly two months before exploitation became likely: time to inventory affected systems, rank the risk, test the fix, and roll it out.
That window shrank every year. By 2024 it crossed zero, at roughly minus one day: exploitation, on average, arriving just before the patch. The 2025 data puts it at minus seven. Seven years took the window from two months of head start to a week of deficit.
What a negative average actually means
A negative time-to-exploit isn’t attackers reading patches faster. It means the average exploited vulnerability is now a zero-day: weaponized before disclosure, before a fix, before your scanner has a signature for it. Machine-speed discovery and exploit development have compressed the attacker’s timeline below the point where any patch cycle, however disciplined, can get there first.
Which quietly breaks several things most security programs are built on.
It breaks patch-cadence-as-strategy. A monthly patch cycle was a reasonable posture when you had 63 days. Weekly was aggressive. Neither means much against an exploit that predates the patch. This isn’t an argument to stop patching; hygiene still closes the long tail, and the long tail is real. It’s an argument that patching is now maintenance, not defense.
It breaks CVSS-ordered queues. If you can’t fix everything before it’s exploitable, and you can’t, then the entire game is fixing the right things first. A severity score computed with no knowledge of your environment can’t tell you what’s right. The question that ranks work in a negative-TTE world is not “how bad is this bug in theory?” but “can an attacker actually reach this, here, today?”
It breaks point-in-time assurance. A clean assessment is a statement about the day it ran. When the average exploit predates the patch, the material risk is the exposure that appeared after your last look: the new service, the misconfigured bucket, the asset nobody inventoried. An annual snapshot doesn’t just age now; it ages from the moment it’s taken.
It breaks the alert-triage model. Teams already drowning in unvalidated findings don’t get faster by adding feeds. Every hour spent confirming whether a finding is real is an hour inside a window that no longer exists.
What’s left when the race is unwinnable
You can’t patch faster than attackers exploit. What you can do is know, continuously, which of your exposures are actually reachable, and fix those first.
That posture has three requirements, and they’re demanding:
- Continuous discovery. The exposure that hurts you is the one that appeared this week, on an asset you may not have known you had.
- Validation by exploitation. When you can only fix a fraction in time, spending that fraction on theoretical findings is the expensive way to lose; proven reachability is the only ranking signal that holds up.
- Machine speed, human reach. The testing has to run at the pace of the attackers’ discovery. And the surfaces automation can’t safely or cleverly test, like OT and business logic, don’t stop being attack surface.
That’s the argument for continuous, validated testing generally, and it’s the argument Incenter was built on specifically. The fuller version, with the numbers laid against the annual-assessment model, is at why Incenter.
The 63-day window isn’t coming back. The programs that adapt won’t be the ones that patch hardest; they’ll be the ones that stopped guessing which exposures matter.