Join our Newsletter — 33% off our NHI Course
Home› Guides› Windows Update for Business and Autopatch Security Guide:…
Guide Endpoint Security

Windows Update for Business and Autopatch Security Guide: Policy Settings That Close the Patch Gap

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 14 November 2026 14 min read
On this page

Cloud managed Windows updates only close vulnerabilities as fast as the deferrals, deadlines and approvals you configure, and many fleets are set up so that a security update can legally wait more than a month before it installs. Windows Update client policies (the feature Microsoft formerly called Windows Update for Business) and Windows Autopatch have replaced on-premises update servers for most Windows clients, but their settings interact in ways that are easy to misread: cloud policies override rings, deadlines count from different start points, and pausing one release does not pause another. This guide covers the policy model, the settings that decide your real exposure window, Autopatch groups and approvals, safeguard holds, reporting and the admin plane that controls all of it. It goes deeper than the Patch Management Guide and the Patch Tuesday Guide, which cover programme design, the monthly calendar and hotpatch, and is written for endpoint engineers and vulnerability managers running Microsoft cloud update policies.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Windows Update and Windows Autopatch documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

  • Your exposure window is deferral plus deadline plus grace period. Quality updates can be deferred up to 30 days, and a deadline and grace period then add more; add the three numbers for your last ring to see the real worst case.
  • Use deadlines, not hope. Deadline policies install offered updates and force a restart once the effective deadline passes, regardless of active hours, which is the only way to bound how long a user can postpone.
  • Cloud policies win. An Autopatch or Intune Windows quality update policy takes priority over update ring approval and deferral, while the ring's deadline and grace period still apply; document which object controls which number.
  • Approve security automatically, the rest manually. Microsoft recommends automatic approval for monthly security updates, manual approval for optional and non-security updates, and quality deferrals under three days.
  • The update admin plane is a deployment tool. Accounts that can create update policies, approve drivers or pause releases can delay security fixes across the estate, so govern them as privileged.

The policy model: client policies, rings and Autopatch

Windows Update client policies are free for Windows 10 and 11 Pro, Education and Enterprise editions (including LTSC and IoT Enterprise) and are set through Group Policy, MDM configuration service provider (CSP) policies such as the Update CSP, or Intune. Windows Autopatch is a cloud service that sits on top of those policies to add approval, scheduling and deployment protections, and automates Windows quality, feature, driver and firmware and hotpatch updates plus Microsoft 365 Apps for enterprise, Microsoft Edge and Microsoft Teams.

ObjectWhat it controlsWhere it is set
Update ring policy (Windows 10 and later)Deferrals, pauses, deadlines, grace period, restart behaviour, user optionsIntune update rings, Group Policy or Update CSP
Windows quality update policyApproval mode per update type, cloud deferral, hotpatch and Quick Machine Recovery settingsIntune or Autopatch
Feature update policyWhich Windows version a device moves to and whenIntune or Autopatch
Driver update policyAutomatic or manual approval of drivers and firmwareIntune or Autopatch
Expedite policyAccelerated install of one quality update for targeted devicesIntune
Autopatch groupContainer of device based Entra groups and the policies above, split into sequential ringsIntune admin centre, Autopatch

Decision guidance: small organisations with Microsoft 365 Business Premium can use Autopatch groups directly, since Microsoft now makes the core Autopatch feature set available to Business Premium, A3 and above, E3 and above and F3. Larger organisations usually run Autopatch for the general fleet and keep hand built ring policies only for estates Autopatch does not serve, such as LTSC devices beyond quality updates or devices that cannot send diagnostic data. Disconnected servers and tightly controlled estates may still need an on-premises server; see the WSUS Security Guide. Moving from Configuration Manager requires the Windows Update and Device configuration co-management workloads set to Intune or Pilot Intune; see Configuration Manager to Intune.

Settings that decide the exposure window

SettingRangeSecurity guidance
Quality update deferral period0 to 30 days0 for test, 1 to 2 for pilot, under 3 for the last ring
Feature update deferral period0 to 365 daysUse feature update policies to pin versions instead of long deferrals
Pause (feature or quality)Up to 35 days from the start datePausing feature updates does not stop quality updates; treat any quality pause as an exception with an owner
Deadline for quality updates2 to 30 days (Intune)Short; Autopatch recommends 0 to 1 day after deferral
Deadline for feature updates2 to 30 days (Intune)Around 5 days, as in Autopatch's recommended feature settings
Grace period0 to 7 days1 to 2 days for most users; longer only for staff returning from leave
Auto reboot before deadlineYes or NoYes (Microsoft recommends it)
Option to pause Windows updatesEnable or DisableDisable, so users cannot pause
Option to check for Windows updatesEnable or DisableKeep enabled so users can pull a fix early
Feature update uninstall period2 to 60 daysKeep long enough to roll back a bad release
Windows drivers / Microsoft product updatesAllow or BlockAllow drivers, but manage them through driver policies with approvals

How deadlines are actually calculated

On Windows 11 version 22H2 and later, the deadline counts from when the client first discovers the update in a scan, and the grace period counts from when the restart becomes pending. The effective deadline is the later of discovery plus deadline days and restart pending plus grace period, after which the device restarts outside active hours. The CSPs are Update/ConfigureDeadlineForQualityUpdates, Update/ConfigureDeadlineForFeatureUpdates, Update/ConfigureDeadlineGracePeriod, Update/ConfigureDeadlineGracePeriodForFeatureUpdates and the two ConfigureDeadlineNoAutoReboot settings for quality and feature updates. Two interactions catch teams out:

  • Configure Automatic Updates: since the December 10, 2024 update it is respected before the deadline and ignored once the deadline passes.
  • Maintenance windows: Microsoft recommends using maintenance windows or deadlines, not both; when both apply, the window wins except once a deadline has expired.

With Autopatch quality policies the compliance date is release date plus policy deferral plus client deadline for automatic approval, and approval date plus client deadline for manual approval. Write those formulas into your remediation standard so the stated SLA matches the configuration. See the Remediation SLAs and Vulnerability Exceptions Guide.

Autopatch groups, rings and approvals

  • Groups and rings: every Autopatch group contains the Test and Last rings, which cannot be removed or renamed, and up to 15 rings in total; a tenant can hold up to 300 groups. Only device based Entra groups are supported, and Test and Last each take one group (with one level of nesting).
  • Distribution: rings can be assigned from a fixed group or spread dynamically by percentage; avoid devices appearing in more than one Autopatch group, which Microsoft warns causes conflicts.
  • Recommended quality settings: Microsoft's example is Test with 0 days deferral, 0 deadline and 0 grace; Ring 1 with 1, 0 and 1; Last with 2, 1 and 2, all with automatic restart before the deadline. That puts the last ring's worst case at about five days after release.
  • Approval modes: set separately for monthly security, monthly non-security preview, out-of-band security and out-of-band non-security updates. Automatic is the default for monthly security; the others default to manual. An existing policy's approval method cannot be changed, so plan it at creation.
  • Pause: pausing a release revokes its approval but does not roll back devices that installed it, does not pause other approved releases, and can take up to eight hours to reach devices.
  • Driver and firmware: receive automatically or self manage with approvals per group, ring or tenant. Firmware is a high impact change, so approve it through the same ring sequence as feature updates. See the Firmware and BIOS Update Management Guide.
  • Hotpatch: configured in the quality update policy; the restart and baseline month model is covered in the Patch Tuesday Guide.

Autopatch registers devices when a group is created or edited. Microsoft requires devices to be corporate owned (Windows BYOD devices are blocked at registration), enrolled in Intune or co-managed, and in contact with Intune within the last 28 days. Its service level goal is to keep at least 95 per cent of Up to Date devices on the latest quality update, so the devices outside that population, the ones that are not registered, not reporting or flagged with alerts, are where your risk sits.

Emergency updates, holds and rollback

  • Expedite: when a specific security update must land faster than the normal timeline, an Intune expedite policy targets that one quality update to a set of devices without building a new quality update policy. Use it for actively exploited vulnerabilities, then let the normal rings catch up. See the Emergency Out-of-Band Patching Playbook.
  • Manual approval override: in Autopatch a manually approved release ignores the deferral, which is the faster route when the release is an out-of-band security update that defaults to manual.
  • Safeguard holds: Microsoft blocks a feature update from devices with a known compatibility issue, identified by an eight digit ID visible in Windows Update for Business reports and the Windows release health known issues page. Holds apply to feature updates through Windows Update only, not WSUS or media. Opting out is for validation in test environments after robust testing; Microsoft cautions it can expose devices to known issues.
  • Stale holds: a hold can persist after Microsoft has resolved it if TLS inspection breaks access to adl.windows.com or the settings-win.data.microsoft.com and settings.data.microsoft.com endpoints. Exclude those from inspection.
  • Rollback: the feature update uninstall period (2 to 60 days) bounds how long a feature update can be removed. For quality updates, uninstalling reopens the vulnerability; prefer pausing the release for devices that have not yet installed it.

Where identity fits

Update policy is a fleet-wide control that can be used to delay security. An account that can extend deferrals, pause releases, change approval mode or approve a driver for every device has the same reach as the software deployment tools tracked by MITRE ATT&CK as T1072 Software Deployment Tools. Microsoft lists Policy and Profile Manager, or a custom role with the Device configurations permissions, as the role to manage quality update policies, and Endpoint Security Manager, Read Only Operator or Help Desk Operator to view reports. Use those narrower roles rather than Intune Administrator, apply scope tags so regional teams cannot change other regions' rings, and require a change record for any pause or deferral increase. Autopatch also requires app-only authentication to be turned on in the tenant so the service can read device attributes; review that the service principals it uses are expected and keep their consent records. See the Microsoft Intune Guide for Multi Admin Approval and the If your patch management tool is compromised playbook for the response side.

Reporting, detection and measurement

  • Prerequisites for reporting: quality update policy reporting needs Windows diagnostic data at least at Required and tenant consent for Intune to use it; Autopatch's population based deployment protections need Optional (Windows 11) or Enhanced (Windows 10). Devices with diagnostic data blocked by policy fall out of reports silently.
  • Reports: Windows Update for Business reports (via the Azure portal), the Intune quality and feature update reports, and Autopatch device alerts. Treat "not ready" and "not up to date" alerts as vulnerability findings with owners.
  • Policy drift: Intune audit logs for changes to update rings, quality, feature and driver policies, pauses and approvals; alert on a quality pause or deferral increase outside a change.
  • Cross check: compare update compliance with your vulnerability scanner's missing patch findings, because the update service only reports what it manages.
MetricTargetWhy it matters
Devices on the latest quality update, 7 days after release95 per cent or moreMatches Autopatch's own service level goal
Managed Windows devices registered to an Autopatch group or ring100 per centUnassigned devices have no deadline at all
Devices that have not reported in 28 daysUnder 2 per centThey drop out of Autopatch registration and reports
Maximum configured exposure window (deferral + deadline + grace, last ring)7 days or lessShows the configuration can meet the SLA
Active quality pauses older than 7 days0Pauses are exceptions, not a holding pattern
Devices on an unsupported Windows version0They no longer receive security updates

Implementation and rollout

  1. Baseline: export all update ring, quality, feature, driver and expedite policies with assignments; compute the exposure window for each ring and list devices with no policy, conflicting policies or Group Policy and MDM both setting Windows Update.
  2. Prerequisites: confirm licences, Intune enrolment or co-management workloads, diagnostic data levels, and network access to Windows Update and Autopatch endpoints.
  3. Design rings: Test (IT and representative hardware), one or two middle rings, and Last; decide approval modes per update type before creating policies, since they cannot be changed later.
  4. Pilot: create one Autopatch group for a pilot population, run two monthly cycles, and check deadline behaviour, restart experience and report accuracy.
  5. Expand: migrate populations by device group, removing legacy ring assignments as each moves, so one object controls each number.
  6. Lock down: disable user pause, set auto reboot before deadline, scope roles and add alerts for policy changes.
  7. Rollback: keep previous ring policies unassigned for one cycle; if a release causes problems, pause it rather than unassigning policies, which leaves devices with no deadline.

Framework mapping

FrameworkReferenceWhat the configuration evidences
NIST SP 800-53 Rev 5SI-2 Flaw RemediationRings, deadlines and compliance reports show flaws are fixed within defined time periods
NIST SP 800-53 Rev 5CM-3 Configuration Change ControlChange records for pauses, deferral changes and approvals
NIST SP 800-53 Rev 5RA-5 Vulnerability Monitoring and ScanningScanner cross check of update compliance
NIST CSF 2.0PR.PS-02, ID.RA-01Software maintained commensurate with risk; vulnerabilities recorded
CIS Controls v8.17.3 Perform Automated Operating System Patch Management, 7.4 Perform Automated Application Patch ManagementAutomatic approval of monthly security updates; Microsoft 365 Apps and Edge in Autopatch
ISO/IEC 27001:2022 Annex AA.8.8 Management of technical vulnerabilities, A.8.32 Change managementPatch timelines and approval records
MITRE ATT&CKT1072 Software Deployment ToolsScoped roles and audit of update policy changes

Common failure patterns

  • Long deferrals in the last ring. A 14 day deferral plus a 7 day deadline plus a 7 day grace period is a four week window that looks like "monthly patching" on paper.
  • No deadlines configured. Without deadline settings, users can postpone restarts indefinitely and the compliance report shows devices stuck at pending restart.
  • Two policy sources. Group Policy from a legacy domain baseline and Intune both set Windows Update, so the effective setting depends on which applied last.
  • Pauses that never end. A release is paused for a known issue and nobody resumes it; devices that did not install it stay exposed.
  • Diagnostic data blocked. Privacy hardening sets telemetry below Required, the device disappears from reports and from Autopatch protections, and the dashboard looks healthier than the estate.
  • Devices outside every group. New hardware or a renamed dynamic group leaves devices with no ring, which means no deadline and no reporting.

Practitioner checklist

  • Calculate deferral plus deadline plus grace for every ring and keep the last ring within your SLA.
  • Use automatic approval for monthly security updates and keep quality deferrals under three days.
  • Turn on deadline settings with auto reboot before deadline and a grace period of 2 days or less for most users.
  • Disable the user option to pause Windows updates.
  • Make sure every managed Windows device belongs to exactly one Autopatch group or ring policy.
  • Remove Group Policy Windows Update settings from devices managed by Intune policies.
  • Keep diagnostic data at the level your reports and Autopatch protections require.
  • Exclude the safeguard hold endpoints from TLS inspection and only opt out of holds in test rings.
  • Manage update policies with Policy and Profile Manager or a custom role, scoped with tags, and alert on pauses and deferral changes.
  • Reconcile update compliance with vulnerability scanner findings monthly.

Standards and references

Related NHI Mgmt Group resources: Patch Management Guide · Patch Tuesday Guide · WSUS Security Guide · Windows Autopilot Security Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 14 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org