Posted in

The defaults already decided: Windows Autopatch quality update policy

by ailona•

A Windows Autopatch quality update policy now sets the patch approvals for a fleet in one place: per release category, it decides whether Windows OS quality updates, supported .NET Framework updates and quick machine recovery fixes go out on their own or wait for a human. The Message Center item that landed yesterday (MC1478956) describes that policy, and the honest version of what is new is narrower than the headline. Microsoft already published the identical text on September 1 as MC1465692, and the Windows IT Pro blog described automatic or manual approvals per update category, deferral settings, pause/resume and quality update reports back in November 2025. What the September 1 to October 15, 2026 rollout adds is .NET Framework and quick machine recovery inside the same policy, plus a quick machine recovery status report.

So the useful question is not whether to adopt the policy. It is what the policies already assigned to your devices actually approve, because the defaults are not uniform and a few of them behave in ways that are easy to miss.

What the policy decides

Four categories get their own automatic or manual setting: monthly security updates, monthly non-security preview updates, out-of-band security updates, and out-of-band non-security updates. Automatic approvals take a deferral of 0 to 30 days through the “Make updates available after” setting; manual approvals have no deferral because you control the timing by approving. A policy created in the portal defaults to automatic for monthly security and manual for everything else, which is also the split Microsoft recommends.

“Approval settings apply uniformly to both OS and .NET Framework update types under each release category.”

That uniformity is the part worth reading twice. You cannot approve a .NET Framework security update separately from the Windows cumulative update it ships alongside: one category setting moves both. A single policy is allowed to mix automatic and manual across categories, which is what most fleets end up doing.

Where the defaults bite

  • Precedence is quiet. A quality update policy beats Windows Update ring policies for approval and deferral, but ring deadlines, grace periods, restart settings and notifications still apply. Across several cloud quality update policies, the policy that approves the latest release wins. And when a cloud policy is assigned next to a legacy quality update policy that only carries the hotpatch setting, the cloud policy wins and monthly security updates are not offered to the device until the policy approves them. Leftovers from an earlier pilot are not inert.
  • Cloud deferrals override ring deferrals. If you set a five day cadence in a legacy update ring and two days in the quality update policy, devices follow the policy. Deadlines and grace periods are still configured in the rings, so split the settings on purpose instead of duplicating the cadence in both places.
  • .NET Framework scope is narrower than “supported .NET Framework updates” sounds. Only Windows 11 devices assigned to the policy follow the policy experience for .NET. Windows 10 devices on Extended Security Updates keep receiving .NET Framework updates from Windows Update under client-side settings, so the policy only governs the OS update there, and Microsoft’s guidance is to expect a separate restart. .NET Framework 3.5 updates are not manageable through these policies at all: they do not appear in the quality updates workflow and Windows Update delivers them standalone under client-side settings.
  • Pause is not rollback. Pausing a release revokes the approval so no new devices receive it, and devices that already installed it are not rolled back. Pause is per release, so pausing a .NET Framework release does not hold back an approved OS quality update. Resuming means re-approving the release, which is then offered as if it were newly approved. Devices can take up to eight hours to pick up a pause, because the instruction travels through Intune.
  • Quick machine recovery is manual by default, and the approval method is not editable. A new quality update policy sets quick machine recovery to manual, and Microsoft states the approval method cannot be changed in an existing policy: a different method means creating a new policy. The approval also outranks client-side configuration. Where a device has quick machine recovery configured both through a quality update policy and through CSP or Settings catalog remote remediation settings, the device is not offered recovery until the cloud policy approves the fix. Quick machine recovery itself needs Windows 11 version 24H2 build 26100.4700 or later, and it only applies to boot-critical failures where Microsoft publishes a remediation for the outage.
  • Assignment has enrollment side effects. Devices targeted by a quality update policy are enrolled in Windows Autopatch for quality updates automatically. When a device is removed from every quality update policy it stays enrolled for 24 hours, which is the window to move it to another policy before it drops back to Windows Update scans and client settings.
  • The per-device view needs diagnostic data. The quality update status report refreshes every four hours and covers target compliance, assigned policies, readiness, alerts and hotpatch information per device, and the quick machine recovery report covers affected devices, remediation status, fix version and OS version. Reporting requires the tenant to allow Intune access to Windows diagnostic data; quality update policies themselves expect telemetry at the Required level or higher and the Microsoft Account Sign-In Assistant service (wlidsvc) running.

What to check before the rollout lands

  1. List every quality update policy and read its approval settings. Anything created and assigned without opening the Settings step is auto-approving monthly security updates.
  2. Write down who approves out-of-band security releases and how they will be told, because a manual category with no named approver is a stalled patch.
  3. Put the rollout cadence in the policy deferral (0 to 30 days) and stop maintaining the same cadence in legacy rings, while keeping deadlines and grace periods in the rings where they belong.
  4. Decide quick machine recovery now. It defaults to manual and cannot be flipped later in the same policy, so treat it as a create-time decision.
  5. Confirm eligibility before promising anything to a client: Microsoft Intune Plan 1 plus a Windows licence with the Autopatch entitlement, devices on Pro, Pro Education, Enterprise or Education editions, Microsoft Entra joined or hybrid joined, and public cloud or GCC as the supported clouds. Windows Enterprise LTSC is outside the quality update policy type, which Microsoft points at update rings instead.
  6. Remember that doing nothing is still a valid answer. Devices with no quality update policy keep getting monthly quality updates through standard Windows Update behaviour, with update rings and Windows Update client policies handling deferrals, deadlines, restarts and notifications. The policy is the opt-in for cloud orchestration, Autopatch-managed deployments, hotpatch on eligible devices and policy-based reporting.

Sources