Fix Secure Boot Measurement Failure in 3 Steps

What’s Actually Happening Here

A Secure Boot measurement failure means Windows couldn’t verify that your boot components (UEFI drivers, boot loader, kernel) are trusted. This usually pops up in Event Viewer as error 0x80072EFE under Microsoft-Windows-TPM-WMI or during a TPM attestation check via tpmtool. The real trigger? Your firmware changed something—a BIOS update, a new SSD, even a minor UEFI setting toggle—and the TPM’s stored measurements no longer match what’s booting now.

You’ll see this after a firmware update, or when you swap between Windows 11 and a Linux dual-boot that touches EFI variables. BitLocker might demand a recovery key on every boot. Don’t panic—this is fixable without reinstalling Windows.

Fix 1: Simple Reboot and Clear TPM (30 Seconds)

This is almost too easy, but it works when the firmware change was a one-time glitch—like a power outage that corrupted the TPM’s volatile memory.

Shut down your PC completely. Not restart—you want a cold boot that clears TPM state.
Power it back on. At the login screen, hold Shift and click Restart. This boots into Windows Recovery Environment (WinRE).
Go to Troubleshoot > Advanced Options > UEFI Firmware Settings. Restart into BIOS.
In BIOS, find the TPM settings (often under Security or Advanced). Set TPM to Enabled (or Firmware TPM for AMD). Save and exit.
Boot to Windows. Open PowerShell as admin and run:
```
Clear-Tpm -Force
```
This resets the TPM’s storage root key. Windows will re-measure boot components on next boot.

Why step 4 matters: Some OEMs (looking at you, Dell XPS 13) ship with TPM set to “Discrete” but the motherboard has a bug where the TPM resets to “Disabled” after a firmware update. Re-enabling it forces Windows to re-issue the attestation identity key.

If the error persists after a reboot, move on.

Fix 2: Reset Secure Boot and PCR7 Configuration (5 Minutes)

This targets the boot measurement chain itself. The TPM stores measurements in Platform Configuration Registers (PCRs), and PCR7 specifically tracks Secure Boot policy. If you modified Secure Boot keys or switched to “Custom” mode, PCR7 mismatches.

Reboot into BIOS again. Find Secure Boot settings.
Switch Secure Boot to Standard (or Default) mode. Some motherboards call it Standard vs Custom. This uses Microsoft’s default keys.
If you see Restore Factory Keys, hit that. It wipes any custom keys you imported.
Save and exit. Boot Windows.
Open PowerShell as admin. Check current PCR7 binding:
```
Get-Tpm | Select-Object $_.Pcr7Binding
```
If it returns True, you’re good. If False, force a re-measurement:
```
Add-TpmPcrBinding -Pcr 7
```
Then reboot.

The nuance: PCR7 binding gets set once per boot session. You’re telling Windows to bind TPM attestation to PCR7—meaning any future Secure Boot tampering will break the chain again, but at least you’ll know exactly what changed.

Still broken? Let’s go nuclear.

Fix 3: Full UEFI Firmware Reset and TPM Initialization (15+ Minutes)

This is the “I’ve tried everything” fix. A corrupted UEFI variable store or a half-baked firmware update can silently break measurement logging. You’re going to reset the entire UEFI environment and reinitialize the TPM.

Back up BitLocker recovery keys first. Open PowerShell:
```
manage-bde -protectors -get c:
```
Write down the 48-digit key. Without it, a TPM clear will lock you out.
Shut down. Unplug the power cable. Remove the CMOS battery if you’re on a desktop. Wait 10 minutes. (Laptops: hold power button for 30 seconds with battery disconnected.)
Reconnect power and boot. Enter BIOS. Load Optimized Defaults (usually F9).
Enable Secure Boot in Standard mode. Enable TPM (fTPM for AMD, PTT for Intel). Disable any “Fast Boot” or “Ultra Fast Boot” – these skip hardware initialization.
Save and exit. Let Windows boot. It will detect the cleared TPM and run initialization. This takes longer than usual because Windows rebuilds the attestation identity key.
After login, open Event Viewer. Check Applications and Services Logs > Microsoft > Windows > TPM-WMI > Admin. You should see Event ID 15 – “TPM successfully initialized.” If you see Event ID 2 (error), you’ve got a hardware TPM issue.

Real-world scenario that demands this fix: You updated your ASUS ROG Strix Z690 motherboard’s BIOS from version 2101 to 2204. The update reset UEFI variables but didn’t clear the TPM’s old measurements. Now every boot shows “Secure Boot measurement failure” even though Secure Boot is enabled. A CMOS reset plus TPM clear is the only way to flush those stale measurements.

What to Do If None of These Work

If you’re still stuck after Fix 3, you likely have a hardware TPM defect or a deeply corrupted boot partition. Check if your TPM is actually functional:

tpmtool getdeviceinformation

If it reports “TPM is not present” when you know it’s enabled, the TPM chip may be dead. On some Lenovo ThinkPads (T14, X1 Carbon), the TPM can fail after a firmware update and requires RMA. For desktop motherboards, try reseating the CPU (the TPM is sometimes embedded in the chipset) or updating to the latest BIOS beta—manufacturers occasionally patch measurement bugs months later.