What TPM 2.0, Secure Boot and Supported CPUs Really Mean: The Hardware Requirements Behind the Windows 11 Upgrade Check

The Windows 11 upgrade experience performs a gate check, not a performance test. It does not measure how fast your processor is, how much RAM you have beyond the minimum line, or whether your SSD is quick — it verifies that a specific set of security and platform components is present and active, and it treats each item as an independent pass/fail condition. A 2019 gaming PC with a ninth-generation Core i7, 32 GB of RAM and a 1 TB NVMe drive can therefore be blocked by exactly one missing piece: a TPM module that Windows cannot see. The hardware is more than capable; the check simply does not ask “capable” — it asks “does this specific component exist, at this specific version, in this specific state?”

There are practical reasons for the gate. Windows 11 builds a larger share of its security model on hardware: features such as Virtualization-Based Security, Credential Guard and Pluton-based sign-in assume that keys can be created and used inside a tamper-resistant module (the TPM) and that the boot chain starts from firmware whose loaders were verified by signature (Secure Boot). Microsoft also ties its driver and feature-update support commitment to a published set of processor generations, because those chips ship with the instruction-set features Windows 11's mitigations rely on. The result is a requirements list where every line has an engineering rationale — which is why “my PC is fast” is not an answer to any line of it.

The second reason the check surprises people is that several failures are configuration problems, not hardware problems. The most common one: a machine that has a TPM in its processor firmware (Intel PTT or AMD fTPM) but with that feature switched off in the firmware settings. Windows then reports “no TPM”, even though the capability is physically present and would be available after a single firmware setting change — reversible, safe, and inside Microsoft's supported configuration. The same pattern applies to Secure Boot on boards that support it but ship with legacy/CSM boot enabled. Before you conclude that your hardware is too old, this guide shows how to tell those fixable cases from the ones where the component genuinely does not exist.

How to use this guide: if you just want answers about your PC, jump straight to Part 2 (section 5 onward) and run the checks in order — TPM first, then Secure Boot/boot mode, then CPU, then RAM and storage — because those are the four lines that actually exclude machines. If a check fails, Part 3 maps the failure to its most likely cause and the safest next step. Part 4 is where decisions get made: which fixes are worth doing, what an unsupported install would cost you, and how to prepare (and how to recover) before touching anything that affects boot or encryption. The full 30-topic tutorial collection at the end links out to deeper dives for each subject.

It is worth separating the six requirement lines from each other before checking them, because they fail in different ways and their fixes have very different risk profiles. The processor line is a membership test: your exact CPU model must appear on Microsoft's published support lists for Intel and AMD (with version-specific lists maintained for newer releases). It cannot be fixed by any setting — only by replacing silicon. The TPM line is a presence-plus-version test: a TPM 2.0 module must exist and be reachable, but it may be hiding as a disabled firmware feature. The firmware line has two halves — the system must boot in UEFI mode rather than legacy BIOS mode, and the firmware must be capable of Secure Boot; “capable” is the key word, because Windows 11 requires the capability even when Secure Boot itself is switched off. Memory (4 GB) and storage (64 GB) are simple thresholds, and the graphics/display line (DirectX 12 with a WDDM 2.x driver, 720p display) is the one that almost never fails on a machine new enough to be considered for Windows 11.

Two subtleties cause most of the confusion in practice. First, capability versus state: Secure Boot can be capable-but-disabled, and a firmware TPM can be present-but-off. Both are fixable from firmware settings without changing hardware; both are reversible; and both keep you inside Microsoft's supported configuration. Second, total versus available: the storage requirement is about the disk's capacity floor, but an in-place upgrade additionally needs tens of gigabytes of free space to stage its files — a 64 GB drive that technically passes can still fail the upgrade for lack of room. The table below pairs each requirement with how to verify it, the failure you are most likely to meet, and the safe next action when it fails.

Notice the asymmetry in the last column: three of the six lines (TPM, Secure Boot/CSM, and RAM) have cheap, reversible fixes that do not change what hardware you own; one line (CPU) has no fix short of new silicon; and two (storage capacity, graphics) are usually non-issues. That asymmetry is the entire logic of this guide — section 14 makes it explicit as a rule for deciding what to do.

A Trusted Platform Module (TPM) is a small cryptographic coprocessor whose defining property is that the keys it creates never leave it in usable form. When Windows asks the TPM to generate a key pair, the private half stays sealed inside the module: operations are performed on it internally, and only results — signatures, decrypted blobs, attestations — come out. That makes the TPM a root of trust: even software with full administrative rights cannot simply read the master keys off disk the way it can any other file. Windows 11 leans on that property for BitLocker drive encryption (the volume-encryption key is wrapped by a TPM-resident key), Windows Hello biometric and PIN data, device encryption on consumer editions, smart-card and certificate scenarios, and the platform attestation that Virtualization-Based Security uses to decide whether memory-integrity features can be trusted.

The version number matters because TPM 1.2 and TPM 2.0 are different specifications with different capabilities. TPM 2.0 supports the algorithms and key hierarchies Windows 11's security features expect (notably SHA-256-based operations and the attestation structures VBS uses), while TPM 1.2 — common on machines from roughly before 2016 — predates them. That is why the requirement reads “TPM version 2.0” rather than just “a TPM”: a machine with a working 1.2 module still fails this line, and no setting changes that. When you check your own machine in section 5, the spec version is the number that decides — not whether a chip exists at all.

On most PCs from the last several years, the TPM is not a separate chip soldered to the board but a firmware TPM implemented inside the processor: Intel calls it Platform Trust Technology (PTT), AMD calls it fTPM. Functionally they provide the same TPM 2.0 interface to Windows; they differ in where you find their on/off switch, which lives in the motherboard firmware under names that vary by manufacturer and firmware version — “Intel PTT”, “fTPM support”, “Security Device”, “TPM On/Off” are all seen on real boards. This is the single most important fact for diagnosis: when Windows reports that no TPM is present, the hardware may be fully capable and merely switched off in firmware. The distinction between physically absent, present but disabled, and present but not detected drives everything in section 12.

UEFI (Unified Extensible Firmware Interface) is the modern replacement for the decades-old BIOS firmware interface. Where legacy BIOS hands control to a small bootloader read from a fixed disk location with no verification, UEFI establishes a chain of trust: the firmware itself verifies that each stage of the boot process — its own drivers, the bootloader, and ultimately the operating system loader — carries a valid digital signature before executing it. That verification mechanism is Secure Boot. It works through a set of signed certificates stored in firmware variables (the platform key, key exchanges, and signature databases): only software whose signature chains to a trusted key gets executed. The practical effect is that very old boot-stage malware — the kind that infects the master boot record or bootloader before Windows ever loads — cannot survive a reboot on a machine with Secure Boot enabled, because the firmware refuses to run code it cannot verify.

Three consequences of this model matter for the compatibility check. First, Secure Boot only exists inside UEFI — there is no Secure Boot in legacy BIOS mode — which is why the requirement is written as “UEFI, Secure Boot capable”: a machine must boot in UEFI mode and its firmware must support the signature-verification feature. Second, “capable” and “enabled” are different states. Windows 11 can be installed on a UEFI machine with Secure Boot switched off, so a board that supports the feature but ships with it disabled still qualifies — enabling it later is a supported, reversible configuration change. Third, many boards from the transition era (roughly 2012–2018) include a CSM (Compatibility Support Module) that emulates legacy BIOS behaviour so older operating systems can boot; on some of those boards Secure Boot cannot be enabled while CSM is active, because the two boot models are mutually exclusive. That interaction — not any mystery in Windows itself — is why “Secure Boot unavailable” sometimes means “disable legacy/CSM boot first”, and it is the reason the switch deserves preparation rather than a quick toggle: changing boot mode on an existing installation can leave it unbootable if the disk's partition layout (MBR versus GPT) does not match the new mode, which is exactly what section 17 prepares for.

What Secure Boot does not do is worth stating plainly, because it stops people over-trusting it: it is a boot-time signature check, not antivirus. It verifies that the early boot chain is signed by trusted keys; it does not scan files you download, and it does not protect against malware that runs after Windows has started. And on modern machines the trust databases are maintained by the firmware vendor and Microsoft's certificate-servicing process, so there is nothing for a typical user to manage — your job in this guide is only to know which of the three states your machine is in: Secure Boot enabled, capable but disabled (fixable from firmware), or not supported by the firmware at all (a platform limit). Section 6 shows how to determine which one applies, and section 12's ordered diagnosis covers what to do in each case.

Start with the graphical tool, because it gives you the answer in plain language and also tells you whether Windows can talk to the module at all. Press Win+R, type tpm.msc and press Enter — this opens the Trusted Platform Module management console. In the left pane select your computer name, then read the right pane: “Spec version” is the number that matters (you need 2.0), and the status line should say the TPM is ready for use. If the console instead shows a message that no TPM was found, or that the service cannot be reached, do not conclude the hardware is absent — that is the “present but disabled / not detected” case, and section 12 walks through it in order.

Confirm the same facts from PowerShell, because the command-line view is what scripts (and the report in section 10) will use, and it exposes one extra detail — whether the module is actually ready: open a normal PowerShell window (no administrator rights are needed for these read-only commands) and run:

Get-Tpm | Format-List TpmReady, TpmVersion, PhysicalPresence

TpmReady           : True
TpmVersion         : 2.0
PhysicalPresence   : NotPresent

If Get-Tpm is inconclusive on your Windows version, the underlying WMI/CIM class gives the raw firmware-reported spec version directly from the TPM driver. Run this in the same window:

$t = Get-CimInstance -Namespace root\CIMV2\Security\MicrosoftTpm -ClassName Win32_Tpm
if ($t) { $t.SpecVersion; $t.IsEnabled_InitialValue } else { "No Win32_Tpm instance — TPM not exposed to the OS" }

Interpret the three outcomes as distinct facts: (a) version 2.0 and ready — this requirement passes, move on; (b) a TPM is detected but reports version 1.2 — the module exists but is the wrong generation, no setting fixes that; (c) nothing is detected — either there is genuinely no TPM hardware, or there is one (often a firmware TPM) that is disabled in firmware settings or not yet handed to Windows. Only case (c) has a realistic fix path on many machines, and only after checking the firmware menu — which is why section 12 starts there rather than with any registry hack.

The single most informative screen for this requirement is System Information. Press Win+R, type msinfo32 and press Enter, then read the System Summary pane: the “BIOS Mode” line tells you which boot world your firmware is currently in (UEFI or Legacy), and the “Secure Boot state” line shows one of three values — Enabled, Disabled, or Unsupported. Those two lines together answer the whole requirement: UEFI mode plus Secure Boot enabled is a clean pass; UEFI mode plus Secure Boot disabled still meets Windows 11's bar (capability is what is required), and it is a safe firmware change to enable it later; Legacy mode fails the requirement outright, because Secure Boot cannot exist in that boot model at all. A board reporting “Unsupported” while in UEFI mode has firmware that simply lacks the feature — a platform limit, not a setting.

For a scriptable answer, PowerShell ships a dedicated cmdlet for exactly this question:

Confirm-SecureBootUEFI

Know the limits of each method before trusting them. msinfo32 reports the state Windows currently sees, which is authoritative for “what mode am I in right now” — but it cannot tell you whether a legacy-mode board would support Secure Boot if converted, because that capability lives in firmware menus, not in the running OS. Confirm-SecureBootUEFI answers only the enabled/disabled question and says nothing about boot mode. And both can look “fine” on a machine whose firmware is mid-change (for example, after a BIOS update that reset settings). So the practical rule: use msinfo32 as the primary source for the two lines above, use the cmdlet to confirm the enabled state from scripts, and when the two disagree — or when you are about to change anything in firmware — re-read both after the next reboot. The ordered diagnosis for each failure mode is in section 12, and the preparation required before touching boot mode is in section 17.

The CPU check is the one requirement you cannot fix with a setting, so get the identification exactly right before drawing conclusions. The trap is vague labels: “Intel Core i7” spans more than a decade of incompatible generations — a 2015 seventh-generation i7 fails while a 2019 eighth-generation i7 passes — and “AMD Ryzen 5” does the same across several families. What you need is the full model string, for example “Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz” or “AMD Ryzen 5 2600 Six-Core Processor”. Three built-in places show it: Settings → System → About (the “Processor” line — the same screen also confirms RAM and system type); Task Manager → Performance → CPU (model name at the top, plus core and thread counts); or PowerShell, which gives the cleanest copyable string:

Get-CimInstance Win32_Processor | Select-Object Name, VendorName, MaxClockSpeed, NumberOfCores, NumberOfLogicalProcessors | Format-List
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model

Now verify that exact string against Microsoft's official lists rather than any third-party round-up: the supported Intel processors page and the supported AMD processors page are the authoritative sources, and Microsoft also maintains version-specific lists (for example for Windows 11 25H2) that can extend coverage to additional parts. Search the list for your model number — not your marketing family name. Two honest caveats: first, these lists describe the minimum floor per generation up to the latest silicon at the time of publication, so a very new part may predate the page's last update even though it is supported — when in doubt, check the list again closer to upgrade day or use PC Health Check as a second opinion. Second, “technically compatible” and “officially listed” are not the same claim: this guide only treats a processor as eligible when it appears on Microsoft's own documentation.

If your model is on the list, this requirement passes — record the string you used, because you will want it in any support conversation. If it is not on the list, resist the temptation to infer eligibility from benchmarks or from a similar-sounding sibling SKU; the list is the test. What an off-list result actually means for your options — staying on Windows 10, upgrading the platform, or making an informed unsupported-install decision — is handled in section 14 and the decision tree (section 16), with the economics of a CPU/motherboard upgrade versus a new PC laid out in the planned companion article linked from the collection.

Memory is the simplest line: Settings → System → About shows installed RAM (4 GB or more passes), and PowerShell confirms it with Get-CimInstance Win32_ComputerSystem | Select-Object TotalPhysicalMemory — divide by 1,073,741,824 to get gigabytes. If you are below 4 GB, adding a module is the cheapest fix in this entire guide, fully reversible and with no interaction with any other requirement; check your board's maximum and slot count before buying. Above that, more RAM helps Windows 11 feel comfortable but is not part of the gate.

Storage has two numbers people conflate, and the confusion causes real upgrade failures. The requirement is a capacity floor: the system disk must be at least 64 GB. But an in-place upgrade additionally needs substantial free space on that drive — tens of gigabytes — to stage its files before it can complete, and Microsoft's own documentation notes that storage requirements may grow over time as updates and features expand. So check both: total capacity (Settings → System → Storage, or Get-Volume) against the 64 GB floor, and free space on C: against what an upgrade actually needs in practice. A 128 GB drive with 90 GB used technically passes the requirement yet will fail the upgrade with a space error — which is exactly the failure mode mapped in the error table (section 11). The read-only commands below show both at once:

$cs = Get-CimInstance Win32_ComputerSystem
[pscustomobject]@{ RAM_GB = [math]::Round($cs.TotalPhysicalMemory / 1GB, 1) }
Get-Volume | Where-Object DriveLetter | Select-Object DriveLetter, FileSystemLabel, @{n='Total_GB';e={[math]::Round($_.Size/1GB,0)}}, @{n='Free_GB';e={[math]::Round($_.SizeRemaining/1GB,0)}} | Format-Table

The last two lines rarely fail on a machine new enough to be considered for Windows 11, but check them properly rather than assuming. For graphics: run dxdiag (type it in the Start menu search and press Enter), open the Display tab, and look at the “Driver Model” line — you need WDDM 2.x with DirectX 12 support; if an older driver reports WDDM 1.x, update the graphics driver from the vendor before concluding the GPU itself is the problem. For display: the requirement is a high-definition (720p) panel of 9 inches or greater at 8 bits per color channel — anything you are actually using to read this page almost certainly satisfies it. With all six lines checked, you have a complete, independently verified picture of your machine — which is more than the one-line verdict from most checkers gives you.

PC Health Check is Microsoft's free official app for the Windows 11 readiness question: you download it from Microsoft's PC Health Check page (or the Microsoft Store), run “Check your PC”, and it returns either “Your PC can run Windows 11” or “This PC can't run Windows 11” with a list of the specific requirements that failed. Its value is as a fast, authoritative first read — it is Microsoft's own assessment tool, so a pass from it carries more weight than a third-party checker, and a fail names the exact requirement lines that blocked you, which maps directly onto the sections above.

Treat it as a hypothesis to verify, not a final verdict. The app reports a general readiness result; it does not show you the underlying evidence (the spec version your TPM reports, the BIOS mode line, your exact CPU string), and on edge cases its reading can disagree with what the system tools show — for example when a firmware TPM exists but is in a state Windows has not fully enumerated. So use it in this order: run PC Health Check for the quick answer and the named failures; then confirm each named failure with the corresponding section above (TPM → section 5, Secure Boot/boot mode → section 6, CPU → section 7), because the system tools are what you will cite in any support conversation. If the two sources disagree, trust the system tools plus Microsoft's published processor lists — and note the discrepancy, since it is itself a diagnostic clue (usually a firmware state problem rather than missing hardware).

One practical note on scope: PC Health Check answers “can this hardware install Windows 11”, not “is this machine ready to upgrade safely”. It says nothing about your backup state, free space for staging, driver health, or application compatibility — those are the other half of readiness, covered by the preparation section (17) and the final checklist (section 19). A PC that passes every hardware line can still be a bad upgrade candidate if its data is not backed up; a PC that fails one fixable line can become a clean pass after a single firmware change.

Running the checks one by one is fine for a single machine, but it is easy to lose track of which fact came from which tool — and even easier to misread an “unknown” as a failure. The script below consolidates every hardware check from Part 2 into one report with explicit states: PASS (verified against the requirement), FAIL (checked, does not meet it), UNKNOWN (the information could not be read — which is not a failure and must not be treated as one), and INFO (reported for your records, e.g. the exact CPU string you will look up on Microsoft's list). It is strictly read-only: it queries system properties and prints a report; it changes no settings, writes no files, needs no administrator rights, and never starts any upgrade.

# =============================================================
#  DiagMyPCHub - Windows 11 hardware compatibility report
#  READ-ONLY: queries system properties and prints a report.
#  Changes nothing, writes no files, needs no admin rights.
#  States: PASS / FAIL / UNKNOWN (not a failure) / INFO
# =============================================================

$ErrorActionPreference = 'Continue'
$results = New-Object System.Collections.ArrayList

function Add-Row {
    param([string]$Check, [string]$State, [string]$Detail)
    [void]$results.Add([pscustomobject]@{ Check = $Check; State = $State; Detail = $Detail })
}

Write-Host ''
Write-Host ('=== Windows 11 hardware compatibility report ===')
Write-Host ('Checked on {0} - {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Write-Host ''

# ---------- Processor (membership in Microsoft's list is manual) ----------
try {
    $cpu = Get-CimInstance Win32_Processor | Select-Object -First 1
    if ($cpu.Name) {
        Add-Row 'Processor' 'INFO' ($cpu.Name.Trim() + ' (' + $cpu.NumberOfCores + ' cores / ' + $cpu.NumberOfLogicalProcessors + ' threads)')
        Write-Host '  NOTE: verify the exact model string against Microsoft\'s supported'
        Write-Host '        Intel/AMD processor lists - this script cannot check list membership.'
    } else { throw 'empty name' }
} catch { Add-Row 'Processor' 'UNKNOWN' ('could not read Win32_Processor: ' + $_.Exception.Message) }

# ---------- Memory ----------
try {
    $cs = Get-CimInstance Win32_ComputerSystem
    $ramGB = [math]::Round($cs.TotalPhysicalMemory / 1GB, 1)
    if ($cs.TotalPhysicalMemory -ge (4GB)) { Add-Row 'Memory' 'PASS' ($ramGB.ToString() + ' GB installed (minimum 4 GB)') }
    else { Add-Row 'Memory' 'FAIL' ($ramGB.ToString() + ' GB installed (minimum 4 GB)') }
} catch { Add-Row 'Memory' 'UNKNOWN' ('could not read Win32_ComputerSystem: ' + $_.Exception.Message) }

# ---------- Storage (capacity floor AND free space are different things) ----------
try {
    $sysDrive = (Get-CimInstance Win32_OperatingSystem).SystemDrive
    $vol = Get-Volume -DriveLetter ($sysDrive.TrimEnd(':\')).ToCharArray()[0] -ErrorAction Stop
    if ($null -eq $vol) { throw 'no volume found' }
    $capOK = ($vol.Size -ge 64GB)
    $state = if ($capOK) { 'PASS' } else { 'FAIL' }
    Add-Row 'Storage capacity' $state (($vol.DriveLetter + ': total ' + [math]::Round($vol.Size/1GB,0) + ' GB (minimum 64 GB); free ' + [math]::Round($vol.SizeRemaining/1GB,0) + ' GB - upgrades also need staging space'))
} catch { Add-Row 'Storage capacity' 'UNKNOWN' ('could not read the system volume: ' + $_.Exception.Message) }

# ---------- TPM (Get-Tpm first, CIM Win32_Tpm as fallback) ----------
$tpmState = $null; $tpmDetail = ''
try {
    $tpm = Get-Tpm -ErrorAction Stop
    if ($tpm.TpmReady) {
        if ("$($tpm.TpmVersion)" -like '2*') { $tpmState = 'PASS'; $tpmDetail = 'TPM ready, spec version ' + $tpm.TpmVersion }
        else { $tpmState = 'FAIL'; $tpmDetail = 'TPM ready but spec version ' + $tpm.TpmVersion + ' (2.0 required)' }
    } else { $tpmState = 'UNKNOWN'; $tpmDetail = 'TPM detected but not ready (TpmReady=False) - see the TPM diagnosis section' }
} catch {
    try {
        $wtpm = Get-CimInstance -Namespace root\CIMV2\Security\MicrosoftTpm -ClassName Win32_Tpm -ErrorAction Stop
        if ($wtpm.SpecVersion -and "$($wtpm.SpecVersion)" -like '2*') { $tpmState = 'PASS'; $tpmDetail = 'CIM Win32_Tpm spec version ' + $wtpm.SpecVersion }
        elseif ($wtpm.SpecVersion) { $tpmState = 'FAIL'; $tpmDetail = 'CIM Win32_Tpm spec version ' + $wtpm.SpecVersion + ' (2.0 required)' }
        else { throw 'no spec version' }
    } catch {
        $tpmState = 'UNKNOWN'; $tpmDetail = 'no TPM visible to Windows (Get-Tpm and Win32_Tpm both empty) - present-but-disabled firmware TPM is a common cause; check the firmware menu before concluding hardware is absent'
    }
}
Add-Row 'TPM 2.0' $tpmState $tpmDetail

# ---------- Boot mode (heuristic: SecureBoot cmdlet exists only on UEFI systems) ----------
try {
    if (Get-Command Confirm-SecureBootUEFI -ErrorAction SilentlyContinue) {
        Add-Row 'Boot mode' 'INFO' 'UEFI system (SecureBoot module present) - confirm with msinfo32 "BIOS Mode"'
    } else {
        Add-Row 'Boot mode' 'FAIL' 'legacy BIOS system (no UEFI SecureBoot cmdlet) - confirm with msinfo32 "BIOS Mode"'
    }
} catch { Add-Row 'Boot mode' 'UNKNOWN' ('could not determine: ' + $_.Exception.Message) }

# ---------- Secure Boot state ----------
try {
    if (Get-Command Confirm-SecureBootUEFI -ErrorAction SilentlyContinue) {
        $sb = Confirm-SecureBootUEFI
        if ($sb) { Add-Row 'Secure Boot' 'PASS' 'enabled' }
        else { Add-Row 'Secure Boot' 'INFO' 'disabled but supported (capability meets the requirement; enabling is a firmware change)' }
    } else {
        Add-Row 'Secure Boot' 'UNKNOWN' 'not assessable in this boot mode - read msinfo32 "Secure Boot state" instead'
    }
} catch { Add-Row 'Secure Boot' 'UNKNOWN' ('cmdlet returned an error: ' + $_.Exception.Message) }

# ---------- Report ----------
$results | Format-Table Check, State, Detail -AutoSize -Wrap
Write-Host ''
Write-Host 'Summary: PASS = verified. FAIL = checked, does not meet the requirement.'
Write-Host 'UNKNOWN = could not be read - verify manually before treating it as a failure.'
Write-Host 'This report is a hardware readiness check only; it is not an official'
Write-Host 'Microsoft certification and does not cover backups, drivers or apps.'

Two design choices in that script matter for how you read its output. First, every check is wrapped so that one unreadable property degrades to UNKNOWN instead of aborting the whole report or silently printing a false failure — on older Windows versions some CIM properties behave differently, and an error there is an information gap, not evidence of incompatibility. Second, the CPU line deliberately reports INFO, never PASS: list membership can only be verified by you, against Microsoft's published pages, because no local command can answer it. A correct reading of a typical passing machine looks like this:

=== Windows 11 hardware compatibility report ===
Checked on 2026-10-24 09:15 - DESKTOP-EXAMPLE

Check              State   Detail
-----              -----   ------
Processor          INFO    Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (6 cores / 12 threads)
Memory             PASS    16 GB installed (minimum 4 GB)
Storage capacity   PASS    C: total 476 GB (minimum 64 GB); free 212 GB - upgrades also need staging space
TPM 2.0            PASS    TPM ready, spec version 2.0
Boot mode          INFO    UEFI system (SecureBoot module present) - confirm with msinfo32 "BIOS Mode"
Secure Boot        INFO    disabled but supported (capability meets the requirement; enabling is a firmware change)

What this report is not: it is not an official Microsoft compatibility determination (that role belongs to PC Health Check and the upgrade experience itself), and a clean sweep of PASS lines does not by itself make an upgrade safe — data protection, driver state and application compatibility are separate readiness dimensions, covered in section 17 and the final checklist (section 19). Use it as the single source of truth for the hardware facts, and let each FAIL or UNKNOWN row point you at the matching diagnosis section.

When the upgrade experience or PC Health Check blocks you, the message names a requirement — and that name is more useful than it first looks, because each one maps to a specific set of likely causes in a specific order of likelihood. The table below pairs the common blocker messages with what they actually mean, the first safe step for each, and where in this guide the full diagnosis lives. Read the message literally before doing anything: “TPM not found” and “TPM version too low” are different machines in different states, and so are “Secure Boot must be enabled” and “UEFI required”.

The pattern to internalise: every blocker message is a pointer to one requirement, and every requirement has a low-risk verification step before any consequential action. The messages that tempt people into risky moves — “UEFI required” (disk conversion), “TPM not found” (registry hacks) — are precisely the ones where the first safe step is reading, not changing. If your message is not in this table, capture its exact wording and run the consolidated report (section 10); the row that comes back as FAIL or UNKNOWN tells you which section owns your problem.

This small questionnaire turns the five facts you have now verified (or admitted not knowing) into a single recommended next step. Answer from what your own checks in sections 5–8 actually showed — use “not checked yet” freely, because an honest unknown changes the advice more than a guessed answer does. The helper is guidance built from this guide's own diagnosis logic: it is not an official Microsoft compatibility test, it cannot see your machine, and it never reports a guaranteed pass while any required fact is missing.

Every fix for a failed requirement falls into one of two fundamentally different categories, and the difference matters more than any individual step. Category 1 — enabling a supported capability: your hardware already contains the feature (a firmware TPM, Secure Boot support), it is merely switched off, and turning it on brings you inside Microsoft's supported configuration. These changes are reversible from the same firmware menu, they do not alter what Windows considers your hardware to be, and they carry no special update or support penalty — a machine that passes every requirement with Secure Boot enabled is a normally supported Windows 11 PC, full stop. Category 2 — bypassing a genuine eligibility failure: the hardware truly lacks something (an unsupported CPU, no TPM of any kind), and the workaround consists of tricks — registry edits that skip setup's checks, modified installers, third-party bypass utilities — that make the installer proceed anyway. These keep you outside the supported configuration: nothing about the machine has changed, so Microsoft's support and update commitments for unsupported hardware apply from day one.

The practical test for sorting any proposed fix: after doing it, would PC Health Check pass on this machine without any trick? If yes — you enabled a real capability (Category 1). If the check still fails but the installation was forced through anyway — you bypassed (Category 2). That single question removes most of the grey area that forum advice creates, because the two categories deserve completely different risk treatment: Category 1 fixes are worth doing whenever the underlying feature exists, and their main risks are procedural (a bad firmware update, a forgotten BitLocker key), which section 17 manages. Category 2 bypasses are decisions about living with permanent trade-offs — covered in the next section — not fixes to be applied casually.

The ranking encodes two rules worth repeating. Never change multiple firmware settings at once: each change gets its own verification (reboot, re-run sections 5–6) and its own way back — if you flip TPM, Secure Boot and boot order in one session and the machine misbehaves, you no longer know which setting caused it. And never reach for a Category 2 bypass while a Category 1 option is unexplored: the bypass's permanent trade-offs are only worth taking when the hardware genuinely cannot meet the requirement, which is exactly what the ordered diagnosis in Part 3 establishes.

If the ordered diagnosis ends with a genuine eligibility failure — most often an unsupported CPU, sometimes a machine with no TPM of any kind — the remaining option is installing Windows 11 anyway through a bypass. That is a legitimate decision for hardware you want to keep in service, but it deserves its costs stated precisely rather than waved away. The core trade-off is support and update commitment: Microsoft's position, as documented for unsupported devices, is that such installations are not covered by the normal support commitments — feature updates may not be offered to them at all, and even where security updates do arrive in practice, there is no guarantee they will continue. Update behaviour can change over time and with each Windows release, so treat any specific “it still gets updates” claim as true only until proven otherwise, and check Microsoft's current documentation before relying on it for a machine you cannot afford to lose.

Three further costs are less visible but real. Compatibility problems: some Windows 11 components and features assume the hardware floor exists — Virtualization-Based Security, Credential Guard and related platform-security features may be unavailable or behave differently without a usable TPM, and certain driver packages target only supported platforms, so you may find yourself on older drivers for longer. No support recourse: when something breaks in an unsupported configuration, Microsoft Support's answer is that the configuration is not supported — troubleshooting falls entirely on you, which is exactly why this site exists, but it changes the risk calculation for a machine that does real work. And security trade-offs: the bypass removes a gate that was there to protect the update pipeline; an installation that cannot receive feature updates will, over time, accumulate distance from the current release, and every skipped release is one more layer of change to absorb (or never absorb) later.

None of this means an unsupported install is reckless — for a five-year-old office PC with a seventh-generation i5 that runs everything you need, it is often the rational choice, made knowingly. What it means is that the decision belongs in Part 4, not in a hurry: confirm the diagnosis (Part 3), prepare properly (section 17 applies to bypass installs too — arguably more, since you have less room for error), and accept the update/support trade-off explicitly. The full landscape of bypass methods — which ones exist, what each one actually does, and their failure modes — is the subject of a planned companion article in the collection; this guide deliberately stops at describing the decision rather than walking through any specific workaround step by step, because no registry edit or installer trick works on every machine, and publishing one as if it did would be the kind of promise this guide does not make.

This is the guide's logic as a walkable path. Answer each question with your verified state — the same states the readiness helper (section 13) asks about — and follow the branch. Every branch ends in an outcome card that names the risk level, whether the move is reversible, and exactly where to go next. The “not sure” option exists at every question on purpose: an unverified fact routes you to verification, not to a guess, because the cost of acting on a wrong assumption here is measured in bootability, not inconvenience.

The failure you are preparing for here has a specific shape: after a firmware change (TPM enabled, Secure Boot toggled, CSM disabled, boot order changed), the machine no longer reaches your desktop — it may show a BitLocker recovery screen, a “no bootable device” message from the firmware, or loop into automatic repair. The recovery options below are ordered from least to most invasive, and each has a condition that makes it the right choice. Read them once before you make any change — deciding under pressure is how people pick the wrong option.

• The BitLocker recovery screen (48-digit key prompt) — condition: the boot chain works but the drive will not unlock. This is the most common outcome of a TPM-related change, and it is the one your preparation in section 17, step 2 exists for. Enter the recovery key from where you stored it (Microsoft account page, printout, USB). If the key unlocks the drive and Windows boots, the encryption layer is fine — the remaining issue (if any) is a firmware setting to review, not data loss. Do not attempt other recovery options while this screen is showing; they will not get past an unlocked-drive requirement.
• Firmware-setting reversal — condition: you changed exactly one or two settings (recorded in section 17, step 3) and the machine fails to boot or finds no device. Reboot into firmware setup and restore the recorded values. Because each change was made individually with verification, you know which entry to revert. This is why “one setting at a time” from section 14 matters: a multi-setting session has no clean reversal path.
• Windows Recovery Environment (WinRE) — condition: Windows starts but fails during boot (blue screen, automatic repair loop), or the firmware boots to its own menu without finding Windows. Reach it by holding Shift while choosing Restart from the sign-in screen or power menu, or by booting your recovery USB (section 17, step 4). From there: Troubleshoot → Advanced options gives you Startup Repair (appropriate for a damaged boot configuration — let it run before touching anything manually), UEFI Firmware Settings (to make the reversal in the previous bullet without needing a working OS), System Image Restore (if you made an image backup), and Command Prompt for targeted fixes. WinRE is the right tool for boot-configuration damage; it is not the tool for encryption problems (that is bullet 1) or wrong firmware values (that is bullet 2).
• Reinstall over the existing installation — condition: WinRE options have been exhausted and the OS itself is unusable, but your data is safe in backups. Boot the recovery/installation media and run setup over the existing Windows (the in-place-upgrade path described in the in-place upgrade guide, or a clean install per the USB installation guide if you accept re-partitioning). This is invasive by design: it replaces system files and, in the clean-install form, erases the target disk — which is precisely why steps 1–3 come first, and why a verified backup is what makes this step acceptable rather than desperate.

Two boundaries keep this section honest. First, a failed firmware update is not in this list: if the machine stops POSTing (no display, no boot menu) after a BIOS flash, the remedy is vendor-specific — many boards have a dual-BIOS or USB-recovery procedure documented by the manufacturer, and that documentation, not any generic Windows procedure, is what applies. Second, nothing here guarantees data recovery: every option above preserves data only to the extent your backups and keys actually exist. That is the entire argument for section 17 — recovery plans are only as strong as the preparation they assume, which is why the final checklist in section 19 verifies both halves before any operation starts.

This checklist separates the four readiness dimensions that a passing hardware check does not cover on its own: hardware facts (verified, not assumed), data protection (a backup that works and keys you can reach), operational readiness (recovery media, recorded settings, space), and the decision itself (which path you chose and why). Tick a box only when the corresponding section's procedure was completed on your machine — the progress bar below counts real confirmations, and it persists in this browser between visits. A full bar does not certify anything to Microsoft; it certifies that you did not skip a step this guide asked for.

This hub covers the verification, diagnosis and decision logic for every topic below — but a hub is a map, not the territory. The collection organizes the full subject area into six categories of companion tutorials. Topics marked in this guide are covered in the sections above (the card links you there); topics marked planned will be published as their own pages with the depth their subject needs — per-manufacturer firmware procedures, full bypass landscape, fleet automation — and are listed here so you can see exactly what is coming. Use the search box and category filters to find a topic; they filter the cards below in real time.

No topics match that search in this category — try a shorter term, or reset the filters.

The technical claims in this guide are grounded in Microsoft's current documentation, linked below near the topics they support. Where a requirement, list or policy can change over time — storage needs, processor list coverage, update behaviour for unsupported hardware — the live page is the reference and this article states its scope rather than making absolute claims.

• Windows 11 requirements — Microsoft Learn (the minimum hardware requirements this guide verifies against, including the note that storage needs may grow over time)
• Windows 11 system requirements — Microsoft Support
• Windows 11 supported Intel processors and supported AMD processors (Microsoft's official eligibility lists; version-specific lists for newer releases are maintained alongside them)
• How to use the PC Health Check app and the PC Health Check download page
• Trusted Platform Module (TPM) fundamentals — Microsoft Learn, with the consumer-facing summary at What's a TPM? — Microsoft Support
• Get-Tpm cmdlet reference and the Win32_Tpm WMI/CIM class (namespace root\CIMV2\Security\MicrosoftTpm) used by the fallback query in section 5
• Confirm-SecureBootUEFI cmdlet reference and Windows 11 and Secure Boot — Microsoft Support

Related guides on this site