What causes BitLocker Recovery Mode?

(Last updated on September 14, 2020)

Sysadmins often ask us about BitLocker Recovery Mode. They have implemented BitLocker as their endpoint encryption solution which means that the IT service desk now has to issue recovery keys. Here’s where it gets complicated – the recovery keys are 25-digit hexadecimal numbers which are awkward to read, but also hear over a phone line.

This blog will look at the root causes of BitLocker Recovery Mode, and how your organization can mitigate the issue with self-service key recovery.

Authenticating to BitLocker

Let’s start with an overview of BitLocker authentication methods since they can trigger lockouts. The most common authentication method is using the Trusted Protection Module (TPM), a microchip that is built into some laptops and desktops. It automatically decrypts hard drives on startup, without requiring the use of a PIN code, USB, or other form of authentication. This method does not require the user to do anything, and it is the least secure.

Microsoft recommends using the TPM with a BitLocker PIN or startup key loaded on a USB to uplift security.  Both options require user interaction and can lead to lockouts in the event of a forgotten PIN, or lost USB.

Causes of BitLocker Recovery Mode

BitLocker Recovery Mode can occur for many reasons, including:

Authentication errors:

  • Forgetting the PIN
  • Entering incorrect PIN too many times (activating the anti-hammering logic of the TPM)
  • Using a keyboard with a different layout that doesn’t enter the PIN correctly, or one that doesn’t map as assumed by the pre-boot environment
  • Losing the USB flash drive containing the startup key

Boot/BIOS changes:

  • Turning off BIOS support for reading USB devices in the pre-boot environment when using USB-based keys
  • Changing the BIOS boot order to boot another drive ahead of the hard drive (such as giving a CD or DVD drive boot sequence priority)
  • Upgrading critical early startup components such as BIOS upgrades
  • Changes to the master boot record (MBR) on the disk
  • Changes to the boot manager (bootmgr) on the disk
  • Failing to boot from a network drive before booting from the hard drive
  • Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive

Hardware, software and firmware changes:

  • Inserting or removing a CD/DVD
  • Docking or undocking a portal computer if the computer was (respectively) undocked or docked when BitLocker was turned on
  • Changes to NTFS partition table on the disk including: Creating, Deleting, Resizing primary partition
  • Turning off, disabling, deactivating, or clearing the TPM
  • Updating option ROM firmware
  • Upgrading TPM firmware
  • Adding or removing hardware
  • Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards

Other triggers:

  • Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile
  • Hiding the TPM from the operating system
  • Moving the BitLocker-protected drive to a different system
  • Upgrading the motherboard to a new one with a new TPM
  • Failing the TPM self-test
  • Having a BIOS or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer
  • Changing the usage authorization for the storage root key of the TPM to a non-zero value
  • Disabling the code integrity check or enabling test signing on Windows Bootmgr
  • Removing, inserting, or completely depleting the charge on a smart battery (portal computer)
  • Pressing the F8 or F10 key during the boot process

What are PCR’s?

A lot of the above reasons are self-explanatory, but Modifying the Platform Configuration Registers (PCRs) is not always fully understood, or configured correctly. Basically, these settings tell the TPM chip what to check, during the power-on cycle, that the disk is still booting inside a valid machine that hasn’t been tampered. If the check completes, the TPM chip will release the keys to allow BitLocker to boot the encrypted disk.

When a machine is encrypted it stores the state of the BIOS/UEFI settings. Any changes to this state can cause the BitLocker recovery mode to kick in. This could be something as simple as choosing a different boot device at startup if not configured correctly based on the network requirements of your organisation. E.g. if you normally boot from Hard Disk but need to boot from a CD/NIC/USB for some reason.

In an enterprise environment the PCR settings are configured using Group Policy. For BIOS-based computers, you can find the settings here:

Computer Configuration>Polices>Administrative Templates>Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for Bios-based firmware configurations

But don’t forget your UEFI based computers must be configured in a separate location as shown here:

Computer Configuration>Polices>Administrative Templates>Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure TPM platform validation profile for native UEFI firmware configurations

If you are using MDOP MBAM to deploy and configure BitLocker, these settings can be found in the ADMX templates that are added as depicted below:

For BIOS-based settings there is a great blog post about them here:


For UEFI-based Computers, which tend to be more prevalent today. I’ll cover the PCR’s in more detail below. Microsoft recommends using PCRs 0, 2, 4 and 11. Note: PCR 11 must be enabled as this is specific to enabling BitLocker on the device.

  • PCR 0: Core System Firmware Executable Code – Checks for changes to the code on the UEFI firmware – this includes Firmware Updates!
  • PCR 1: Core System Firmware Data – Changes to usually static data (serial, model numbers), but also things like the amount of RAM and CPU type.
  • PCR 2: Extended or pluggable executable code – Option ROM checking for external devices i.e. what’s plugged in during boot and is it valid/has it changed.
  • PCR 3: Extended or pluggable firmware data – Option ROM static data i.e. optional hardware components such as network cards or firmware that might be used during the booting process.
  • PCR 4: Boot Manager – Is your device likely to boot from the same device all the time. Do you push OS deployments from the network using PXE boot? Or has dual boot enabled? Then you might not want to enable this check.
  • PCR 5: GPT/Partition Table – This will check for any changes to the Partition lists e.g. adding and removing partitions, resizing disks, etc.
  • PCR 6: Resume from S4 and S5 power state events – Checks to see if the system has resumed from Hibernation(S4) or a Soft Off (S5).
  • PCR 7: Secure Boot State – Has this changed or is this likely to change?
  • PCR 8/9/10 and 16/17/18/19/20/21/22: Reserved for future use, not defined yet.
  • PCR 11: BitLocker Access Control – this must be enabled.
  • PCR 12/13/14/15: Looks for changes to the OS Kernel, File system, libraries, network connections etc.

Self-service Key Recovery

There are many possible scenarios that can cause BitLocker Recovery to occur. How can we minimize the impact on the user and the service desk while also tackling the possibility of the service desk giving out the recovery key to a malicious actor?

Well that’s where our enterprise solution, Specops Key Recovery, comes in! When a user is prompted for a BitLocker recovery key, they can use the solution to prove their identity with multi-factor authentication (Google Authenticator, Duo Security, SMS, etc.) without having to call the service desk.

Using the information above you should be able to find a good balance between security and usability when deploying BitLocker to your organisation.

Tags: , ,

Written by

Darren James

Product Specialist, Specops Software

More Articles
Back to Blog