How automation is easing IT’s patching pressure | Daily Reports Online
The disclosure-to-exploit window used to be measured in weeks; for weaponized vulnerabilities, it now runs in hours. Out-of-cycle patches that used to be exceptional have become routine across enterprise environments of meaningful size.
This pattern now has a name. You might have heard it already: the Patch Apocalypse. Sounds a bit dramatic, but the impact warrants the drama.
It describes something measurable — software flaws are being discovered, disclosed and weaponized faster than most patch management programs were built to handle.
VP of Product Management, Ivanti
Several factors are converging at once. Frontier AI models are accelerating vulnerability research — Anthropic’s Project Glasswing and comparable initiatives have produced thousands of high-severity findings in compressed timeframes.
Attackers are using the same class of tooling to reverse-engineer patches far faster than previously thought possible. Public disclosures are arriving on shorter cycles.
For any team responsible for keeping production systems patched, this all translates to a backlog that grows faster than the available maintenance management windows can drain it. And “drain” is the right word here, because that’s also the impact on the team: it’s very, very draining.
This is far from an anecdotal observation. The workforce cost is already visible.
Recent UK data shows what’s happening at the personnel level: 42% of UK IT professionals report high levels of stress from their jobs, and 76% say that stress is affecting their physical and mental health. 30% report difficulty concentrating, 35% report trouble sleeping and 30% report increased anxiety and depression.
Why traditional patching is breaking down
Patch management was built around predictability. Vendor releases on a known schedule. A defined maintenance window. Manual testing in a staging environment. Communication, approval, deployment, verification.
The model worked when most enterprise software was released on predictable monthly or quarterly schedules, when threat actors needed weeks to weaponize a disclosed CVE, and when out-of-cycle patches were rare enough that a program could absorb them without restructuring. When those scenarios change, the model’s validity changes.
Two structural changes have done most of the work:
Volume is the first. When a single AI model can autonomously surface thousands of high-severity vulnerabilities across major operating systems and browsers — as Project Glasswing did within weeks of its April launch — the downstream effect is more CVEs arriving sooner, with public patches available, all flowing into the same backlog the IT team was already trying to clear.
Velocity has compounded that. Attackers have access to the same class of capability. Patches can be reverse-engineered in as little as 72 hours, sometimes far less. Any system unpatched in that window is exposed to working exploits.
Combine the two, and a patch program that was already running near capacity has to absorb a step change in volume, with shorter deadlines and less predictability about when the next critical disclosure will land. That’s a lot of pressure, and it’s what’s driving the stress data up.
Automation is taking center stage
As an operating model, automation is far better-equipped to survive a Patch Apocalypse than previous iterations. Three important principles underscore the model’s efficacy:
1. Continuous, risk-based triage. The CISA Known Exploited Vulnerabilities list is the non-negotiable top tier. An Exploit Prediction Scoring System threshold appropriate to the environment can drive priority for everything else. Below that threshold, work waits for the maintenance ring.
2. Automated test and deployment rings. The test cycle has to compress to fit the exploit window. Even with top-tier skills and best intentions, a human checklist cannot move at that speed. The familiar sequence — test ring, early-adopter ring, broad production, mission-critical — has to be instrumented and capable of running without manual coordination at every stage.
3. Closed-loop verification. A patch isn’t deployed until the install is confirmed on every endpoint, and a CVE isn’t closed until a rescan confirms it. Compliance evidence is produced as a byproduct of the workflow, not assembled from a spreadsheet the week before an audit.
Industry data points in the same direction. 67% of IT professionals say AI tools and automation will free up their time for more interesting, fulfilling work. 66% say the same tools will help them provide better service to end users. Less than one in three organizations report having fully embedded automation in their IT workflows.
Who’s paying the cost
Any cost considerations regarding patch programs need to take the human cost into account. A patch program running on legacy assumptions will absorb the Patch Apocalypse by burning out the team running it. The stress figures are showing the early signs. The downstream cost includes attrition, error rates, lost productivity and the slow erosion of the institutional knowledge that holds a program together.
On the other hand, programs where automation runs the workflow have the potential to absorb the same volume without requiring the team to absorb it personally. Continuous prioritization, instrumented rings and verification embedded in the workflow take variable, manual work out of the critical path.
Two-thirds of IT professionals see AI and automation as a route to better work — fewer frantic escalations and more time on the problems that need human judgement.
The Patch Apocalypse is very much here, and is poised to reach every program. Is the workflow underneath built to absorb the impact? If not, consider the whole scope of what — and who — is at stake.
We’ve reviewed and ranked the best endpoint protection software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here:
