Speed Alone Is Not the Goal
Update volumes keep climbing — across browsers, operating systems, and the long tail of third-party applications — and IT teams are under growing pressure to close the gap between "patch released" and "patch deployed." In a piece published on BleepingComputer, Gene Moody, Field CTO at patch management vendor Action1, argues that the instinct to solve this with more automation is only half right: automation that just deploys faster doesn't make an organization safer, it just makes both good and bad outcomes happen faster.
"Testing time gets compressed. Review gets skimmed or skipped," Moody writes of the pressure teams face when the backlog grows faster than the hours available to vet each update. The risk is that automation, applied without safeguards, amplifies that shortcut rather than fixing it.
The Core Argument: Automation ≠ Acceleration
Moody's central claim is blunt: "Automation can produce failure at least as quickly as success." A flawed update pushed automatically to thousands of endpoints reaches all of them just as fast as a good one would — there's no built-in mechanism that makes automation prefer safe outcomes over unsafe ones. His conclusion: "good patch automation needs an accelerator, but it also needs brakes."
That framing — accelerator and brakes — is the piece's throughline. The goal isn't to slow down patching across the board; it's to make the automation itself capable of recognizing when to stop.
Update Rings: Staged Rollouts Instead of All-or-Nothing
Rather than a binary choice between deploying an update everywhere or reviewing it manually everywhere, the article recommends structuring rollouts as update rings — progressively wider deployment waves, each gated by whether the previous wave succeeded. A typical structure looks like:
| Ring | Scope | Purpose |
|---|---|---|
| Ring 0 | IT / test systems | Validate the update installs cleanly and doesn't break core functionality |
| Ring 1 | Early adopters (~20% of the fleet) | Representative IT and business users surface issues that test systems miss |
| Ring 2 | Broad deployment (~80% of the fleet) | Full rollout, only after earlier rings meet their success bar |
Production systems become part of the validation process itself, rather than being the first place an update is ever seen outside a lab.
Predefined Success Criteria — the "Brakes"
The mechanism that makes staged rollout more than just a slower version of the same problem is defining, in advance, what "success" and "failure" mean for a given update. Moody frames it as answering three questions before deployment starts:
- Did the update apply successfully?
- Did endpoints remain healthy afterward?
- Did applications continue functioning normally?
Automation can then evaluate those signals at each ring and act on them without waiting for a human to notice a problem: continue rolling out an update that's meeting its criteria, and halt one that isn't, before it reaches the next — and larger — ring.
Where Human Judgment Still Belongs
The article is explicit that this isn't a pitch for removing people from the loop. "The objective is not to eliminate human judgment so much as to use it where it matters," Moody writes. He draws a line between routine endpoints — laptops, standard workstations — and business-critical systems such as domain controllers, databases, and ERP platforms, which warrant manual approval gates regardless of how well an update has performed elsewhere. Automation, in this model, absorbs the repetitive decisions so that the people running patch programs can spend their attention on the systems where a mistake is most expensive.
Worth Noting
The article is a vendor-authored perspective piece — Moody's employer, Action1, sells a patch management platform built around this update-rings model, including manual approval workflows and endpoint grouping, and the piece closes with a pitch for Action1's free tier (up to 200 endpoints). It does not cite specific incident data, CVE examples, or update-volume statistics to back its claims; the argument is presented as operational reasoning rather than backed by named case studies. That doesn't make the underlying advice — stage your rollouts, define success criteria up front, reserve manual gates for your most critical systems — any less standard or sound; it's a widely-recommended pattern independent of any single vendor's tooling. Readers evaluating a patch automation platform should treat the piece as an argument for a deployment model, not a neutral comparison of vendors.