Skip to content

Is this CPU supported by Windows? Model list, microcode and mitigations

Verified 2 min read

Check a CPU against Microsoft's support list, read the microcode revision Windows loaded, and understand what Spectre-class mitigations cost.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64
E1
Build
26300.9457 / 26100.33650
Edition
Pro (26H2) / Server
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Method

“Supported” is a list, not a vibe. Microsoft publishes the processors supported by each Windows release, and Windows 11 additionally enforces TPM 2.0, Secure Boot and UEFI. A CPU can be perfectly fast and still be off the list — usually because the OEM never shipped firmware for that combination.

Three things to check separately:

  1. Is the model on Microsoft’s list for your Windows release?
  2. Is the microcode current (BIOS/UEFI update, or a Windows microcode update)?
  3. What do mitigations cost on this specific CPU?
Terminal window
Get-CimInstance Win32_Processor |
Select-Object Name,Manufacturer,NumberOfCores,NumberOfLogicalProcessors,MaxClockSpeed
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer,Model

Take the exact model string (not just the family) and look it up in Microsoft’s processor requirements documentation for your release. If it is not listed, Windows 11 setup will refuse or the install will be unsupported even if forced.

For OEM machines, also check the OEM’s support page for that exact model: some ship Windows 11-capable firmware only for later production runs.

Windows exposes the loaded microcode revision in the registry:

Terminal window
Get-ItemProperty 'HKLM:\HARDWARE\DESCRIPTION\System\CentralProcessor\0' |
Select-Object Identifier,'Update Revision','Previous Update Revision'
  • Update Revision is the microcode currently loaded (hex).
  • Previous Update Revision shows the pre-update value when Windows applied an update.
  • A revision that never changes across BIOS updates usually means the update did not include CPU microcode, or the firmware update failed.

Microcode can arrive two ways: in the firmware (permanent until the next flash) or as a Windows update (applied at boot, not persistent in firmware). Firmware is the one you want for a machine you keep.

Spectre/Meltdown-class mitigations are enabled by default where the CPU is affected. The cost depends on workload:

  • Syscall-heavy workloads (databases, some runtimes) notice it most.
  • Bulk compute notices it least.
  • Newer silicon has hardware fixes for older issues but may be affected by newer ones.

Microsoft’s SpeculationControl PowerShell module reports what is enabled and whether hardware mitigation exists:

Terminal window
Install-Module SpeculationControl -Scope CurrentUser
Get-SpeculationControlSettings

Read the *HardwareMitigationAvailable / *WindowsSSBDSupported style fields rather than assuming. Do not disable mitigations on a machine that handles untrusted input.

Windows Server adds its own constraints on top:

  • Server-certified NIC and storage drivers (consumer drivers frequently refuse to install).
  • Hyper-V needs SLAT; nested virtualisation needs the host to expose the right CPU features.
  • Some server parts are supported only on specific OEM platforms.

Check the server’s OEM support matrix before assuming a desktop CPU is fine.

  1. Keep it on the Windows release it was supported for, with its own patch stream.
  2. Do not put it on a network where it handles untrusted input.
  3. If it is a lab machine, label it as unsupported in your notes — and expect driver/firmware surprises.
  4. Replace it before it becomes the machine you depend on.

E1. The registry paths and module behaviour are Microsoft-documented. This site has not run a microcode audit across a fleet, and does not publish mitigation percentages.

Sources