Two lines are moving in opposite directions. The first is how fast an attacker exploits a vulnerability. The second is the average organization's mean time to remediate. It's going the wrong way.
In the age of AI, that time is collapsing. It's going the wrong way.
Patchmageddon, the July 2026 Eye on the Market paper from J.P. Morgan Asset & Wealth Management's Michael Cembalest, written with JPMorganChase Global CISO Pat Opet and his leadership team, puts numbers on the gap.
The raw numbers:
- Median time to exploitation has fallen from roughly a year in 2021 to a single day in 2026. The Zero Day Clock projects one minute by 2027.
- Almost 80% of exploitations now happen on or before the day of disclosure.
- In 2026, every vulnerability that ends up exploited is exploited within 50 days of disclosure.
None of that describes a failure to know. It describes a failure to execute. That's the line between cyber resilience and cyber recovery.
In March 2026, Opet took the RSAC keynote stage for a fireside chat titled Mean Time to Adapt. In April, JPMorganChase's Global Technology Leadership Team published Fortifying the Enterprise: 10 Actions to Take Now for AI-Ready Cyber Resilience. In July, Cembalest's paper restated all ten actions and backed them with data.
The message is consistent. Everyone building or running software needs to start evaluating speed, not just accuracy, when it comes to keeping systems current.
What actually slows patching down
Patchmageddon includes a chart on this exact question: factors causing major delays in the Linux vulnerability patching process, from TuxCare's Open Source Landscape Report 2026.
Only two of the factors respondents cited are about knowing what to fix. Everything else is about coordinating people, sequencing work, tracking completion, and holding owners accountable.
Patching isn't slow because enterprises lack scanners. It's slow because the work between "patch available" and "patch verified everywhere" runs on goodwill, email, and spreadsheets.
We see the same curve in our own codebase
This isn't abstract for us. The software our customers run their incidents and recoveries on sits on the same open-source supply chain as everyone else's.
We've long taken a broken-windows approach to patching: any release containing a critical or high CVE gets blocked in our pipeline. In 2026 we went further and started blocking PRs to trunk for any CVE, full stop.
We reviewed every commit over the twelve months to June 2026 and classified the maintenance work. A quiet second half of 2025. Then a steady climb through 2026. June was a record month for security fixes.
Most of that work was unplanned and advisory-driven. The only real lever we had was taking the toil out of execution, for one app. Multiply that across the 500 to 5,000 apps in a typical large enterprise, and the problem compounds fast.
Optimize change management for speed
Here's the most uncomfortable stat in the paper: in around 60% of breaches, a patch was already available at the time of compromise.
Why wasn't it applied? The paper answers its own question, over 80% of security professionals have foregone patching to avoid disrupting the business. That's not negligence. That's a rational response to a change process that forces a choice between exposure and uptime.
JPMorganChase's action calls for emergency change pathways that bypass non-essential gates while preserving auditability, and for mean time to patch to be measured and reported as a core operational metric.
Most enterprises hear "fast" and "auditable" as a contradiction. In their environment, it is one. Speed costs them the audit trail. The audit trail costs them speed.
That contradiction only exists when the record is a reconstruction. When the audit trail is generated by execution itself meaning: every task with an owner, a sequence, a timestamp, a status - the fast path and the auditable path stop competing. They follow the same path.
"Just enough process" is the right instinct. But when the process gets abandoned the moment an emergency hits instead of carrying you through it, that's a signal to refine it through better design or automation, not more documentation.
Cutover learned this on disaster recovery before incident response. A decade of orchestrating recovery for the world's largest financial institutions produced roughly 50% faster recovery times by running the work, not documenting it afterward. The same logic applies to the patch and change lifecycle.
Are we patched?
Four in five CIOs and CISOs have been surprised to discover a patch they believed was fully deployed hadn't reached every device.
These are organizations with mature vulnerability management programs, asset inventories, and reporting. They processed the change. They closed the ticket. The dashboard went green. The change still didn't land everywhere.
That's a verification gap, and no policy fix closes it. A ticket records an intention. A log records an event. Neither records execution - which task, against which target, by whom, in what order, done or not done.
Only an execution record answers that question, and it can't be rebuilt afterward from chat history and screenshots.
The same gap shows up after every major incident, when teams spend days reconstructing a timeline that should have written itself. The Dragos 2026 review, cited in the paper, puts it bluntly: in a growing number of operational technology incidents, asset owners declared "not cyber" not because they'd determined it, but because they lacked the data to determine anything at all.
Action: AI agents need somewhere governed to work
Cutover's position: the actor shouldn't change the governance. Humans work in Cutover's UI. Automations use the developer API. External agents execute tasks in a runbook via MCP. Cutover-controlled external agents operate within tasks via AG-UI.
Same task model. Same sequence. Same approval gates. Same timestamped audit trail. Whether the work is done by a human, an automation, or an AI agent.
That's why orchestration complexity rises as agents proliferate, not falls. More actors, more concurrency, higher stakes and a growing need for one independent layer where all of them are governed together.
Action: plans that have never been executed will fail
Patchmageddon ends on this note: organizations need resilience plans for when the patch doesn't arrive in time. Not every vulnerability is patchable and JPMorganChase estimates only 55% to 65% of industrial network hardware can be.
So the response plan has to work.
That means stress-testing incident response and resiliency plans, not just documenting them, and tracking and fixing findings with rigor after every exercise. Add a harder requirement: exercise plans in the same environment you'll respond in. An exercise run somewhere else produces a time signal you can't trust, because the translation step never gets tested.
Findings need to survive as tasks with owners. Not as slides.
What good looks like
A leading global bank ran over 100 live incidents through Cutover Respond in its first year and reported a 28% improvement in Mean Time to Resolution (MTTR). Another global bank cut MTTR by more than 60% with orchestrated runbooks, eliminating recurring handoff errors. Against traditional chat-based responses, the verified range is 28% to 50% faster.
What tomorrow looks like
Accuracy was the old measure: did we patch the right thing, did we follow the process.
Speed is the new one. Opet has given it a name: mean time to adapt. Adaptation isn't a posture or a mindset — it's an interval, measured from the moment a fix exists to the moment it's verifiably in place everywhere it needs to be.
Most enterprises have never measured that interval end to end. The ones that start will find out fast that adaptation is an execution discipline.
See what orchestrated execution looks like: cutover.com/book-a-demo.