Stop optimizing for patch deployment - start optimizing for recovery.

Every organization we talk with wants to patch faster. Few have a tested way to roll back a patch. That imbalance, not deployment throughput, is what decides how exposed an endpoint estate really is.

The numbers that frame this are not subtle. Exploitation of vulnerabilities accounted for 31% of breach initial access in the 2026 Verizon Data Breach Investigations Report, up from 20% the year before and overtaking both phishing and credential abuse for the first time. Over the same period, only 26% of vulnerabilities on the CISA Known Exploited Vulnerabilities catalog were fully remediated, down from 38%. Volume has changed shape too: according to Microsoft's Security Update Guide, June 2026's Patch Tuesday carried 206 CVEs, a record at the time. By September, that record had been broken again, with Microsoft's largest Patch Tuesday release ever recorded at roughly 974 CVEs.

Attackers are getting in through unpatched software more often, defenders are closing less of it, and there is three times as much of it to close. The obvious conclusion is to patch faster. That conclusion is incomplete, and acting on it alone makes most estates slower.

Deployment speed has a ceiling - recovery speed does not.

Ask an endpoint team what is stopping them from patching faster and you will hear the same list: testing capacity, change control, device connectivity, user tolerance for restarts. Every item on that list is real, and no amount of budget removes them. Deployment speed is bounded by things largely outside the endpoint team's control.

Recovery speed is different. How quickly you notice a bad update, how quickly you stop it, and how quickly you reverse it are design properties. They depend on telemetry, on thresholds agreed in advance, on tested reversal paths and on rehearsal. All four are within your control, and none of them requires a new patching product.

This is not an argument for patching slowly. It is the opposite. The organizations deploying fastest are the ones least afraid of a bad patch, because they have proved they can get back out. Teams that cannot reverse an update compensate by testing longer, piloting smaller batches, and deferring more, and end up slower, not safer.

So the first question is not "how quickly can we deploy?" It is "what happens on the day an update breaks something, and how do we know?"

Patching everything was never the model

In the first half of 2026, newly exploited vulnerabilities amounted to about 1.4% of the CVEs published in the same period, down from a peak of 2.7% in late 2023. Against the prior six months, CVE volume grew about 45% while newly exploited volume grew about 10%. The gap between what is disclosed and what is dangerous is widening, not narrowing.

That matters because of how time-to-exploit is reported. Two very different measures are in circulation, and both are correct:

• Aggregate trackers report the fastest observed exploitation in a window. Measured that way, time-to-exploit has collapsed to under a day. This is the figure behind most current industry commentary, including WWT's own work on agentic patching and remediation, and for the tail it describes (internet-facing, automatable, confirmed exploited) it is entirely real.
• The population median reports the typical case across all published vulnerabilities. That figure fell through 2026 too, from 120 days to roughly 80, not to hours.

Design around the first number alone and everything becomes an emergency: you spend the capacity the urgent tail needs on the vast majority of findings that will not be attacked. Design around the second alone and vulnerabilities being exploited today sit in a 30-day queue.

The reconciliation is risk tiering, and it is exposure-based rather than severity-based. CISA's BOD 26-04 takes the same approach, recommending remediation within three days where there is evidence of exploitation, ability to be automated, high technical impact, or public exposure:

A severity score alone cannot place a vulnerability in a tier. A moderate-severity flaw that is being actively exploited against internet-facing systems outranks a critical-severity flaw with negligible exploit likelihood, every time. Prioritization that starts from a CVSS (Common Vulnerability Scoring System) rating spreads effort evenly across findings that do not carry remotely equal risk.

Patch less. Patch better. Then use the recovered capacity on the tail that actually matters.

Five pillars of endpoint remediation maturity

We assess endpoint remediation across five pillars. They are deliberately scoped to the endpoint estate: every platform and every patch class, not just Windows and not just the operating system.

Governance and ownership. One named owner for patching outcomes, distinct from the security function that reports on them. Security sets risk appetite and deadlines; endpoint operations owns method and execution; the boundary is written down. Where the fix belongs to a vendor or an application owner rather than to endpoint operations, that owner is named just as explicitly. Additionally, the emergency path has been tested in the last twelve months. An untested emergency path does not exist.

Coverage and visibility. Every platform first-class: Windows, macOS, iOS and iPadOS, Android, Linux, ChromeOS, virtual desktop images, thin clients. Third-party, line-of-business and internally developed applications inside the same deadline framework as the OS, not in a separate backlog. That includes the ones your endpoint team cannot patch itself. Patch-tool compliance reconciled against independent vulnerability data, with the delta known and explained.

Tooling and telemetry. Prioritization that blends exploitation evidence with asset context. Experience telemetry, covering crash, boot, performance and application health, wired into the deployment decision rather than reviewed afterwards. Reporting that separates deployed, installed, and installed-and-restarted, because a patch nobody has restarted into has not been applied.

Release and rollback. Ring-based release with a first ring that reflects real production diversity, not IT's own laptops. Promotion gated on measured health, with a halt threshold agreed before deployment starts. A tested reversal path for each patch class. Where clean uninstall is impossible, everyone knows in advance that the plan is a restore.

Automation and orchestration. Routine patching running without a human in the loop, verification and retry automated so the last few percent closes itself, and vulnerability operations as a standing capability rather than a project that spins up when a big CVE lands.

Estates rarely score evenly. The most common shape we see is solid governance and coverage on Windows, a measurable gap everywhere else, and a rollback capability that has never been tested.

Someone else's code is still your exposure

Line-of-business and internally developed applications break an assumption the rest of this article makes: that the team accountable for remediation can actually perform the fix. Here it cannot. The vendor ships on its own schedule, the internal development team has its own backlog, and sometimes the application is pinned to a runtime version that patching would break.

So handle them differently. What usually happens instead is that they are not handled at all. They fall off the compliance report, out of the deadline framework, and into a backlog with no owner. Exposure does not care whose queue it sits in. An in-house application running a known-exploited dependency is the same breach as an unpatched operating system, and it is more likely to be reachable from the internet.

The answer is not a lower standard. It is a different owner. These applications need a named remediation owner outside endpoint operations, the same risk tier and deadline as everything else, and a standing item in the review where the rest of the estate is discussed. Endpoint operations reports the finding and tracks it; it should not be marked non-compliant for a fix it has no authority to make. And where the remedy is a vendor upgrade or a development sprint, the decision is commercial rather than technical, which means it belongs in front of someone who can fund it.

The tell is easy to spot. If the applications section of your vulnerability report is longer than the OS section and has not moved in six months, this is not working.

The population most likely to surprise you

If you run virtual desktops, your exposure is set by something most compliance reports do not measure.

A golden image is a patch state frozen in time, and every clone inherits it. Rebuild cadence, not deployment speed, determines how exposed that population is. Which cuts both ways: a non-persistent estate can in principle remediate faster than any physical fleet, because rebuilding the image means the next logon is patched. Very few organizations realize that advantage, because the image pipeline is manual and rebuilds happen quarterly, when someone has time.

Application layers compound it. App Volumes packages, MSIX app attach and similar layers carry their own patch state and sit outside the OS deadline framework in most estates. And most tooling reports the running clone rather than the parent image, so the dashboard describes something other than your actual exposure.

What AI-accelerated discovery changes, and what it does not

AI-assisted vulnerability discovery moved from research into production during 2026. The near-term effect lands on volume and on the tail: more findings reaching disclosure, and a larger share of them reachable and automatable. It does not move the population median, and it does not change the fundamentals above.

What it does change is the cost of a weak foundation. AI-assisted prioritization inherits the quality of your inventory and amplifies its gaps: if you cannot say what software runs where, to a version, faster triage produces faster wrong answers. Automating a reversal path nobody has tested only accelerates the failure.

WWT's enterprise position is agentic patching and remediation: AI in the reasoning layer, deterministic automation for execution, human authority over approvals and exceptions. Our endpoint model is the diagnostic that sits in front of it. Neither recommends letting a model change production unsupervised.

Three moves that need no budget

Reconcile once. Run your patch-tool compliance report and your vulnerability scanner across the same estate in the same week, and put the delta in a single number. That number is your real starting position. It usually surprises people.

Write the halt threshold down. Before your next release, agree the failure rate that stops a rollout and who is authorized to call it. A number and a name, on one page. It is the cheapest resilience you will ever buy.

Test one reversal. Pick the patch class you would least like to reverse, and try it in a controlled way this quarter. Whatever you learn is better learned now than at four o'clock on a Thursday afternoon.

Find out where you stand

WWT's Endpoint Patching Maturity Briefing is a one-hour session covering what has changed in the threat and vendor landscape, a reference model for what good looks like across the five pillars, a walkthrough of how a routine update becomes an incident, and ten questions you can put to your own team the next day. No preparation, no environment access, no commitment.

For organizations that want their own estate graded, the four-hour workshop produces a scored assessment against the five pillars with the evidence behind every grade, a coverage view of every platform against every patch class, including the populations current reporting misses, and three prioritized moves specific to you. We never touch your consoles.

Request the Endpoint Patching Maturity Briefing.

Recovery speed is a design choice. Let's design it.