For most businesses, patching still runs on a monthly rhythm: wait for Patch Tuesday, test for a bit, push the updates, repeat. That cadence made sense when turning a disclosed vulnerability into a working attack took months of specialist effort. It does not make sense anymore. AI has compressed that effort into something closer to a prompt, and the gap between a fix being published and that fix being weaponised is now measured in hours. If your patching depends on a monthly window and a human approval queue, you are holding a door open that attackers now walk through the same day.
This is the fourth post in our series on how AI is reshaping each layer of your security stack, after Zero Trust, EDR, and application control. The full ecosystem overview ties the whole series together.
The numbers are stark. Industry analysis puts the average window between a vulnerability being disclosed and a working exploit appearing at roughly 2.3 years back in 2018. In 2026 that same window is estimated at around 10 hours. In April 2026 Palo Alto’s Unit 42 warned that frontier AI models are enabling autonomous discovery of new flaws, collapsing the window to patch known ones, and moving the industry toward what they bluntly call N-hours instead of N-days. Reverse-engineering a vendor’s patch to find the hole it fixes used to be a craft. Now it is a task you can hand to a model.
The traditional model was simple: each month, identify vulnerabilities, rank them by severity, deploy the fixes, and start again. It worked while vulnerability discovery moved at human speed and attackers faced real friction. That friction is gone. AI did not break patch management so much as expose that it was already too slow. Manual processes create bottlenecks, and surveys show the vast majority of enterprises report that hand-driven patching disrupts other critical work. The vulnerabilities that slip down the priority list, the ones a busy team never quite gets to, are exactly the ones attackers go looking for.
The shift over the past year is real and measurable. According to the 2026 State of Patch Management Report, most enterprises now begin deploying patches within six days, and a majority complete deployment just as quickly. Autonomous patching has moved from a nice idea to the standard, and the key word is policy-driven: a human sets the risk appetite and the guardrails once, then automation executes at machine speed within them.
We run Action1 for this across our managed clients. It is cloud-native CVE remediation that covers both the operating system and the third-party applications attackers love to target. It deploys through autonomous staged rollouts, so a patch reaches a small pilot group first and only widens once it proves stable, and it uses peer-to-peer distribution so updating an entire fleet does not saturate your internet connection. Identify, deploy, verify, without a person sitting in every single loop. That is what patching at machine speed looks like in practice.
| Dimension | Manual monthly patching | Machine-speed, policy-driven |
|---|---|---|
| Cadence | Monthly maintenance window | Continuous |
| Prioritisation | Severity score alone | Real exploitability and business risk |
| Approval | Human queue for each patch | Policy agreed once, then automatic |
| Deployment | All at once or ad hoc | Staged rings with automatic verification |
| Typical exposure window | Weeks | Hours |
The usual objection is that automated patching will break production. It is a fair worry, and the answer is in how it is done, not whether it is done. Staged rings mean a bad update hits a handful of test machines before it ever reaches the business, and automatic verification confirms each patch actually applied. The larger risk in 2026 is the opposite one: patching too slowly. And because no patch programme is ever perfectly current, patching works best as one layer beside the others in this series. If a gap is briefly open, application control stops unapproved code running through it and EDR catches anything that tries. That layering is the heart of our managed cyber security.
Two of the Essential Eight controls are patch applications and patch operating systems, and at higher maturity levels the Australian Signals Directorate expects critical patches applied within 48 hours of release. You cannot reliably hit a 48-hour target by hand across a real business. Automation is not a shortcut around the Essential Eight, it is what makes those timeframes achievable in the first place.
Retire the monthly-only cadence for critical patches. A once-a-month window is an eternity against a 10-hour exploit timeline. Critical and actively exploited vulnerabilities need to be handled continuously, not held for the next maintenance slot.
Set policy by exploitability, not just severity. A patch programme that treats every high-CVSS item as equally urgent burns time on flaws nobody is exploiting while real risks wait. Prioritising by what attackers are actually using is the subject of the next post in this series.
Confirm your patches are verified, not just pushed. Deploying an update and confirming it applied are two different things. Contact Epic IT for a free patch posture review and we will show you how current you really are and where the gaps sit.
Next in the series: vulnerability management, when attackers scan faster than you can patch.
Our Perth-based team can run a free patch posture review, showing you where you stand against machine-speed exploit timelines and the Essential Eight. Contact us on 1300 EPIC IT.