A Safeguard Hold Is Blocking Your Feature Update: Finding Which One, and Why the Opt-Out Is Not a Fix

One device in a ring of two thousand refuses to take the feature update. Every other machine moved to the new Windows release weeks ago. This one sits on the old build. Windows Update reports that the device is up to date. The update ring is correct. The device is compliant, healthy, and checking in. And yet the update is simply never offered.

That device is almost certainly under a safeguard hold. Microsoft found a known-bad combination of app, driver or hardware on machines like it, and told the Windows Update service to stop offering the new release to those machines until the issue is fixed. It is a deliberate protection. It looks exactly like a broken client.

This post explains the whole chain: what a safeguard hold is, how the Microsoft Compatibility Appraiser feeds it, why the whole mechanism silently dies if diagnostic data is turned off, where the eight-digit hold ID appears on the device and in the portal, and what the documented opt-out actually does. That last part matters, because the opt-out is not a fix, and deploying it fleet-wide is one of the worst things you can do to a Windows estate.

The problem: the feature update is never offered, and nothing on the device says why

Start with what the help desk actually sees. A user reports that their machine is on an older Windows release than their colleagues. An engineer checks Windows Update. It says the device is up to date. The engineer clicks Check for updates. Quality updates and drivers arrive normally. The feature update does not.

Nothing is broken. The device asked the Windows Update service for the new release, and the service declined to offer it.

Here is the first thing to run. This reads the installed release and asks the Windows Update agent what it is currently being offered. It changes nothing.

On a device using plain Windows Update with no Windows Update client policies applied, Microsoft documents a user-facing message in the Settings app: it tells the user the update is on its way but not yet ready for their device, instead of offering a download button. That message is the only hint the platform gives, and most managed devices never show it, because Windows Update client policies suppress that experience entirely.

So on a managed fleet, the user-visible symptom is nothing at all. That is why these tickets get escalated as "Windows Update broken" and then bounced between the patching team and the platform team for a week.

Why it happens: safeguard holds, the compatibility appraiser, and the telemetry they ride on

Take the pieces one at a time, then put them in order.

What a safeguard hold is

Microsoft watches quality and compatibility signals from the Windows population. When it spots a pattern where a specific app, driver or hardware configuration causes a feature update to fail, roll back, lose connectivity, lose data or break something important, and there is no immediate workaround, it applies a hold on the updating service. Devices matching that pattern stop being offered the new release. The hold is released once a fix exists and has been verified in the field. Microsoft also applies holds when a customer, a partner or its own internal validation finds a severe issue.

Two things follow from that description, and both surprise people:

• The hold lives service-side. It is not a setting on your device that you can clear. The device is told nothing except "no update for you".
• The hold is targeted. It applies to devices that look like the broken pattern. That is why one device in a ring is stuck and the rest are fine.

The Microsoft Compatibility Appraiser: the thing that decides what your device looks like

The component that works out whether your device matches a hold pattern is the Microsoft Compatibility Appraiser. Spelled out: it is the inventory-and-assessment engine that Windows uses to judge whether this specific machine can safely move to a specific target release. Microsoft documents that it creates registry entries under the AppCompatFlags subkey and that it runs as a scheduled task under \Microsoft\Windows\Application Experience\.

Here is the chain, in order, from trigger to result:

1. The Microsoft Compatibility Appraiser scheduled task fires, or the servicing stack runs the appraiser during an update scan.
2. CompatTelRunner.exe hosts the run. It loads appraiser.dll (the assessment logic) and aeinv.dll (the application inventory component).
3. The appraiser reads the local inventory of apps, drivers, devices and firmware, and compares it against a compatibility data baseline shipped in the OS and refreshed from Microsoft.
4. It writes its verdict for each known target release into the registry under AppCompatFlags, including a gated status and, if the device is held, a safeguard ID.
5. The Connected User Experiences and Telemetry service (short name DiagTrack) uploads the diagnostic data that lets Microsoft see the pattern across the population and lets your tenant reports show it.
6. The Windows Update agent (wuauserv) scans. The service applies any hold that matches, and the feature update is not offered.

Step 5 is where most real-world failures live, and it is the part people cut without realising what they cut.

The telemetry requirement: no diagnostic data, no safeguard story

This is the single most important prerequisite in the whole feature area, so be precise about it.

Microsoft documents that Windows Update for Business reports require devices to send diagnostic data at the Required level at minimum. Required was previously called Basic. Microsoft recommends Optional on Windows 11 and Enhanced on Windows 10, but only requires Required. Intune's feature update policies carry the same requirement: telemetry must be on, at a minimum of Required, and the Microsoft Account Sign-In Assistant service (wlidsvc) must be enabled and running.

Turn diagnostic data off and the consequences cascade. The appraiser still runs locally, but nothing is reported, so your tenant has no readiness or safeguard data, the device cannot be identified in the reports, and you lose the only supported way to find out which hold is in effect. Microsoft also notes that the reports depend on the services configuration mechanism, sometimes called OneSettings, and that blocking it can make client data in the reports wrong or missing.

The two look-alikes you must rule out first

Before you spend a day on holds, eliminate the two configurations that produce the exact same symptom.

A version pin. The TargetReleaseVersion policy pins a device to a named release. Set it, and the device will never be offered anything newer, regardless of holds. Microsoft's ADMX ships this as Select the target Feature Update version, and it writes a DWORD switch plus a string naming the release. A pin left behind from last year's migration project is the most common false positive in this whole area.

Feature update policy targeting. Microsoft documents that a device managed by Windows Autopatch which is no longer targeted by any feature update policy is not offered any feature update at all, until it is assigned to a new profile, unenrolled from Intune, or removed from feature update management through the Graph API. An empty group assignment produces a permanently stuck device that looks exactly like a hold.

System files and binaries in the flow

These are the binaries that actually do the work. Every one of these was read from a live Windows 11 25H2 device (build 26200.9168); the file descriptions are the ones Windows itself reports.

Services and scheduled tasks

Parent task folder, which is the same on every supported build:

How to verify: GStatus, the hold ID, and the two reports that name it

There are exactly two supported ways to find out whether a device is held: the client-side registry evidence the appraiser writes, and the tenant-side reports. Use both. They answer different questions.

The client-side surface: the registry

Microsoft documents a value called GStatus - gated status - as the indicator of whether a safeguard hold is in effect. It lives in two places. There is a global one under the appraiser's GWX subkey, and a per-target-release one under TargetVersionUpgradeExperienceIndicators, where the subkey name encodes the target release, for example GE24H2 or GE25H2.

Shared parent key for the appraiser output:

Policy keys that produce the same symptom, or turn the mechanism off. Shared parent key:

Here is that read, done properly. This is the client-side check that answers "is this device held, and by what".

The same values in the graphical tool, for anyone who prefers to look before they script. Open Registry Editor (regedit.exe) and browse to the appraiser key.

The Event Viewer surface, and an honest answer about it

Microsoft publishes no event IDs for safeguard holds. Say that out loud rather than inventing some. There is no "hold applied" event to alert on. What does exist is a set of Event Viewer channels for the compatibility infrastructure, and the Windows Update client channel where scan activity lands. Use them for context, not for hold detection.

These channels were enumerated on a live Windows 11 25H2 device with wevtutil el. Channel paths as shown in Event Viewer under Applications and Services Logs:

The log-file surface

When a hold is caused by an app or driver, the same compatibility engine that feeds the hold also writes human-readable findings during a setup compatibility scan. Microsoft documents these paths and the exact strings to search for.

You do not have to attempt a real upgrade to generate these. Microsoft documents a scan-only mode:

The tenant-side surface: the reports that name the hold

The registry tells you this device is held. The reports tell you how many devices are held and by what. Microsoft documents two report families.

Windows Update for Business reports present a list of active safeguard holds and identify each one by an eight-digit identifier. That identifier is what you search for on the Windows release health dashboard, under Known issues for the relevant release, to find out what the hold is actually about.

Intune's compatibility reports are the other route, and they are the faster one for most admins. There are two, and both are generated on demand.

1. Sign in to the Microsoft Intune admin center.
2. Go to Reports > Device management > Windows updates, then select the Reports tab.
3. Select Windows Feature Update Device Readiness Report.
4. Select Select Target OS and choose the exact release you plan to deploy. The insights are specific to that target, so a mismatch gives you a misleading answer.
5. Select Select Scope (Tags) and pick the devices in scope. Optionally refine by Ownership and Readiness status.
6. Select Generate report and wait. It can take several minutes and you are notified when it finishes.
7. Find your device, select its name, and open the Other tab in the details flyout. Microsoft documents that compatibility risks tied to device configuration and settings - including some safeguard holds - land on that tab rather than under Applications or Drivers.

For the fleet-wide view, use the sibling report:

1. From the same Reports tab, select Windows Feature Update Compatibility Risks Report.
2. Select Select Target OS, optionally refine by Asset type and Risk status, then select Generate report.
3. Look for rows with an Asset type of Other and a safeguard description in the Issue column. Microsoft is explicit that a safeguard entry is not a real installed asset - it is a placeholder that tags the apps or drivers in your environment carrying the safeguard.
4. Select the number under Affected devices to see which machines are implicated.

Before either report will show anything, the tenant has to be allowed to see Windows diagnostic data at all:

A device that shows Unknown as its Readiness status is the tell. Microsoft's own guidance for that value is to check that the device is properly configured to send Windows diagnostic data.

The fix: clear the actual blocker, or opt out only inside a validation ring

Work in this order. The order matters, because steps one and two stop most of these tickets dead.

1. Rule out a version pin. Read TargetReleaseVersionInfo. If it names the release the device is already on, there is no mystery and no hold - remove or retarget the pin.
2. Rule out policy targeting. Confirm the device is actually in scope of a feature update policy. A device that has fallen out of every feature update profile is not offered feature updates at all.
3. Confirm the hold on the client. Read GStatus. Zero means held.
4. Get the safeguard ID from GatedBlockId, or from the eight-digit identifier in Windows Update for Business reports.
5. Look the ID up on the Windows release health dashboard, under Known issues for the target release. That page tells you what the issue is and, once fixed, moves to Resolved issues.
6. Remediate the cause - update the driver, update or remove the app, change the setting. When Microsoft verifies the fix, it releases the hold and the offer resumes on its own. No client-side action is needed to "clear" a hold.
7. Check for a stale hold. If the dashboard says the issue is resolved but the device still reports the ID, treat it as a data-refresh problem and check TLS inspection on the compatibility endpoints.

The documented opt-out, and exactly what it is for

There is one supported way to make a device ignore safeguards: the disable-safeguards policy. Microsoft documents it as the Update/DisableWUfBSafeguards CSP for MDM, and Disable safeguards for Feature Updates in Group Policy. It applies to Windows Update client policies devices running Windows 11, or Windows 10 version 1809 or later with the October 2020 security update.

The exact registry surface, confirmed against the ADMX file Microsoft ships in C:\Windows\PolicyDefinitions\WindowsUpdate.admx:

Group Policy: the safeguard opt-out

The setting lives under the node that governs which updates Windows Update will offer. Full path, confirmed from the ADMX and its English-language strings:

1. Open the Group Policy Management Editor against a GPO scoped to your validation ring only. Not to a production ring. Not to Authenticated Users.
2. Expand Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update.
3. Double-click Disable safeguards for Feature Updates.
4. Select Enabled, then select OK. This writes DisableWUfBSafeguards = 1.
5. On a target device, run gpupdate /target:computer /force, then confirm the value landed in the WindowsUpdate policy key.
6. When validation is finished, set the policy back to Not Configured and confirm the value is gone. Disabled and Not Configured both restore safeguards, but Not Configured leaves the cleanest key.

While you are in the same editor, the diagnostic data level lives one node over. Without this at Required or above, none of the verification in this post works.

1. Expand Computer Configuration > Policies > Administrative Templates > Windows Components > Data Collection and Preview Builds.
2. Double-click Allow Diagnostic Data.
3. Select Enabled, then choose at least Send required diagnostic data. Microsoft recommends Send optional diagnostic data on Windows 11.
4. Optionally enable Allow device name to be sent in Windows diagnostic data in the same node, so held devices appear by name in the reports rather than anonymously.
5. Select OK, then confirm AllowTelemetry in the DataCollection policy key.

Intune: the same two settings in the Settings Catalog

Both settings exist in the Settings Catalog, so there is no CSP-only or GPO-only trap here. The safeguard opt-out sits under the Windows Update for Business category.

1. Go to Devices > Configuration and select Create > New Policy.
2. Set Platform to Windows 10 and later and Profile type to Settings catalog, then select Create.
3. Name the profile something that screams what it does - for example WUfB - Safeguards DISABLED - validation ring only. Future you will thank present you.
4. On the Configuration settings tab, select Add settings.
5. In the settings picker, browse to the Windows Update for Business category and select Disable WUFB Safeguards.
6. Close the picker and set the toggle to Enabled. This maps to ./Device/Vendor/MSFT/Policy/Config/Update/DisableWUfBSafeguards with a value of 1.
7. Assign the profile to a small, named validation group. Never to All devices.
8. Select Review + create, then Create.
9. When validation is done, delete the profile. Do not leave it assigned to an empty group "in case".

The diagnostic data level is in the same catalog, under the System category:

1. Create or edit a Settings catalog profile as above.
2. Select Add settings, browse to the System category, and select Allow Telemetry.
3. Choose at least Basic - the value Microsoft now calls Required, documented as 1. Choose Full (Optional, documented as 3) if your privacy posture allows it, which is Microsoft's recommendation for Windows 11.
4. Optionally add Allow Device Name In Diagnostic Data from the same category and set it to Allowed.
5. Assign, review and create. Then confirm on a device that the level is actually in force - remembering the MDM value-name gotcha above.

If you configure by OMA-URI instead of the catalog, the two paths are:

Defender, ASR and endpoint security: honestly, not applicable

This topic does not touch Microsoft Defender Antivirus, attack surface reduction rules, exploit protection, Windows Defender Application Control or the firewall. There is no Endpoint Security profile that affects safeguard holds, and no ASR rule that blocks or unblocks one. If you came here looking for a Defender setting, there is not one, and any guide that offers you one is guessing.

There is one genuine security-tooling interaction, and it is the network kind rather than the endpoint kind. Microsoft documents that TLS inspection of adl.windows.com, settings-win.data.microsoft.com and settings.data.microsoft.com is the most common cause of a device carrying an outdated hold. If your organisation runs a TLS-inspecting proxy or next-generation firewall, those endpoints belong on the bypass list. That is a network security change, not an endpoint security one - but it is the security control most likely to cause this problem.

Proof it worked: reading a real device report

Reading eight registry locations by hand on every escalation gets old. The companion script for this post does the whole sweep read-only. It reports the diagnostic data level actually in force from both the Group Policy and MDM surfaces, every Application Experience task with its state and last run time, every appraiser gated status with its safeguard ID, both version-pin surfaces, whether the opt-out is set, the appraiser binaries on disk, and whether Windows Update is currently offering a feature update.

It sets nothing. It cannot set the opt-out and it cannot change the diagnostic data level, by construction - there is no write path in it at all.

Below is a genuine run on the Windows 11 25H2 reference device, elevated, with the user name replaced. Nothing else was edited.

Now the verdict block, which is the part you would collect at scale.

That last note is the real lesson of this whole post. The symptom was "feature update not offered". The cause was a version pin, not a safeguard hold. The two are indistinguishable from the user's chair and from the Windows Update page, and only distinguishable by reading the right registry values.

For a device that genuinely is held, "proof it worked" looks different, because you do not clear a hold from the client. You remediate the cause, wait for Microsoft to verify the fix and release the hold, and then confirm three things in order: GatedBlockId no longer names the ID, GStatus reads 2 on the target key, and the Windows Update search returns the feature update. If the first two flip but the third does not, you are back to version pins and policy targeting - not to safeguards.

References

Microsoft official

• Safeguard holds for Windows - the mechanism, the GStatus and GatedBlockId registry values, the eight-digit identifier, and the TLS-inspection cause of stale holds.
• Opt out of safeguard holds - the disable-safeguards policy, its supported operating systems, and Microsoft's cautions.
• Policy CSP - Update - DisableWUfBSafeguards and TargetReleaseVersion: OMA-URIs, allowed values, registry key and Group Policy mapping.
• Policy CSP - System - AllowTelemetry and AllowDeviceNameInDiagnosticData: values, registry key and Group Policy mapping.
• Prerequisites for Windows Update for Business reports - the Required diagnostic data minimum, the device-name policy, and the endpoints devices must reach.
• Use compatibility reports for Windows updates in Intune - the device readiness and compatibility risks reports, the safeguard placeholder rows, and the reporting latency.
• Manage Windows feature updates in Intune - the telemetry and wlidsvc requirements, and why an untargeted device is offered nothing.
• Use the Windows Setup compatibility scan logs to identify blocking issues - the CompatData and APPRAISER_HumanReadable log paths, the exact search strings, and the appraiser scheduled task.
• Windows release health - where you look up a safeguard ID under Known issues and Resolved issues for a release.

Community deep dives

Both of these were fetched and confirmed on topic while writing this post.

One closing thought. Safeguard holds are the only part of Windows Update that actively protects you from Microsoft's own release quality, and the opt-out is the only knob most admins ever learn about. Learn the other four - GStatus, GatedBlockId, the release health dashboard, and the readiness report - and you will almost never need the knob.