UEFI settings that change how Windows behaves

Verified 2026-10-292 min read

Secure Boot, fTPM, CSM, Resizable BAR and IOMMU: what each switch does to Windows, and the order to change them in.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

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

The short answer

Five firmware switches change what Windows can do. Set them in this order, because some depend on others:

Boot mode: UEFI, CSM off — without it, none of the rest works.
fTPM/PTT enabled — gives you TPM 2.0.
Secure Boot enabled — required by Windows 11, improves boot integrity.
IOMMU (VT-d/AMD-Vi) enabled — needed for device passthrough and DMA protection.
Resizable BAR — performance feature for GPUs, optional.

Everything else (fan curves, memory profiles, CPU limits) is tuning; these five are about capability.

What each one actually does

Setting	Windows effect	If wrong
UEFI + CSM off	enables Secure Boot, GPT boot, VBS	Windows 11 refuses to install; BitLocker weaker
fTPM/PTT	TPM 2.0 for BitLocker, Hello, Credential Guard	setup says “TPM not found”; device encryption unavailable
Secure Boot	signed boot chain only	Windows 11 unsupported; some anti-cheat/VBS features limited
IOMMU	DMA remapping, device isolation	VM passthrough fails; DMA attack surface larger
Resizable BAR	GPU can expose full VRAM window	performance loss on some titles (small)

Verify from inside Windows

# Secure Boot state
Confirm-SecureBootUEFI
# TPM
Get-Tpm | Select-Object TpmPresent,TpmReady,TpmEnabled,ManufacturerIdTxt
# firmware mode (UEFI vs legacy)
$env:firmware_type
# boot entry / partition style
Get-Disk | Select-Object Number,PartitionStyle

Confirm-SecureBootUEFI throwing “not supported” usually means the system booted legacy/CSM.
$env:firmware_type returns UEFI or Legacy.
PartitionStyle should be GPT on a modern install.

Secure Boot: modes and keys

Secure Boot in setup mode has no platform keys (PK) enrolled; Windows will still install, and the firmware may enrol keys on first boot or leave it to you.

Standard/custom mode with Microsoft keys — the normal consumer state.
Custom keys — for Linux dual-boot or signing your own bootloaders.
Disabled — Windows 11 is unsupported; some drivers refuse to load.

Changing Secure Boot state can invalidate BitLocker’s measured boot and trigger a recovery prompt. Suspend BitLocker before changing firmware settings:

Suspend-BitLocker -MountPoint C: -RebootCount 1

Dual boot and Linux

Keep Secure Boot enabled and use a distribution that supports it (most do), or enrol your own keys.
Disable Fast Boot in firmware — it makes the other OS’s boot entries unreliable.
Windows Update can reorder the boot order; if the other OS “disappears”, check firmware boot entries before repairing anything.

Servers: fewer switches, same consequences

Windows Server installs without TPM/Secure Boot, but:

VBS/Credential Guard needs virtualization + IOMMU;
BitLocker on servers is common — plan TPM ownership and recovery-key escrow;
firmware updates may reset these settings; document the state before updating.

A safe change procedure

Note current settings (photograph the screens).
Suspend BitLocker if enabled.
Change one setting, save, boot.
Verify from Windows with the commands above.
Resume BitLocker, confirm protection status.
If the machine will not boot, clear CMOS and restore the previous state.

Lab boundary

E1. The switches and their Windows effects are documented by Microsoft and firmware vendors. The lab’s VMs use OVMF with vTPM, which exercises the same requirements without physical firmware screens.