Windows Autopatch Now Controls Quality, .NET, and Quick…

Starting September 1, 2026, Windows Autopatch stopped being a Windows-quality-updates-only service. Microsoft is rolling out a single governance surface that also covers supported .NET Framework updates and Quick Machine Recovery (QMR) updates — the feature that lets Windows auto-repair a device that will not boot. The rollout is phased and lands across all tenants by October 15, 2026. If you manage endpoints with Intune, this changes how you approve, defer, pause, and report on patches, and it introduces at least one decision you cannot walk back once you make it.

This post builds the practical decision model: when to use automatic versus manual approval, how quality updates, .NET updates, and QMR updates are governed as separate approval settings inside the same policy, how deployment rings and deferrals actually interact, how to approve an emergency QMR fix, how to pause a release that is causing problems, and what happens when a client-side Settings Catalog configuration disagrees with a cloud-based approval. Every claim below is checked directly against Microsoft Learn as of September 2026 — including the one warning that matters most.

Watch this post — YouTube walkthrough

Watch on YouTube · Subscribe at @EndpointWeekly

The short version

Windows Autopatch's quality update policy is now the single control point for Windows OS quality updates, supported .NET Framework updates, and Quick Machine Recovery updates — you configure automatic-or-manual approval and a deferral period per update type, all inside one policy object. The approval method you pick for each update type cannot be changed later; if you get it wrong, Microsoft requires you to build a brand new policy rather than edit the existing one. Cloud-based approvals in this policy always beat client-side Settings Catalog or CSP configuration for the same device. This post walks through the full decision model, including the exact console steps, the Recovery CSP paths involved, and a read-only Graph script that audits every quality update policy in a tenant for exactly this kind of approval-method mistake before it becomes permanent.

Watch out — this cannot be undone. Microsoft's own documentation states it twice, in near-identical wording, on two separate pages: "The approval method cannot be changed in an existing policy. If you need to use a different approval method, you must create a new policy." This applies to every approval setting inside a Windows quality update policy — including the one that governs Quick Machine Recovery updates. Pick automatic when you meant manual, or the wrong update type, and there is no edit screen that fixes it. You build a new policy, reassign every device, and retire the old one. Get this right before you click Create, not after.

The problem: three update types, one policy, one irreversible setting

Before September 2026, Windows Autopatch quality update policies only controlled Windows OS quality updates. .NET Framework updates and Quick Machine Recovery updates followed whatever client-side Windows Update settings a device already had, mostly invisible to central governance. Microsoft's message center entry, published September 1, 2026 at 11:00 PT, titled "More control for Windows Autopatch updates: quality updates, .NET Framework, and quick machine recovery," changes that. The rollout begins that day and is expected to complete for all tenants by October 15, 2026 — this is an active, in-progress change, not something you can assume every tenant already has.

Once a tenant has the update, a single Windows quality update policy becomes the control point for four things at once:

Windows OS monthly security updates and monthly non-security preview updates
Supported .NET Framework updates — security, non-security, and out-of-band releases, riding on the same approval and deferral settings as the matching OS update category
Out-of-band (OOB) security and non-security updates, for both OS and .NET Framework
Quick Machine Recovery updates — Microsoft-provided remediation fixes for devices stuck in a boot-failure loop

Each of those update types gets its own approval method: automatic or manual. You can mix them — automatic for monthly security, manual for everything else, for example. That flexibility is the whole point of the redesign. The problem is that Microsoft's own FAQ is blunt about what happens if you choose wrong:

Context. Quoted directly from Microsoft Learn's Windows quality updates and .NET Framework updates overview, under "Can I edit the approval method in an existing quality update policy?": "No, the approval method cannot be changed in an existing policy. If you need to use a different approval method, you must create a new policy." The Quick Machine Recovery updates page carries the same rule in its own words: "The approval method cannot be changed in an existing policy. If you need to use a different approval method, you must create a new policy." Two separate pages, two separate authors, the same non-negotiable behavior.

That single sentence is the reason this post exists. Get the approval method wrong on any update type in a quality update policy — including QMR — and Intune will not let you flip it later. You retire the policy and stand up a replacement. If that policy is already assigned to thousands of devices, that is a real migration, not a settings tweak.

Why it happens: how Autopatch actually structures approval across quality, .NET, and QMR updates

To make sensible decisions here, you need to understand how Microsoft actually modeled this, not how it looks from the console alone. Windows Autopatch quality update policies are backed by a Microsoft Graph beta resource called windowsQualityUpdatePolicy. Every policy carries a collection of approval settings, and each entry in that collection has four fields: a cadence (monthly or outOfBand), a category (all, security, nonSecurity, or — the one that matters here — quickMachineRecovery), an approval method (manual or automatic), and a deferral in days.

That quickMachineRecovery category value, documented directly on Microsoft's Graph reference for the windowsQualityUpdateApprovalSetting resource, confirms what the human-readable docs describe in prose: QMR is not a separate policy type. It is one more approval-setting row inside the same quality update policy object that already governs OS and .NET updates. That is why the "cannot be edited" rule that applies to a security-update approval method applies identically to the QMR row — they are the same kind of object, just a different category value.

Gotcha. A single quality update policy supports up to six approval settings, but the UX in Intune only expects four (the standard security / non-security / OOB-security / OOB-non-security split). QMR and hotpatch are configured on the same policy through separate screens in the creation wizard, not as extra rows you add yourself in that four-item list — so do not assume "four settings visible" means QMR was skipped. It is configured elsewhere in the same wizard, and it still inherits the same "cannot be edited later" rule.

The defaults matter too, because they are asymmetric across update types. When you create a new quality update policy, monthly security updates default to automatic approval. Monthly non-security preview updates, out-of-band updates, and Quick Machine Recovery updates all default to manual approval. Microsoft's stated reasoning: security patches are time-critical enough that automatic rollout (with a sane deferral) beats waiting on a human, while everything else benefits from a human looking at the payload first.

.NET Framework updates ride on whichever OS category they match — a .NET security update follows the same approval method and deferral as the OS monthly security setting, not a setting of its own. There are two real exceptions worth knowing before you plan a rollout:

.NET Framework 3.5 cannot be managed through Autopatch quality update policies at all. These updates never appear in the quality update workflow. Windows Update delivers them as standalone content governed by client-side settings, so their timing can genuinely differ from everything else in your policy.
Windows 10 devices enrolled in Extended Security Updates (ESU) do not get the combined behavior. They keep receiving .NET Framework updates from Windows Update based on client-side settings; the quality update policy's approval settings apply only to the OS quality updates on those devices, and .NET updates there can trigger a separate restart.

How to verify: what your existing policies actually enforce today

Before you touch any policy, find out what is actually configured right now — both in the cloud policy and on the client. Two places to check, and they do not always agree.

Check the cloud-based policy in the portal

Start with the human-readable view. This shows you approval method and deferral per update type, per policy.

Devices › Manage updates › Windows updates › Quality updates

Sign in to the Microsoft Intune admin center.
Go to Devices > Manage updates > Windows updates > Quality updates.
Select an existing policy to open it, and review its approval method for each update category — including the Quick Machine Recovery and hotpatch settings screen further into the wizard.
Repeat for every policy assigned to devices you care about. Multiple policies can target the same device; Windows Autopatch resolves conflicts by letting the policy approving the latest release take priority.

That is fine for a handful of policies. It does not scale to auditing a tenant with dozens of them, which is why the companion script in this post queries the same data through Graph instead.

Real capture of the Devices, Windows updates, Quality updates tab, showing Autopatch update readiness tools and the policy list — Real capture from a live Intune tenant — the Quality updates tab, with the Autopatch update readiness checkup and alerts tiles, and a live policy list below.

Real capture of a Windows quality update policy's Automatic update deployment settings, showing Allow toggles for cumulative updates and hotpatch — Real capture — the automatic-approval toggle for cumulative quality updates and hotpatch inside an actual policy.

Real capture of a Windows quality update policy's properties page, showing scope tags, assignments and included groups, with the owner name and internal scope tag redacted — Real capture from a live tenant — the policy owner's name and an internal scope tag are redacted. Everything else (ring structure, group names, settings) is unmodified.

Check the client-side Settings Catalog / CSP configuration

QMR also has a purely client-side configuration surface: the Recovery CSP, which some organizations configure through a Settings Catalog profile (or the reagentc.exe /setrecoverysettings command line, or the Windows Settings app directly on the device). This is a genuinely separate control from the cloud-based quality update policy's QMR approval setting, and Microsoft's documentation is explicit about how the two interact:

Note, quoted directly from Microsoft Learn. "Some devices have Quick machine recovery updates configured both through a Quality update policy (for approval settings) and via CSP or Settings catalog policy (for remote remediation settings). In this case, the devices aren't offered Quick machine recovery until you approve the update. Approvals via cloud policies take precedence over client-side settings."

In plain terms: a device can have EnableQuickMachineRecovery set to true at the client level and still never receive a QMR fix, because the cloud-based quality update policy governing that device has QMR set to manual approval and nobody has approved the release yet. The client-side toggle controls whether the device is even capable of asking for a fix; the cloud policy controls whether it is allowed to receive one. Both must be favorable for a device to actually get remediated.

Recovery CSP reference — the client-side QMR settings

These nodes live under the parent path below, deployed through Intune's Settings Catalog (search for "Quick machine recovery" or "Recovery" when adding settings) or via the reagentc.exe command line and its XML file:

./Vendor/MSFT/Recovery/QuickMachineRecovery/

Node (type)	Purpose	Allowed values
`EnableQuickMachineRecovery` (bool)	Master on/off switch for QMR on the device	`true` / `false`
`AutoRemediationSettings/EnableAutoRemediation` (bool)	Whether the device checks for a fix automatically versus waiting for manual action in WinRE	`true` / `false`, depends on `EnableQuickMachineRecovery=true`
`AutoRemediationSettings/SetRetryInterval` (int, minutes)	How long the device waits before checking again after a failed attempt	0-4320 (0 = check once, no retries)
`AutoRemediationSettings/SetTimeToReboot` (int, minutes)	How long the device stays in the recovery environment before forcing a reboot	1-4320 (max 72 hours)

Watch out — this is CSP/Settings Catalog only, with no Group Policy ADMX equivalent. Microsoft's Recovery CSP documentation does not list a corresponding Group Policy path for any Quick Machine Recovery node, and none of the QMR configuration guidance on Microsoft Learn mentions one. If your organization still manages endpoint policy primarily through on-premises Group Policy, QMR's client-side settings are simply out of reach that way — you configure them through Intune's Settings Catalog, the reagentc.exe command line, or by letting the user set them directly in Windows Settings. Do not spend time hunting for a GPO for this; there is not one.

The fix: the decision model — rings, deferrals, emergency approvals, and pausing a bad release

With the mechanics understood, here is how to actually run this day to day: how to structure automatic versus manual approval, how deployment rings and deferrals work together, how to approve an emergency QMR fix outside your normal cadence, and how to pause a release that turns out to be bad.

Deciding automatic versus manual, per update type

Treat this as four separate decisions, not one:

Update type	Microsoft's default	Recommended posture
Monthly security (OS + .NET)	Automatic	Keep automatic, with a short deferral (1-3 days) on a pilot ring, longer (7-14 days) on production, so a bad release surfaces on pilot devices first
Monthly non-security preview (OS + .NET)	Manual	Keep manual unless you have a specific reason to want preview features early — these are optional by design
Out-of-band security / non-security	Manual	Keep manual for non-security OOB; consider automatic with a very short deferral for OOB security if your team cannot guarantee same-day manual review of critical fixes
Quick Machine Recovery	Manual	Manual is defensible for most fleets, since QMR fixes are rare, high-impact, and worth eyes-on review — but if boot-failure incidents are common in your estate, automatic with a 0-1 day deferral gets remediation to affected devices fastest

Tip. Whatever you choose, you can always manually override a deferral and approve a specific release immediately — Microsoft confirms this explicitly in its FAQ. That means "automatic with a deferral" is not a one-way door the way the approval method is. You can safely default to automatic-with-deferral for lower-risk categories, knowing you can still fast-track a specific release the moment you need to.

Deployment rings and the deferral period

Windows Autopatch groups build the familiar test / pilot / production staging pattern by assigning different quality update policies (with different deferral periods) to different Autopatch groups or device rings. The deferral period itself only ever applies to automatically approved updates — for manual approval, you control timing entirely through when you click Approve. The allowed deferral range for quality updates is 0 to 30 days. A shorter deferral means faster delivery to that ring; a longer one buys you more time to see how the update behaves elsewhere first.

Gotcha. When a device is assigned to both a legacy Update ring policy and a cloud-based quality update policy, the cloud-based quality update policy's approval and deferral settings win. Other Update ring settings — deadlines, grace periods, active hours — still apply from the ring policy. If you inherited an estate with both policy types layered on the same devices, do not assume the ring policy's deferral is what is actually controlling delivery; check the quality update policy first.

Real capture of Autopatch groups and their deployment rings, including a ring policy with status Paused, group names and device counts redacted — Real capture from a live tenant — group and ring names, plus device counts, are redacted since they would reveal organization scale. Notice the bottom ring policy's status: **Paused** — a live example of the mechanism covered next.

Approving an emergency QMR fix

QMR fixes exist because a device cannot boot. When one becomes available and your policy has QMR set to manual approval, here is the full path to get it out immediately:

Sign in to the Microsoft Intune admin center.
Go to Devices > Manage updates > Windows updates > Quality updates.
Select Manage updates.
On the Manage quality updates blade, find the QMR release under the Release column.
Select the release name to review its details, including the included KBs, before approving.
Check the Approved policies column — it shows "X of Y" policies approved, and you can select that to see exactly which policies still need review.
Select the policies that need this release and select Approve.

To approve a single policy without going through the bulk workflow, open that individual policy, select the horizontal ellipses (...) next to the release, and select Approve directly. And if the policy is already set to automatic approval with a deferral period, you do not have to wait it out — Microsoft's FAQ confirms you can manually override the deferral and approve immediately whenever needed, which is exactly the emergency-approval path for an automatic policy.

Manage quality updates › Select release › Approved policies (X of Y) ›

Real capture of the Create expedite policy wizard, showing Microsoft's own note that expediting is currently the only dedicated emergency quality-update control besides update rings — Real capture — Microsoft's own in-product text confirms expediting is currently the only dedicated control, beyond the standard approval workflow above, for forcing a lagging device onto a specific quality update faster.

Approve

Pausing a bad release

If a QMR fix, quality update, or .NET update turns out to cause problems after approval, you do not have to wait for it to run its course. Pausing revokes approval so no new devices receive it — devices that already installed it are not rolled back, only new offers stop.

Go to Devices > Manage updates > Windows updates > Quality updates in the Intune admin center.
Select Manage updates.
Select the release you need to stop, and use the same Approved policies view to see which policies currently have it approved.
Select the affected policies and select Pause.

Gotcha. The pause only affects the specific release you selected. Pausing a bad .NET Framework release does not pause an already-approved Windows OS quality update running alongside it, and pausing an OS security update does not touch a separate non-security or QMR release. If several update types went out together and you need to stop all of them, you pause each one individually.

Devices can take up to eight hours to apply a new pause setting, because Windows Autopatch relies on Intune's normal device check-in cadence to deliver the instruction — plan your incident response timeline around that, not around an assumption of instant effect. To resume, simply re-approve the update; Windows Autopatch offers it again to devices that still need it, exactly as if it were newly approved.

Proof it worked: reading the reports and the audit script's output

Two ways to confirm your governance decisions are actually working: the built-in Quality update status report, and a read-only Graph script you can run against your own tenant.

Real capture of the Windows updates Releases tab, showing quality and feature update releases with deployment status and first-deployment date — Real capture from a live tenant — the Releases tab ties every quality and feature release to its rollout status across all of your policies.

The Quality update status report

Reports › Windows Autopatch › Windows quality updates › Quality update status

Go to Reports > Windows Autopatch > Windows quality updates in the Intune admin center.
Select the Reports tab.
Select Quality update status.

The report refreshes every four hours and gives you a per-device view. The columns that matter most for this post's decision model:

Column	What it tells you	Why it matters here
Update status	Up to date / In progress / Not up to date	The headline compliance signal per device
Target compliance	Calculated as release date + deferral + deadline (automatic) or approval date + deadline (manual)	Shows you exactly how your approval-method choice changes the compliance clock
Quality update policy	Which policy (or policies) govern this device	The fastest way to spot a device still on a policy you meant to retire after an approval-method mistake

Optional columns worth adding for this scenario include Hotpatch readiness and Build number — both help you separate "not up to date because it is waiting on approval" from "not up to date because it is not even eligible for the update path you configured."

Real capture of the Quick machine recovery (QMR) updates report, showing device counts by remediation status and the quality update policy tied to each device, device names redacted — Real capture from a live tenant — device names are redacted. Notice the **Quality update policy** column: it shows exactly which policy's approval controls each device's QMR remediation — the same linkage the Settings Catalog vs. cloud approval section above describes.

The companion script: auditing every quality update policy for approval-method risk

The script for this post, Get-AutopatchQualityUpdatePolicyAudit.ps1, queries the same windowsQualityUpdatePolicy Graph resource behind the portal experience, and reports on every policy in the tenant: its approval method and deferral for each update category, whether hotpatch is enabled, and specifically whether Quick Machine Recovery is set to manual or automatic. It is entirely read-only — it calls Graph with GET only, using the DeviceManagementConfiguration.Read.All scope, and never modifies a policy.

Context — why this script cannot be run against a real tenant for this post. This post's author does not have a Windows Autopatch tenant with quality update policies configured available to test against right now. The output below is genuinely illustrative, clearly labeled as such, built from the exact JSON shape Microsoft documents for this Graph resource — not a real captured run. Validate the script in your own tenant before trusting its output operationally.

PowerShell — ILLUSTRATIVE example, not a real run (placeholder tenant data)

.\Get-AutopatchQualityUpdatePolicyAudit.ps1 -TenantId "<redacted>" -ClientId "<redacted>" -CertificateThumbprint "<redacted>" Connecting to Microsoft Graph (beta) as an application... Connected. Querying /deviceManagement/windowsQualityUpdatePolicies Found 3 Windows quality update policy(ies). Policy: Pilot - Quality and QMR Hotpatch enabled : True security / monthly : automatic, defer 2 day(s) nonSecurity / monthly : manual security / outOfBand : manual quickMachineRecovery / monthly : automatic, defer 0 day(s) # Healthy: pilot ring, fast automatic QMR so boot-failure fixes reach test devices first. Policy: Production - Quality and QMR Hotpatch enabled : True security / monthly : automatic, defer 9 day(s) nonSecurity / monthly : manual security / outOfBand : manual quickMachineRecovery / monthly : manual # Healthy: production stays manual on QMR pending pilot signal, matches the recommended posture. Policy: Legacy - Broad Ring (REVIEW NEEDED) Hotpatch enabled : False security / monthly : manual nonSecurity / monthly : manual security / outOfBand : manual quickMachineRecovery / monthly : automatic, defer 0 day(s) WARNING: Policy 'Legacy - Broad Ring' has Quick Machine Recovery set to AUTOMATIC with a 0-day deferral, but monthly security updates on the same policy are still MANUAL. This is an unusual combination worth a second look - QMR is deploying faster than your own security patches on this policy. Remember: the approval method itself cannot be edited on this policy. If this was not intentional, plan a replacement policy rather than trying to fix it here. Summary: 3 policies audited, 1 flagged for review. # Exit code 1 (flagged policy found).

Run it with -CsvPath to write one row per policy per update-category setting, so you can track approval-method configuration over time or feed it into whatever compliance reporting your team already maintains.

References

Microsoft MVP community deep-dives

Author	Post	What it adds
Anoop C Nair (MVP)	Microsoft Expands Windows Autopatch With Quick Machine Recovery Controls	Portal-view screenshots of the QMR deployment and reporting dashboards, plus a Prevention / Management / Recovery framing of the feature that is a useful mental model alongside this post's approval-method decision table

    
    PowerShell — companion script
  
Download it from Imran76Awan/Windows-Patching-Scripts — no sign-in required. It is read-only: it queries Graph with GET only and never changes a policy. Validate it in your own tenant before relying on the output.

      ●
      Get-AutopatchQualityUpdatePolicyAudit.ps1
      — Audits every Windows quality update policy's approval method and deferral, per update category including QMR
    
      View all scripts on GitHub

Windows Autopatch Now Controls Quality, .NET, and Quick Machine Recovery Updates — What Changes For Admins