Fix TPM_E_WRONGPCRVAL 0X80280018 on Windows

Quick answer

Use your BitLocker recovery key to boot, then suspend BitLocker, clear TPM, and re-enable BitLocker. That resyncs the PCR values.

What's actually happening here

TPM_E_WRONGPCRVAL means the TPM recorded one set of Platform Configuration Register (PCR) values during the last BitLocker enrollment, but now the system boots with different PCR values. PCRs are hashes of your boot chain — firmware, bootloader, kernel drivers. If any of those changed, the TPM won't release the encryption key. This commonly triggers after a BIOS/UEFI update, a secure boot key change, or a TPM firmware update. Windows 11 22H2 systems with BitLocker enabled and a recent Lenovo or Dell firmware patch are typical victims. The error shows up as a blue screen with 0X80280018, or BitLocker asking for a recovery key at every boot.

Fix steps

Boot with recovery key — If you're locked out, type the 48-digit BitLocker recovery key. Find it in your Microsoft account (account.microsoft.com/devices/recoverykey), or check where you saved it. Don't have it? You're stuck until you wipe the drive.
Suspend BitLocker — Open an admin Command Prompt and run
```
manage-bde -protectors -disable C:
```
This tells Windows to temporarily stop checking TPM for that drive. It won't decrypt anything — just pauses the protection.
Clear and reinitialize TPM — In the same admin prompt, run
```
tpm.msc
```
to open the TPM management console. Under Actions, click "Clear TPM". You'll need to reboot and accept the UEFI prompt. Important: Clearing TPM invalidates any keys stored there (Windows Hello, BitLocker, etc.). Your recovery key saved you, but you still need to re-enroll everything after.
Re-enable BitLocker with new PCR — After reboot, run
```
manage-bde -protectors -enable C:
```
Then force a PCR reseal with
```
manage-bde -protectors -add C: -TPM
```
This captures the current PCR values.
Verify — Check status with
```
manage-bde -status C:
```
It should show "Protection On" with no recovery key prompt on next boot.

Alternative fixes if the main one fails

Update firmware and drivers — Sometimes the mismatch is because the old PCR values captured a buggy firmware version. Install the latest UEFI update from your motherboard vendor, then re-run step 2–4.
Disable Secure Boot and re-enable — Enter UEFI setup, disable Secure Boot, save and exit, reboot, then re-enable it. This resets the PCR 7 measurements. Then re-enroll BitLocker.
Use Group Policy to exclude PCR 7 — If Secure Boot changes are the culprit, you can configure BitLocker to ignore PCR 7. Run
```
gpedit.msc
```
and go to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives. Enable "Configure TPM platform validation profile" and uncheck PCR 7. This is a band-aid — I don't recommend it unless you're stuck and can't update firmware.
Last resort: decrypt and re-encrypt — Run
```
manage-bde -off C:
```
(takes hours on a large SSD), then re-enable with
```
manage-bde -on C: -TPM
```
This wipes the old PCR data entirely. Only do this if clearing TPM didn't help.

Prevention tip

Before you update your UEFI firmware or TPM firmware, suspend BitLocker manually. Run

manage-bde -protectors -disable C:

before the update, then re-enable after. The TPM will capture the new PCR values cleanly. Also save a current BitLocker recovery key to your Microsoft account _before_ any firmware change — not after you crash. That 48-digit number is your only escape hatch when PCR values go sideways.

Real-world trigger: Lenovo ThinkPad X1 Carbon Gen 11 with BIOS update 1.47 to 1.48 in November 2024. The update changed UEFI Secure Boot variables, shifting PCR 7, and every boot required the recovery key until the above fix was applied.