Two pieces from a16z put numbers on something most of us in tech ops have been feeling.
The exploit bottleneck has collapsed
RAND’s 2017 study put the median at 22 days for a professional to turn a vulnerability into a working exploit. In the August 2026 PaperCut campaign, a few hundred AI agents on a cheap open-weight model went from an empty workspace to a first real victim in under four hours, using bugs disclosed four days earlier. 395 organizations in 48 countries.
Patching has not moved
The patch half-life for a critical vulnerability was 30 days in 2003 and 30 days in 2008. The 2026 DBIR puts the median time to fully fix a known-exploited bug at 43 days, up from 32.
JPMorganChase’s technology leadership blog post explained why: decision speed and execution speed are different problems. You can decide in hours and still need weeks to find the affected systems, locate owners, test, secure a change window, coordinate suppliers and confirm it landed. Approvals got faster. Execution did not.
What works when the patch won’t arrive in time
So a16z’s second piece asks what works when the patch won’t arrive in time. Their answer, in order of reach:
- Get it off the open internet.
- Segment what has to stay connected.
- Block the attack in the network, at machine speed.
- Remove the bug class entirely (memory-safe code).
Plus two they add alongside: keep a safe manual fallback, and retire what cannot be protected. And the one they say everyone forgets: prove you can recover. Not “we have backups.” The last real restore, how long it took, what came back.
Resilience is a bit like proof of work
You don’t get credit for the plan. You get credit for the run: a recovery capability you exercise regularly, that reflects the live estate, and that is the same thing you invoke when it is real. Show it, don’t assure it.
This is the problem Cutover Recover exists for, so I am talking my book.
Frequently asked questions
How fast can attackers now exploit a vulnerability?
RAND’s 2017 study put the median at 22 days for a professional to turn a vulnerability into a working exploit. In the August 2026 PaperCut campaign, AI agents went from an empty workspace to a first real victim in under four hours.
Why has patching not kept pace?
Decision speed and execution speed are different problems. You can decide in hours and still need weeks to find the affected systems, locate owners, test, secure a change window, coordinate suppliers and confirm the fix landed.
What works when the patch will not arrive in time?
a16z’s answer, in order of reach: get it off the open internet, segment what has to stay connected, block the attack in the network at machine speed, and remove the bug class entirely. Alongside those, keep a safe manual fallback, retire what cannot be protected, and prove you can recover.
What does proving cyber resilience look like?
You get credit for the run, not the plan: a recovery capability you exercise regularly, that reflects the live estate, and that is the same thing you invoke when it is real.
The pieces referenced above
- The Exploit Was the Bottleneck (a16z, Nov 5, 2026)
- Defense in Depth, Rebuilt for Machine Speed (a16z, Nov 6, 2026)
- 200 days into the frontier: What we know and what to do now (JPMorganChase Global Technology Leadership Team, Nov 2, 2026)