Patch management

How fast should you patch? Faster than your rings allow

Ask how fast you should patch and the industry hands you a ritual: a pilot ring, a 72-hour wait, a broader ring, another wait, then the rest of the estate, three or four weeks after release. That advice was written for fleets of fifty thousand machines and a team that genuinely watches the pilot ring. For almost everyone else, we think it is the riskier choice, and this piece is the case for patching much faster.

The maths the standard advice ignores

Deployment rings exist to manage one risk: a bad patch breaking things. They manage it by adding time. What the ritual never prices in is what that time now costs, because the other side of the ledger has changed completely.

The median time from a vulnerability being disclosed to it being exploited in the wild is now measured in days, often under five, and a growing share of vulnerabilities are exploited before a patch even exists. Meanwhile the average organisation takes more than 60 days to remediate a critical vulnerability, and roughly six in ten breaches involve a vulnerability for which a patch was already available. In several recent incidents, exploitation began within 24 hours of a vulnerability being added to CISA's Known Exploited Vulnerabilities catalogue.

Put those numbers side by side and the conclusion is uncomfortable. The window between a patch being released and your estate installing it is not slack in the schedule. It is the attack window, and it is where most real-world compromises now happen. Every 72-hour pause between rings is not caution. It is three more days spent inside the exploited zone, multiplied by every machine still waiting.

A ring nobody watches is just a delay

Here is the question that decides whether your rings are a control or a costume: when your pilot ring finished last month, what did anyone actually check?

At enterprise scale there is a real answer. Application owners run smoke tests, a helpdesk watches ticket volumes from the pilot cohort, and advancement to the next ring is a decision someone makes against evidence. That is testing, and it earns its delay.

In most estates of 30, 100 or even 500 machines, the honest answer is nothing. Nobody ran a test plan. Nobody compared failure rates. The pilot ring "passed" because nobody phoned to complain, which is the same evidence you would have had by deploying everywhere. You have adopted the enterprise pattern's delay without its validation, which means you are carrying all of the cost and none of the benefit. A ring nobody watches is not a safeguard. It is a queue.

The ceremony compounds quietly, too. A pilot ring on Tuesday, 72 hours of not looking at it, a broader ring, 72 more, a change freeze on Fridays and then the weekend, and a fix released on the 10th reaches the last laptop on the 4th of the following month. Nobody decided to accept three and a half weeks of exposure. The process decided it, one reasonable-sounding pause at a time.

The strongest recent argument for rings does not even survive contact with its own example. The most catastrophic bad update in years, the CrowdStrike outage of July 2024, was not a Windows patch. It was a security vendor's content update, pushed through a channel that ignored customers' staging policies entirely. Organisations that had carefully configured n-1 and n-2 update rings were flattened alongside everyone else. The disaster everyone cites to justify slow patching is one that rings demonstrably failed to prevent, while the breaches that known vulnerabilities cause every week rarely make the news at all.

Weigh a bad patch against a breach, honestly

None of this claims bad patches do not happen. They do, a few times a year, and occasionally a nasty one. The argument is that the two risks are wildly asymmetric, and the ritual treats them as equal.

A bad patch is loud, fast and reversible. Machines blue-screen, a printer driver dies, an application refuses to start, and you know within hours because users tell you. Windows can uninstall a cumulative update, Microsoft ships Known Issue Rollback fixes for widespread problems, and you can pause a deployment mid-flight. If your backups are monitored and restorable, even the worst case is a bad day, not a bad quarter.

A breach through a known, unpatched vulnerability is the opposite in every respect. It is silent, it dwells for weeks, and nothing about it can be rolled back: not the exfiltrated data, not the ransomware deployment, not the incident-response invoice. You cannot uninstall a compromise.

How fast should you patch, then?

Fast enough that the release-to-deployed gap is measured in days. A cadence we would defend for a typical estate looks like this:

• Security updates: auto-approved, deployed within 72 hours of release. Not after a two-week soak. If a vulnerability is in the Known Exploited Vulnerabilities catalogue, deploy immediately, everywhere, including servers.
• Keep a canary, but size it in hours, not weeks. A handful of machines that install on day zero, advanced automatically the next day unless failures actually appear. The point of a canary is automated observation, not a fortnight of ceremony.
• Servers get care, not delay. A snapshot, a maintenance window, a tested restore path, and then the patch, days after release rather than months. Care is preparation; delay is just exposure with paperwork.
• Third-party applications run continuously. Browsers and readers are the most exploited software you manage and their patching sits outside Windows Update entirely, so it should not wait for a monthly cycle at all.

One distinction keeps this from being reckless: the argument is about security updates, not feature upgrades. Defer a Windows feature update for months if you like, since nothing exploits your not having the newest Start menu, and the compatibility risk there is real. The mistake is letting the caution appropriate for feature changes set the tempo for security fixes, because the two ride entirely different risk curves.

The prerequisites are unglamorous: per-device visibility of what failed to install, reboot discipline so patches actually take effect, and a restore path you have tested. If a machine reports a failure, find the real cause instead of widening the delay for everyone else. And measure the thing that matters: not whether you have rings, but how many days pass between a patch being released and 95% of your estate having it. Whether you look after your own organisation's machines or a dozen clients' estates, that one number is your actual exposure, and for most teams reading this, shrinking it will do more for security than any other change this year.

Where this fits with Helios

The cadence above only works if the boring parts are automatic, which is why Helios treats them as platform work rather than technician work. Patch policies auto-approve and deploy on the schedule you set, Windows and third-party alike, and every device reports per-update success or failure rather than a fleet-wide green tick. Because the same agent watches health continuously, a canary group is genuinely observed: if failures spike after a rollout, you see it in hours and can pause, and Helio's auto-healing picks up the routine failures without a ticket. Speed is safe when the feedback loop is real.