You updated your BIOS or UEFI firmware, restarted, and now Windows won’t boot to the desktop. Instead you’re staring at a blue BitLocker recovery screen demanding a 48-digit key. Nothing is broken, and you weren’t attacked. This is BitLocker doing exactly what it’s built to do — it noticed the boot environment changed and refused to hand over the drive key automatically.
That’s reassuring once you understand it, and annoying if you don’t have the recovery key handy. This guide explains why a firmware update sets off the prompt, how to get back into Windows, and — most importantly — how to avoid the whole situation next time by suspending BitLocker before you flash firmware.
Why a firmware update triggers the prompt
BitLocker protects your drive’s encryption key by sealing it to the TPM (Trusted Platform Module). The TPM measures the state of the early boot environment — firmware, boot configuration, Secure Boot state — and only releases the key when those measurements match what it recorded when BitLocker was set up.
A BIOS/UEFI update changes the firmware, which changes those measurements. From the TPM’s point of view, the boot environment is no longer the one it sealed the key to, so it won’t release the key automatically. BitLocker then falls back to its safety net: it asks for the recovery key to prove you’re authorized.
This is the intended design. The same protection that stops an attacker from moving your drive into another machine also fires when you legitimately change the firmware. The fix isn’t to weaken BitLocker — it’s to tell BitLocker ahead of time that a change is coming.
Step 1: Get back into Windows with your recovery key
Right now you need the key. The recovery screen shows a Key ID — match the first characters of that ID to the right key if you have more than one saved. Check these locations:
- Your Microsoft account. Sign in at
account.microsoft.com/devices/recoverykeywith the account used on the PC. This is where consumer device encryption saves the key automatically. - A work or school account. On managed devices the key is often saved to Microsoft Entra ID — ask your IT admin or check your organization’s portal.
- A printout or saved file. BitLocker can save the key to a file or USB drive at setup. Look for a
.txtfile named with “BitLocker Recovery Key.” - Active Directory. In a domain environment, the key may be escrowed in AD DS for administrators to retrieve.
Our companion guide on where to find your BitLocker recovery key walks through each of these in detail. Enter the 48-digit key at the prompt and Windows will boot.
Step 2: Stop it happening every boot
Sometimes entering the key once isn’t enough and the prompt returns on the next restart. That means BitLocker hasn’t re-sealed its key to the new firmware measurements yet. Once you’re booted into Windows, force it to re-seal by suspending and resuming protection (covered below), then reboot to confirm a normal, automatic unlock.
While you’re in, sanity-check that Secure Boot and TPM settings in firmware match what they were before the update. A firmware update that silently re-enabled or disabled Secure Boot can keep the measurements from settling.
The real fix: suspend BitLocker before firmware updates
Here’s the part that prevents the headache entirely. Before you run a BIOS/UEFI or other firmware update, suspend BitLocker. Suspension tells BitLocker to use a clear key temporarily, so a changed boot measurement during the update doesn’t trigger recovery. After the update and reboot, you resume protection and BitLocker re-seals to the new, current measurements.
Suspending does not decrypt your drive. The data stays encrypted and any new data is still written encrypted — suspension only makes the unlock key available in the clear so the machine can boot without prompting.
Option A: Control Panel
- Open Control Panel → System and Security → BitLocker Drive Encryption.
- Next to the operating system drive, select Suspend protection.
- Confirm with Yes.
- Run your firmware update and let the PC reboot.
- Return to the same screen and select Resume protection.
Option B: PowerShell
Run an elevated PowerShell (right-click → Run as administrator). To suspend for a set number of reboots:
Suspend-BitLocker -MountPoint "C:" -RebootCount 1The -RebootCount value sets how many restarts happen before protection resumes automatically. Use 1 if the update reboots once; the suspension lifts on its own afterward. To resume manually at any time:
Resume-BitLocker -MountPoint "C:"Check the current state before and after:
manage-bde -status C:Look at the Protection Status line — Protection Off while suspended, Protection On once resumed.
Suspend / resume reference
| Suspend-BitLocker -MountPoint "C:" | Suspend until you resume manually |
|---|---|
| Suspend-BitLocker -MountPoint "C:" -RebootCount 1 | Auto-resume after 1 reboot |
| Resume-BitLocker -MountPoint "C:" | Resume protection now |
| manage-bde -status C: | Check protection status |
A clean firmware-update routine
Put together, the safe sequence for any BIOS/UEFI or TPM firmware update looks like this:
Before you flash firmware
- Confirm your BitLocker recovery key is backed up and you can access it
- Suspend BitLocker on the OS drive (Control Panel or Suspend-BitLocker)
- Run the firmware update and let the PC reboot as needed
- Resume BitLocker protection (or confirm auto-resume completed)
- Reboot once more and verify it unlocks without a recovery prompt
- Check manage-bde -status shows Protection On
This routine matters most for managed fleets. If you’re pushing firmware updates across many machines, suspend BitLocker as part of the update package so users aren’t hit with recovery prompts en masse. The same caution applies to TPM firmware updates specifically, which change the very component BitLocker seals its key to.
When you don’t have the key and can’t boot
If you’re locked out and genuinely cannot find the key anywhere, the options narrow quickly. Re-check every Microsoft and work account that was ever signed in on the device — the key is tied to the account active at the time encryption was enabled, which isn’t always the one you expect. Check any USB drives and printouts from when the PC was set up. For a domain-joined or Intune-managed device, your IT administrator is the right contact.
If the data is truly unrecoverable and you only need a working PC, you’ll be looking at a clean reinstall, which wipes the drive. Our guide on resetting Windows 11 without losing files covers the reset paths, though note that an inaccessible BitLocker volume may not preserve files. This is the worst-case outcome, and it’s exactly what backing up the key beforehand prevents.
Wrapping up
A BitLocker recovery prompt after a BIOS update isn’t a fault — it’s the TPM noticing the firmware changed and protecting the drive accordingly. Enter your recovery key to get in, and if the prompt repeats, suspend and resume BitLocker so it re-seals to the new boot state.
The lasting fix is procedural: suspend BitLocker before any firmware update, run the update, then resume. Suspension keeps the drive encrypted while letting the machine boot through the change, and resuming re-seals the key cleanly. Build that into your update routine and the recovery screen stops being a surprise.
