BitLocker Asking for the Recovery Key After a BIOS/Firmware Update

The fast answer. A BIOS or UEFI firmware update changes the boot measurements stored in the TPM. BitLocker sees the change, assumes tampering, and demands your 48-digit recovery key. Enter the key to get in, then re-seal BitLocker to the new measurements so the prompt stops:

manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

Reboot. If the prompt returns, re-bind the TPM protector directly (see Step 3 below). If you haven't applied the firmware update yet, suspend BitLocker first and the prompt never appears.

Why this happens

UEFI/BIOS firmware update — the update changes firmware code and configuration measured by the TPM at boot. The new measurements don't match what BitLocker sealed the key against, so it falls back to recovery mode. This is the most common trigger.
TPM firmware update — some TPM firmware updates clear or reset the TPM entirely. If the update doesn't use the Windows API to clear the TPM, BitLocker isn't automatically suspended and you get the recovery prompt.
Secure Boot configuration change — if the firmware update altered Secure Boot keys, databases, or toggled Secure Boot on/off, PCR 7 (which measures the Secure Boot policy) changes and triggers recovery.
BIOS settings change — any BIOS setting change (boot order, virtualization, storage mode) that affects boot-time measurements can trigger the prompt, especially if the BIOS was reset to defaults during the update.
Non-default PCR configuration — systems using PCR values other than the default PCR 7 and PCR 11 (often set by Group Policy) are more sensitive to firmware changes and trigger recovery more often.

Step-by-step fix

Step 1 — Enter the recovery key

At the blue BitLocker recovery screen, type your 48-digit recovery key. Find it at account.microsoft.com/devices/recoverykey (personal Microsoft accounts), in Azure AD / Intune / Active Directory (work devices), or wherever you saved it. Without the key the data is inaccessible — that is BitLocker working as designed.

Step 2 — Suspend and resume BitLocker (re-seal to new measurements)

Once Windows boots, open an admin Command Prompt and run:

manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

This suspends BitLocker (stores the key unsealed for one cycle), then resumes it, which re-seals the encryption key to the current post-update TPM measurements. Reboot and test — the recovery prompt should be gone.

Step 3 — Re-bind the TPM protector (if the prompt persists)

If suspend/resume alone doesn't hold, delete the stale TPM protector and create a fresh one:

manage-bde -protectors -delete C: -type TPM
manage-bde -protectors -add C: -tpm

Verify the new protector is in place:

manage-bde -status C:
manage-bde -protectors -get C:

Reboot. This forces BitLocker to seal to the current PCR values from scratch.

Step 4 — Check Secure Boot and PCR configuration

If the loop continues, enter BIOS/UEFI setup (usually Del or F2 at power-on) and confirm Secure Boot is enabled. If Secure Boot is off, BitLocker can't bind to PCR 7 and falls back to PCR values that are more sensitive to firmware changes. Enable Secure Boot, save, boot Windows, then suspend and resume BitLocker again (Step 2). Also check whether Group Policy is pinning non-default PCR values — run manage-bde -protectors -get C: and look for the PCR validation profile. The default (and recommended) profile is PCR 7 and PCR 11.

Step 5 — If Windows won't start at all: unlock in WinRE

Boot a Windows install USB → Repair your computer → Troubleshoot → Advanced options → Command Prompt. Unlock the drive with your recovery key:

manage-bde -unlock C: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456

Replace the digits with your real 48-digit key and C: with the BitLocker drive letter shown in WinRE. Then disable protectors so the machine can boot:

manage-bde -protectors -disable C:

Reboot into Windows and re-enable protection (Step 2) once the system is stable.

Step 6 — Prevent this next time: suspend before updating

Before applying any BIOS, UEFI, or TPM firmware update, suspend BitLocker from an admin PowerShell prompt:

Suspend-BitLocker -MountPoint "C:" -RebootCount 0

The -RebootCount 0 keeps BitLocker suspended until you explicitly resume it, which is important because firmware updates can require multiple reboots. After the update completes successfully, resume protection:

Resume-BitLocker -MountPoint "C:"

Microsoft's own guidance is to suspend BitLocker before non-Windows firmware updates. Windows quality and feature updates handle this automatically.

Data safety: Do not run format, clean, or a fresh Windows install to "get past" BitLocker — that destroys the encrypted data permanently. The only legitimate way in is the 48-digit recovery key. Keep a copy of your key in a safe place before applying BIOS or firmware updates, since those are exactly what triggers the prompt. If you don't have the key, check account.microsoft.com/devices/recoverykey or contact your IT admin before doing anything else.

GRAM tip: Once the machine boots past the recovery prompt, plug in GRAM — a free portable repair toolkit that runs from a USB inside Windows — to read the event logs and confirm which firmware or Secure Boot change triggered the prompt, and let its AI agent walk the re-bind commands so the recovery screen doesn't return.

Download GRAM free See AI pricing →

FAQ

Can I fix this without a second working computer?

Yes. If you have your 48-digit recovery key, enter it at the BitLocker screen to boot into Windows, then run the suspend/resume commands from there. If Windows won't start at all, use Windows Recovery (WinRE) — which lives on the broken PC itself (force three failed boots to trigger Automatic Repair, or boot from any Windows install USB). No second computer is required. (GRAM runs inside Windows rather than from boot media — use it once the machine boots to confirm the root cause.)

I lost my BitLocker recovery key — can I still get in?

Only if it's stored somewhere. Check account.microsoft.com/devices/recoverykey for personal Microsoft accounts, or your organization's Azure AD / Active Directory / Intune (or ask IT) for work devices. Without the key the data cannot be recovered — that is BitLocker working as designed, not a fault to defeat.

Will suspending BitLocker leave my data unprotected?

While suspended, the data stays encrypted on disk, but the volume master key is stored with a clear key so the TPM check is skipped at boot. Anyone with physical access to the running machine could access the data. Resume protection as soon as the firmware update finishes — don't leave it suspended longer than necessary.

Why does this happen after a BIOS update but not after a Windows Update?

Windows quality and feature updates are designed to automatically suspend and resume BitLocker as needed during the update process. Third-party BIOS and UEFI firmware updates don't go through the Windows update mechanism, so they don't trigger that automatic suspension. Microsoft recommends manually suspending BitLocker before applying non-Windows firmware updates.