Why this device cannot upgrade to Windows 11: reading the real hardware gate instead of guessing

A user opens Windows Update and sees a line telling them the PC does not currently meet Windows 11 system requirements. That single sentence is the entire diagnostic output. There is no field naming the check that failed, no value, no code. So the guessing starts.

Some admins order replacement laptops. Some paste a registry bypass from a forum without knowing what it does to their support position. Almost nobody reads the check that actually failed, even though Windows wrote it to disk in at least three places before it showed that message.

The problem: one message, several independent gates

Windows 11 has a published list of minimum hardware requirements. Every item on that list is checked separately. Any one of them can block the upgrade on its own.

Here is the documented list, straight from Microsoft's Windows 11 requirements article, with the way to read each one on a live device.

Two of those rows cause almost all of the confusion in an enterprise fleet, and both are worth spelling out before anything else.

The first is the processor row. "Compatible 64-bit processor" is not a speed test. It is a lookup against a list Microsoft publishes per Windows 11 release, on separate pages for AMD, Intel and Qualcomm parts. A four-core, 3 GHz, 64-bit chip can fail purely because its model is not on the list for the release you are deploying.

The second is the firmware row. It says "UEFI, Secure Boot capable". It does not say Secure Boot enabled. Microsoft's own Secure Boot support article is explicit: "the requirement to upgrade a Windows 10 device to Windows 11 is only that the PC be Secure Boot capable by having UEFI/BIOS enabled". A device with Secure Boot switched off in firmware still satisfies the gate, as long as the firmware supports Secure Boot at all.

So the real question is never "is this device eligible". It is "which gate failed". Windows answers that question in writing, and the next section explains who writes it.

Why it happens: the appraiser decides, not Setup

Two different components evaluate Windows 11 hardware requirements, at two different times, and they write to two different places. Confusing them is the root of most bad troubleshooting here.

The chain, in order. A scheduled task called Microsoft Compatibility Appraiser runs compattelrunner.exe, loading appraiser.dll. The appraiser inventories the device, compares it against a compatibility data file it refreshes from Microsoft, and writes its verdict into the registry under AppCompatFlags. Windows Update reads that verdict to decide whether to offer the upgrade at all. Only later, if an upgrade is actually attempted, does Windows Setup run its own separate system-requirement action and write an XML compatibility report.

That means a device can be blocked without Setup ever running. The message in Windows Update is the appraiser's answer, not Setup's.

The useful part for us is that Microsoft publishes the specific reason codes. In the Configuration Manager readiness dashboard documentation, these conditions are listed as making a device Red for Windows 11.

Read that table again with an operations hat on. It is a complete decode of the message users see. If you can read RedReason off a device, you never have to guess which gate failed, and you never have to replace a laptop that only needed a firmware toggle.

Microsoft also documents a second, separate reason a device is not offered the upgrade, which is not a hardware gate at all: a safeguard hold. A safeguard hold is Microsoft blocking a specific feature update on devices with a known issue, such as a broken fingerprint sensor driver. The documented registry marker for it is GStatus, where 2 means no hold is in effect and 0 means a hold is in effect. A device can be perfectly eligible on hardware and still not be offered the upgrade because of a hold. Those two situations produce similar user complaints and completely different actions.

The binaries in the flow

Naming the actual files makes the chain concrete, and lets you confirm each one exists rather than trusting a diagram.

On the Windows 11 Enterprise device used to write this article, every file above was present except appraiser.sdb in System32, which lives in C:\Windows\Panther instead. That is worth knowing before you write a detection rule against a path you have not checked.

How to verify: read each gate directly

There are four surfaces worth reading, in this order: the registry verdict, the live hardware state, the Setup logs, and the XML compatibility report. Start with the registry, because it is the fastest answer.

1. The registry verdict

Everything in this section lives under one parent key.

That last distinction matters more than it looks. The documented values are safe to build detection logic on. The undocumented ones can change in any monthly update without notice, so read them for diagnosis and do not gate a deployment on them.

A blocked device shows the same value names with different data, for example UpgEx of Red and RedReason of Tpm. That is the entire diagnosis in two values.

2. The live hardware state

The registry tells you what the appraiser concluded. The commands below tell you what is actually true right now, which is what you need before touching firmware. Each one reads only; none of them change anything.

3. The Setup logs

If an upgrade was actually attempted, Setup left its own trail. Microsoft documents the log locations by phase; these are the ones that matter for hardware gates.

Here is what a healthy requirement scan looks like. These are genuine lines from C:\Windows\Panther\setupact.log on the device used for this article, with nothing invented.

The XML that scan produces is the clearest artefact of the lot. Each check appears as a HardwareItem with a HardwareType name and a BlockingType. On this device the Secure Boot item reads exactly like this, again real and untouched apart from line wrapping:

BlockingType="None" is the healthy reading. A gate that failed carries a blocking value instead, and the HardwareType name tells you which check it was. Microsoft does not publish the full list of HardwareType names, so treat the names you find as observed rather than documented, and use them to point at a gate rather than as a contract.

4. Event Viewer: an honest N/A

Microsoft publishes no Event IDs for Windows 11 hardware-requirement appraisal. There is no event to look for that says "TPM gate failed". Saying so plainly is more useful than inventing one, so here is the substitute: the channels that exist, and what they are actually good for.

Confirm this yourself rather than trusting the table, with wevtutil el piped into a filter, then Get-WinEvent -ListLog on any channel you care about to see whether it is enabled and how many records it holds. If a channel is enabled with zero records, the answer to "why is there nothing in Event Viewer" is simply that nothing writes there for this scenario.

5. Services and scheduled tasks

The appraiser is driven by a scheduled task, and its data upload depends on one service.

Read them with Get-ScheduledTask -TaskPath '\Microsoft\Windows\Application Experience\' and Get-Service DiagTrack. On the test device the task name is Microsoft Compatibility Appraiser Exp, which is a reminder that task names vary by build and that you should enumerate the path rather than hard-code a task name.

The fix: act on the gate that actually failed

Now that you can name the failing gate, each one has a different answer. Only one of them is "buy new hardware".

Getting into firmware without a boot-key race

Microsoft documents a route into UEFI firmware settings from inside Windows, which is far more reliable than telling a user to hammer F2 at boot.

From there, the two settings to look for are the TPM (PTT or fTPM) and the boot mode, changing it from Legacy BIOS or CSM to UEFI. Microsoft's Secure Boot article calls out that same boot-mode change explicitly.

Converting an MBR system disk

If the disk is MBR, switching firmware to UEFI on its own produces an unbootable machine. Convert first. MBR2GPT.EXE ships in Windows\System32 on every supported Windows version and can validate without changing anything.

The bypass question, answered honestly

Two registry approaches circulate for installing Windows 11 on ineligible hardware. Being precise about their documentation status matters more here than anywhere else in this article, because the consequence is your support position.

Two observations from the live device, offered as facts rather than advice. The MoSetup key exists by default on this Windows 11 Enterprise build, and it is empty, which contradicts the common instruction that you must create the key yourself. And LabConfig does not exist on a running OS at all, because it is an install-time construct rather than something a managed device carries.

Group Policy: no policy makes a device eligible

Say this plainly, because it saves hours of searching: there is no Group Policy setting, no CSP and no Intune configuration profile that makes an ineligible device eligible for Windows 11. Eligibility is a hardware fact evaluated on the device. Policy controls what is offered, not what is possible.

Two policies genuinely matter around this problem, and both are in the same ADMX file, WindowsUpdate.admx.

To reach the safeguard policy in the Group Policy Editor:

1. Run gpedit.msc on the device, or open your domain GPO in the Group Policy Management Editor.
2. Expand Computer Configuration.
3. Expand Administrative Templates.
4. Expand Windows Components.
5. Expand Windows Update.
6. Select Manage updates offered from Windows Update.
7. Open Disable safeguards for Feature Updates and set it to Enabled only for validation devices.
8. In the same folder, Select the target Feature Update version controls which release is offered, using the product name and version fields.

To make the appraiser's verdict visible to your reporting at all, diagnostic data has to be on. That is a separate policy:

1. Open the Group Policy Management Console or gpedit.msc.
2. Expand Computer Configuration, then Administrative Templates, then Windows Components.
3. Select Data Collection and Preview Builds.
4. Open Allow diagnostic data, which is named Allow telemetry on Windows 10 version 1809 and earlier.
5. Choose the level. The documented values are 0 for diagnostic data off, 1 for Required, 2 for Enhanced and 3 for Optional.
6. Set at least Required if you want readiness reporting to work. Microsoft's Configuration Manager readiness dashboard prerequisites state that telemetry should be enabled at basic level and hardware inventory enabled on clients.

Intune: the same reality, plus a report worth using

The two Windows Update policies above exist in the Settings Catalog and as CSPs. The safeguard one is ./Device/Vendor/MSFT/Policy/Config/Update/DisableWUfBSafeguards, where 0 is the default and means safeguards are enabled, and 1 means upgrades deploy without blocking on safeguards. Diagnostic data is System/AllowTelemetry.

To create that profile:

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices, then Configuration.
3. Select Create, then New policy.
4. Platform: Windows 10 and later. Profile type: Settings catalog.
5. Select Add settings and search for Disable WUfB Safeguards, or for Allow Telemetry for the diagnostic data setting.
6. Set the value, assign the profile to a small validation group only, and save.

The genuinely useful Intune surface for this problem is not a policy at all. It is a report. Endpoint analytics has a Work from anywhere report whose Windows tab gives a device-by-device view of Windows 11 hardware readiness. The Windows 11 readiness status column shows Capable, Not capable, Upgraded or Unknown, and the Windows 11 readiness reason column names the specific hardware requirements that are not met. Selecting Windows on the Overview page shows a chart of the top hardware blockers across the tenant.

That chart is the difference between "we need a hardware refresh" and "four hundred devices need a firmware toggle". Microsoft's documentation also notes that devices showing Unknown are usually inactive rather than broken, so check last check-in time before you treat them as a problem.

Defender and security policy: N/A, and why

This topic does not touch Microsoft Defender, attack surface reduction, exploit protection, WDAC or the firewall. No Endpoint Security profile influences hardware eligibility, and no ASR rule blocks an upgrade offer. The overlap people expect is TPM and Secure Boot, but those are firmware facts read by the appraiser, not Defender features. Saying N/A here is more useful than inventing a connection, and if a colleague insists Defender is involved, the RedReason value on the device will settle it.

Proof it worked: a real read-only gate report

The companion script for this article, Get-Windows11ReadinessGate.ps1, evaluates every documented gate separately and prints the measured value beside the requirement. It writes nothing. It cannot set a bypass value, cannot touch firmware and cannot change a service.

The output below is a genuine run on the Windows 11 Enterprise device used to write this article, with only the device name replaced. It exited with code 0, and the same script parsed with zero errors on Windows PowerShell 5.1 and PowerShell 7.6 and produced the same verdicts on both.

Three design decisions in that script are worth borrowing for any readiness check you write yourself.

It reports the CPU supported-model gate as MANUAL, not PASS. There is no local database of supported processors to compare against, so claiming a pass would be a guess dressed as a result. It prints the family, model and stepping so you can compare against the published list for the release you are deploying.

It distinguishes a read failure from a genuine absence. If Win32_Tpm returns nothing, the script asks Get-Tpm for a second opinion. Only when that confirms TpmPresent=False does it record a real FAIL. Otherwise the gate is READ-FAILED and the whole run exits 1, because a device wrongly reported as having no TPM is how unnecessary hardware orders get raised.

It treats Confirm-SecureBootUEFI returning False as a pass, with a note explaining why, because the documented requirement is capable and not enabled.

References

• Windows 11 requirements - the minimum hardware requirements, including the TPM 2.0 and "UEFI, Secure Boot capable" wording.
• Windows Processor Requirements - the per-release supported AMD, Intel and Qualcomm processor lists.
• Manage Windows 11 readiness dashboard - the documented UpgEx colours and the full list of RedReason values for Windows 11.
• Safeguard holds for Windows - the GStatus, GatedBlockId and GatedBlockReason registry values and their meanings.
• Opt out of safeguard holds - the Update/DisableWUfBSafeguards CSP and the "Disable safeguards for Feature Updates" policy, with Microsoft's cautions.
• Log files and resolving upgrade errors - the Setup log locations by phase and the documented search strings.
• Get-Tpm and Win32_Tpm class - the TPM properties, including the documented SpecVersion format.
• Confirm-SecureBootUEFI - the documented True, False and "Cmdlet not supported on this platform" behaviours.
• MBR2GPT - syntax, disk prerequisites, return codes and the warning that conversion cannot be undone.
• Work from anywhere report in endpoint analytics - the Windows 11 readiness status and readiness reason columns.
• Plan for Windows 11 - determining eligibility, and the statement that Windows Update client policies stop ineligible devices being offered the upgrade.
• Windows 11 on devices that don't meet minimum system requirements - the support and update-entitlement statements quoted above.
• IsProcessorFeaturePresent - the documented constants used to read SSE2, NX and CMPXCHG16B.

No community or MVP deep-dive is cited here. I looked for one specifically on reading the Windows 11 hardware gate and could not verify a match on topic, and a fabricated citation is worse than an omitted table.