Skip to content

A BitLocker recovery drill: where the key is and how to use it

Verified 2 min read

The four places a recovery key can live, what triggers a recovery prompt, and a 15-minute drill to prove you can actually get back in.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64
E1
Build
26300.9457 / 26100.33650
Edition
Pro (26H2) / Server
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Checklist

A recovery key you have never used is a key you do not have. The drill is:

  1. Find every key protector.
  2. Confirm you can read the actual key from outside the machine.
  3. Boot into the recovery prompt deliberately and get back in.

Fifteen minutes now, versus a bricked laptop at an airport.

Trigger Notes
TPM change or clear the most common
Secure Boot / firmware setting change measured boot changes
Boot order or boot manager change dual boot, USB boot
Motherboard or disk moved to another machine
Too many failed PIN attempts lockout
Windows update to firmware (sometimes) hence the “suspend” habit
Terminal window
manage-bde -status C:
manage-bde -protectors -get C:
Get-BitLockerVolume | Select-Object MountPoint,VolumeStatus,ProtectionStatus,KeyProtector

You will see protectors like:

  • TPM — automatic unlock, no user action;
  • TPM + PIN — PIN required at boot;
  • Numerical password — the 48-digit recovery key;
  • External key — a .bek file on a USB drive;
  • Password — for data volumes.

The numerical password is what the recovery screen asks for.

Step 2 — prove you can read it from outside

Section titled “Step 2 — prove you can read it from outside”
Location How you reach it when the machine will not boot
Microsoft account any other device, account.microsoft.com/devices/recoverykey
Entra ID another managed device, or the admin portal
Active Directory another domain machine (admins)
Printed / saved file wherever you put it — and this is where most people fail
manage-bde -protectors -get output only from a working OS

Write down which of these applies to this machine. “It’s in my Microsoft account” is only true if you know the account and can sign in — including the second factor.

Do this on a machine you can afford to reboot:

  1. Note the current key (screenshot or export): manage-bde -protectors -get C:.
  2. Suspend protection for one reboot: Suspend-BitLocker -MountPoint C: -RebootCount 1.
  3. Reboot and confirm you get in without a prompt (that is the suspend working).
  4. Now deliberately break measured boot: change a firmware setting (e.g. toggle Secure Boot) and boot.
  5. You should see the recovery screen. Enter the 48-digit key from your external copy, not from the screen.
  6. Restore the firmware setting.
  7. manage-bde -status — protection back to On.

If step 5 fails, you have found the real problem while the machine still works.

  • Suspend before firmware updates, dual-boot changes, or moving disks.
  • After any suspend, confirm manage-bde -status shows Protection On again.
  • Keep two external copies of the key, in different places.
  • Do not store the only copy on the encrypted disk.
Terminal window
# confirm protection is really on after maintenance
Get-BitLockerVolume | Select-Object MountPoint,ProtectionStatus,VolumeStatus,EncryptionPercentage

E1. Protector types and recovery behaviour are documented by Microsoft. The lab VMs use a vTPM without BitLocker enabled, so no recovery prompt was triggered.

Sources