Patch management has a reputation for being a maintenance task. In a cloud-managed environment it’s a security control – and the distinction matters for how you design it.
Devices that aren’t current aren’t just inconvenient. They’re non-compliant, and non-compliant devices produce signals that affect access decisions. Conditional Access can gate access based on compliance state. Defender for Endpoint surfaces vulnerability exposure tied to patch level. The moment you connect device compliance to access enforcement – which is the whole point of this architecture – patching becomes part of your security posture, not a background process.
Intune doesn’t patch devices directly. It expresses intent through update policies, and Windows Update enforces that intent. The device evaluates the policy continuously and works toward the defined state on its own schedule. This is the same convergence model that governs everything else in Intune – not a push, but a standing expectation.
When licensed, Windows Autopatch is my default. It removes the operational overhead of managing update rings manually and hands sequencing to Microsoft – which is a reasonable trade for most environments.
Windows Autopatch is Microsoft’s managed update service. When you enable it, Microsoft takes over the ring structure and manages quality update sequencing on your behalf, using Microsoft’s own deployment rings and rollout cadence. Devices move through rings automatically. You get reporting, you get pause controls for emergency situations, but you’re not making decisions about deferral periods or deadline settings week to week. For organizations that want updates handled reliably without maintaining ring configurations manually, Autopatch delivers that cleanly.
Autopatch requires Microsoft Intune Plan 1 or higher and Windows 10/11 Enterprise or Professional editions. It’s available with Microsoft 365 Business Premium, E3, and E5 licenses. If your licensing covers it, it should be your default starting point – not something you evaluate against manual rings as equals. The question isn’t “should I use Autopatch or rings?” The question is “does my environment have a reason to manage rings manually?”
Manual Update Rings remain the right answer in specific scenarios. Environments with compliance frameworks that require explicit control over update timing, organizations with complex ring structures tied to business units or shift workers, or any environment where a regulatory requirement dictates exactly when patches apply – these are legitimate reasons to manage rings directly. The control is real and the flexibility is genuine. It’s just operational overhead that Autopatch eliminates when you don’t need that level of granularity.
One constraint worth understanding clearly: Autopatch and manual Update Rings are mutually exclusive per device group, not per tenant. You can run both in the same tenant – Autopatch for your standard fleet, manual rings for a subset of devices with specific requirements. What you can’t do is apply both to the same device. The decision is per device group, and it should be deliberate.
Feature updates – major Windows version upgrades – deserve separate treatment from quality updates regardless of whether you use Autopatch or rings. The risk profile is different and the failure modes are more disruptive.
Feature update policies in Intune control which Windows version devices are running and how the upgrade is delivered. These are distinct from quality update policies and should be managed separately. Autopatch handles feature updates through its own cadence, but even there, validating a major OS version upgrade against your application inventory before broad rollout is worth the extra step. A quality update regression is recoverable. An OS version upgrade that breaks a critical application is a more involved remediation.
Driver updates through Windows Update for Business are now manageable separately through Intune – approving, pausing, or blocking specific driver updates rather than taking whatever Windows Update delivers. In standardized hardware fleets this matters less. In mixed environments with varied hardware generations, driver update control prevents the category of regression where a driver update breaks something that was working cleanly before.
Two developments since this pattern settled are worth folding in. The first is hotpatch, which changes the reboot calculus directly. For eligible Windows 11 Enterprise devices, Microsoft now delivers eight of the twelve monthly security updates as hotpatches that apply to running code in memory without a restart, leaving only the four quarterly baseline months to require a reboot. It is on by default where devices qualify, and it is managed through an Autopatch quality-update policy. The practical effect is that the 3am reboot I just described happens roughly a third as often, because the security content that used to force it no longer does. It does not remove restarts entirely, since the baseline months and feature updates still need one, but it meaningfully lowers the number of times you have to interrupt someone to stay patched.
The second is a direction rather than a feature. WSUS is now formally deprecated. Microsoft has stopped investing in it and has made clear that on-premises update infrastructure is not where Windows update management is going. The replacement is exactly the model this article describes: Intune update policies and Autopatch, where Intune holds the policy and the assignments and devices pull content straight from Windows Update with nothing on-premises in the path. Autopatch itself also stopped being a gated feature along the way and now rides the common Windows Enterprise and Microsoft 365 entitlements rather than needing a separate enablement, which removes one of the old reasons teams stayed on manual rings. If you are still running WSUS, treat it as a migration you are managing rather than a platform you are maintaining.
Update management done well is invisible. Devices stay current, compliance dashboards stay green, and nobody files a ticket because their laptop rebooted at 3am on a Tuesday. The environments where update management becomes a project are almost always the ones that deferred the design decisions until something broke in production.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.4] Defender for Endpoint: The Security Layer That Connects Everything
Next: [5.5.1] Configuring Autopatch and Update Rings in Practice ›
