Patch management in rings means you never push an update to every computer at once. A small canary group gets it first. A larger pilot group gets it after the canary group has run it for a few days without trouble. Only then does everyone else get it. The point is simple: a bad patch should break ten machines, not a thousand. This guide explains how to size the rings, what to watch between them, how long to wait, and the one rule most teams get wrong: a patch is not installed because the installer said so. It is installed when a rescan proves it.
Why patching all at once goes wrong
Every month brings updates for Windows, browsers, Office, runtimes and the dozens of third-party tools on a typical fleet. Most of them are harmless. Some are not. An update can break a printer driver, a VPN client, a line-of-business application, or boot itself. If that update went to the whole company on Tuesday night, Wednesday morning is a help desk flood.
The other failure is the opposite: fear of breaking things makes teams delay patches for weeks while known vulnerabilities stay open on every endpoint. CISA's Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) is a good reminder of how fast exploited flaws pile up.
Rings solve both problems. You patch quickly, because the first ring goes out within a day. You patch safely, because you find out about breakage on a small group before it reaches the people who would be most expensive to interrupt.
What a deployment ring actually is
A ring is a named group of endpoints that receives updates at a set stage. Three rings are enough for most organizations.
| Ring | Who is in it | Typical size | When it gets the patch |
|---|---|---|---|
| Canary | IT staff, volunteers, a few machines of each hardware model | 1 to 5 percent of the fleet | Day 0, as soon as the patch is approved |
| Pilot | One or two people from each department, each major application in use | 10 to 20 percent | After the canary soak period |
| Everyone | The rest of the fleet | The remainder | After the pilot soak period |
The percentages are a starting point, not a rule. What matters more than size is coverage. The canary ring should contain every hardware model you own and every critical application, otherwise it tells you nothing about the machines that will actually break. The pilot ring should contain real users doing real work, because IT staff rarely use the finance system or the warehouse scanner software.
Some teams add a fourth ring for servers. That is fine. More than five rings usually means the process has become slower than it needs to be.
Building the rings from rules
The common mistake is to build rings by hand from a spreadsheet. Within three months the spreadsheet is stale: people have left, laptops were replaced, and the "canary" ring is now two retired machines and a printer.
Build rings from rules instead. A ring membership rule can be as simple as:
- Canary: hostname starts with IT-, plus a tag set by the administrator.
- Pilot: one device per department, chosen by the administrator and tagged.
- Everyone: every enrolled endpoint not already in canary or pilot.
Servers deserve their own rule, and so do machines that must not reboot during business hours, such as point-of-sale terminals. A rule-based group picks up new devices automatically and drops old ones when they stop reporting. The same groups serve hardening baselines and drift enforcement and software deployment, so it is worth having one grouping system rather than three.
The soak period: what to watch between rings
The wait between rings is called the soak period. The canary soak is usually two to three days. The pilot soak is usually three to seven days. During a soak you are looking for a small set of signals:
- Install failures. The installer exited with an error on more than a handful of machines.
- Rollbacks. Windows reverted the update on its own after a failed boot.
- Help desk tickets that mention the patched component or started on the day the patch arrived.
- Application health. The pilot users in each department confirm their main application still works.
- Reboot loops or long reboots reported by the agent.
Set a stop rule before you start. For example: if more than two percent of the canary ring fails to install, or any machine fails to boot, the rollout pauses until someone has looked. A stop rule written down in advance removes the argument about whether the problem is "bad enough".
Microsoft's own guidance on Windows Update for Business deployment rings (https://learn.microsoft.com/en-us/windows/deployment/update/waas-deployment-rings-windows-10-updates) follows the same pattern and is a useful reference for the Windows-specific knobs.
Emergency patches skip the wait, not the rings
When a vulnerability is being exploited in the wild, the soak periods shrink to hours, not days. The rings still exist. Canary goes out immediately, pilot a few hours later, everyone the same evening. You still learn about breakage before it hits the whole fleet, just faster. What you should never do is skip straight to "everyone" because the patch is urgent. An urgent patch that bricks the fleet is a bigger incident than the vulnerability it fixed.
"Installed" means rescanned, not "installer returned 0"
This is the rule that separates real patch compliance from a dashboard that looks green.
Most patch tools mark an update as installed the moment the installer exits successfully. That is not the same thing as the patch being present. An update can report success and then be rolled back on reboot. A machine can be restored from an older image. A pending reboot can hold the real change for days.
Good practice is to treat the installer result as a hint and the rescan as the truth. After the install, and after the reboot, the agent scans the machine again and checks that the vulnerable component is actually at the fixed version. Only then does the endpoint count as patched. The same discipline applies to vulnerability management: a vulnerability is closed when a scan no longer finds it, not when someone marked it fixed.
This matters for auditors as much as for security. If an IT audit asks for patch compliance evidence, "the tool said it installed" is weak evidence. "The endpoint was rescanned on this date and the fixed version was found" is strong evidence.
Reboots and the people on the other end
Patching is a people problem as much as a technical one. Forced reboots at 2 a.m. work for desktops that stay on and fail for laptops in a bag. Never forcing a reboot leaves machines "patched, pending reboot" for weeks, which is the same as unpatched.
A workable middle ground:
- Install silently during the maintenance window, usually overnight.
- Notify the user that a reboot is needed and let them pick a time within a deadline, for example 48 hours.
- When the deadline passes, reboot with a visible countdown the user can see but not cancel.
- Treat servers and shared machines differently, with explicit windows agreed with their owners.
Measure the pending-reboot count as its own number. If it is growing, the deadline is too long or the notifications are being ignored.
Patch management checklist
Use this as a quick review of your own process.
- Three rings exist, defined by rules rather than a hand-kept list.
- The canary ring contains every hardware model and every critical application.
- The pilot ring contains at least one real user per department.
- Soak periods are written down: canary 2 to 3 days, pilot 3 to 7 days, shorter for exploited vulnerabilities.
- A stop rule is written down, with a named person who decides whether to continue.
- "Installed" is confirmed by a rescan after reboot, not by installer exit code.
- Pending-reboot count is tracked as its own metric with a deadline.
- Servers, point-of-sale and other no-reboot-during-hours machines have their own window.
- Third-party applications (browsers, PDF readers, runtimes) are in scope, not just Windows.
- Offline laptops pick up the ring's patches when they reconnect, without manual chasing.
- Every ring advance and every pause is recorded with who did it and when.
- Patch compliance can be exported as evidence for an audit.
How Tracemark does it
Tracemark's Endpoint Management product delivers patch management in rings from the same agent and console that run the rest of the platform. Updates roll out in three stages: canary, pilot, everyone. The console also offers dynamic endpoint groups defined by rule, so a group's membership follows the device's attributes and new machines are picked up without anyone editing a list.
The rule about "installed" is built in. A patch counts as installed only after the agent has rescanned the endpoint and found the fixed version. The installer's own success message is not enough on its own, so the compliance number in the console reflects what is actually on the machine.
The agent works offline. Policies are cached on the device and events are queued, so a laptop that was in a bag during the maintenance window is not lost to the process when it reconnects. The agent's own signed updates roll out in rings with rollback, so the tool that patches the fleet is itself updated the same careful way.
Vulnerability findings live in the same console. Exposure Management ranks vulnerabilities with "exploited today" above the highest score, and a finding is fixed when a rescan no longer sees it, not when someone marks it. Changes made by administrators are recorded in the admin trail (who, what, when), and Governance & Audit provides scheduled reports with a delivery history and evidence packs the auditor can open.
Frequently asked questions
How many rings do I need?
Three is enough for most organizations: canary, pilot and everyone. Add a separate ring for servers or for devices that cannot reboot during business hours. More than five rings tends to slow the process without catching more problems.
How long should the soak period be?
Two to three days for the canary ring and three to seven days for the pilot ring is a common pattern. For vulnerabilities that are being exploited, shorten the waits to hours but keep the ring order. Write the numbers down so nobody has to decide under pressure.
Why not trust the installer's success result?
Because an update can succeed and then be rolled back on reboot, be held by a pending reboot, or be undone by a reimage. A rescan after reboot that finds the fixed version is the only reliable proof. It is also the evidence an auditor will accept.
Should third-party applications be in the rings too?
Yes. Browsers, PDF readers, Java and other runtimes are patched at least as often as Windows and are frequent entry points. Run them through the same canary, pilot and everyone stages with the same rescan rule.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca