Quick fix: Suspend BitLocker before each major Windows Update, or clear the TPM-triggering Secure Boot policy that’s flagging your firmware change as tampering.
Every time Windows installs a feature update or a firmware-related patch, your PC reboots into a blue screen asking for the 48-digit BitLocker recovery key. You enter it, the system boots normally, and a month later it happens again. The drive isn’t damaged. Your password isn’t wrong. BitLocker has simply decided the boot environment changed enough to be suspicious.
Affects: Windows 11 (and Windows 10) with BitLocker enabled on the system drive.
Fix time: 5–15 minutes depending on which method works for you.
What causes this
BitLocker on the system drive uses your TPM (Trusted Platform Module) to measure the boot chain — UEFI firmware, Secure Boot state, the bootloader, and a few other components. When any of those measurements change, the TPM refuses to release the encryption key, and Windows falls back to asking you for the recovery key directly.
Most often, the trigger is a UEFI firmware update bundled with a Windows Update (especially around Patch Tuesday), a Secure Boot policy refresh, a CPU microcode update, or a switch in the boot order after replacing or reseating an SSD. The drive is fine; the chain of trust is what got reshuffled.
Method 1: Suspend BitLocker before each Windows Update
This is the supported way to skip the recovery prompt on the next reboot. Suspending BitLocker doesn’t decrypt the drive — it just stores the unsealed key in plaintext on the volume temporarily so the boot chain can change without tripping the alarm.
- Press
Win + Sand type BitLocker, then open Manage BitLocker. - Next to your system drive (usually C:), click Suspend protection.
- Confirm Yes when Windows asks how long to suspend — accept the default (one reboot) for a routine update.
- Run Settings → Windows Update → Check for updates and install pending updates.
- After the reboot finishes and Windows is back on the desktop, return to Manage BitLocker and click Resume protection.
BitLocker will re-seal the key against the new boot measurements, and no recovery prompt appears. You can script this with PowerShell using Suspend-BitLocker -MountPoint “C:” -RebootCount 1 if you patch many machines.
Method 2: Disable Secure Boot policy re-measurement
If you rarely change firmware but BitLocker still prompts, the TPM is measuring a Secure Boot DBX (revocation list) that Windows quietly updates. You can keep BitLocker active and stop the TPM from caring about that specific measurement.
- Open Start → Group Policy Editor (
gpedit.msc). Home edition users: skip to Method 3. - Navigate to Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives.
- Open Configure TPM platform validation profile for native UEFI firmware configurations.
- Set it to Enabled, then in the list of PCR slots, uncheck PCR 7: Secure Boot State. Leave PCR 0, 2, 4, and 11 checked — those still protect you against true tampering.
- Click OK, open an elevated Command Prompt, and run
gpupdate /force. - Reboot once to commit the new validation profile. BitLocker will re-seal against the reduced PCR set automatically.
You can verify the active profile with manage-bde -protectors -get C: — the output lists which PCRs are bound to the current key.
Method 3: Decrypt, then re-enable BitLocker fresh
When the previous methods don’t stick — usually because the laptop’s OEM firmware updates very frequently, or the TPM was reseated — wiping the BitLocker state and starting clean is the most reliable fix. It takes longer because the drive has to be decrypted and re-encrypted.
- Open Manage BitLocker and click Turn off BitLocker on the system drive.
- Wait for the decryption to finish (a 512 GB SSD takes 30–90 minutes on modern hardware).
- Once the drive shows as Off, click Turn on BitLocker from the same screen.
- Choose Save to your Microsoft account or Save to a file when prompted for the recovery key location — and write it down or print it as a backup.
- Select Encrypt used disk space only for a much faster re-encryption (it’s as secure as full re-encryption on a previously-unused drive).
- Reboot when prompted and let the new encryption finish in the background.
This is the right path if you also recently changed the SSD, swapped the motherboard, or did anything that altered the TPM owner relationship.
How to verify the fix worked
- Open an elevated Command Prompt and run
manage-bde -status C:. Conversion Status should read Fully Encrypted and Protection Status should read On. - Reboot the machine once. Windows should go straight to the sign-in screen with no recovery prompt.
- Run Check for updates again. If a pending update applies and reboots, the recovery prompt should not return.
If none of these work
If the prompt still appears after every reboot — not just after updates — the TPM itself is producing inconsistent measurements. Open tpm.msc and check the Status: it should read The TPM is ready for use. If it shows a warning, run Clear TPM (you’ll need to suspend BitLocker first, then resume after). If the TPM clear doesn’t resolve it, the device’s firmware may have a known UEFI/BitLocker bug — check the laptop manufacturer’s support page for a BIOS update referencing “BitLocker” or “TPM” specifically. Persistent prompts despite a healthy TPM and current firmware almost always point to a failing TPM chip on the motherboard.
Bottom line: The recovery prompt isn’t a sign of compromise — it’s BitLocker doing its job. Either suspend it before updates or remove the trigger (PCR 7) so it stops complaining about benign changes.