# UEFI settings that change how Windows behaves

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

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

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

1. **Boot mode: UEFI, CSM off** — without it, none of the rest works.
2. **fTPM/PTT enabled** — gives you TPM 2.0.
3. **Secure Boot enabled** — required by Windows 11, improves boot integrity.
4. **IOMMU (VT-d/AMD-Vi) enabled** — needed for device passthrough and DMA protection.
5. **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

```powershell
# 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:**

```powershell
Suspend-BitLocker -MountPoint C: -RebootCount 1
```

> **Caution: Clearing TPM wipes BitLocker keys**
>
> Clearing the TPM (or resetting fTPM) discards the key protectors stored there. If BitLocker is on and you do not have the recovery key, the data is gone. Suspend first, or have the key in hand.

## 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

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

## Related

- [First boot checklist](https://windows.homes/en/hardware/build/first-boot/)
- [Hardware requirements by OS version](https://windows.homes/en/hardware/buy/os-hardware-matrix/)
- [Virtualisation flags](https://windows.homes/en/hardware/cpu/virtualization-flags/)

## 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.

## Sources

- [Microsoft Learn — OEM Secure Boot](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot)
- [Microsoft Learn — TPM fundamentals](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals)
- [Microsoft Learn — Confirm-SecureBootUEFI](https://learn.microsoft.com/en-us/powershell/module/secureboot/confirm-securebootuefi)
- [Microsoft Learn — Windows 11 requirements](https://learn.microsoft.com/en-us/windows/whats-new/windows-11-requirements)

---

Source: https://windows.homes/en/hardware/build/uefi-settings/