Endpoint management
Update rings
Windows update rings
Windows update rings are Intune policies that control how and when Windows quality updates (monthly cumulative security and reliability fixes) and feature updates reach different groups of managed devices.
Why Update rings matters in a Microsoft estate
Update rings matters for endpoint teams because device, app, compliance, update, and troubleshooting signals often sit across several Microsoft admin areas. Linking these terms back to Intune and device-reporting routes helps readers move from definition to action.
How Update rings shows up in practice
They let an organisation stagger rollout across the estate, rather than exposing every device to a newly released update on the same day it ships from Microsoft. A ring configuration sets deferral periods, the number of days after Microsoft's public release before a device in that ring is offered the update, separately for quality and feature updates. It also sets deadlines forcing installation after a grace period, active hours defining when automatic restarts are avoided, and options like whether users can pause updates temporarily. The underlying rationale is straightforward risk management.
A small, low-risk ring, IT staff and volunteer early adopters, receives updates first with a short or zero deferral, giving the organisation a window to catch update-related problems such as driver conflicts, application breakage, or unexpected reboots. A much larger "broad" ring of general users receives the same update days or weeks later, by which point Microsoft's own telemetry and the organisation's own pilot ring will typically have surfaced known issues worth pausing for. This is the same core mechanism Windows Autopatch automates and manages on the organisation's behalf.
The meaningful practical choice for most Microsoft 365 estates is between manually configured update rings, which give full control over ring membership, deferral periods, and pause/resume decisions but require an admin to actively monitor rollout health and intervene when something goes wrong, and Autopatch, which takes that monitoring and decision-making off the admin's plate in exchange for less granular control over the specifics. A common configuration mistake is setting deferral periods without a corresponding process to actually review what happened in the pilot ring before the broad ring's deferral period expires. This reduces staged rollout to a false sense of safety, since the ring structure only protects the organisation if someone is actually watching for failures in the early rings and is willing to pause deployment when something looks wrong, rather than treating the deferral period purely as a fixed delay.
Update rings also interact with compliance policies in a way that's easy to overlook. A compliance policy checking for minimum OS version needs to be set consistent with the actual deferral periods in the update rings feeding the estate. Otherwise, a compliance policy demanding the very latest patch level, while update rings intentionally hold most devices back by design, will mark a large share of a perfectly well-managed estate as non-compliant. This is a frequent, avoidable source of alarming-looking compliance dashboards that don't actually reflect a real security gap.