BitLocker asking over and over for a recovery key

The behavior is consistent with BitLocker entering recovery because the Secure Boot measurements in TPM PCR 7 no longer match what was recorded when the TPM protector was last updated.

Key points from the scenario:

• Error text indicates an unexpected Secure Boot policy change.
• BitLocker uses TPM PCRs (especially PCR 7 on modern/Connected Standby devices) to validate Secure Boot state before automatically unlocking.
• When the Secure Boot configuration or its measurements change unexpectedly, BitLocker cannot validate the boot chain and repeatedly falls back to recovery.

From the BitLocker preboot recovery documentation:

• E_FVE_SECUREBOOT_CHANGED is raised when the Secure Boot configuration unexpectedly changed and the boot configuration measured in PCR 7 changed. This can be due to:
  • An additional measurement now present that was not present when BitLocker last updated the TPM protector.
  • A missing measurement that was present before.
  • An expected event having a different measurement.
• In this case, a BitLocker recovery method is required to unlock the device.

Additionally, if the TPM protector is using PCRs beyond the default PCR 7 and PCR 11 (for example, due to custom Group Policy or Secure Boot being altered), firmware or Secure Boot–related changes can cause persistent recovery prompts. Devices that support Connected Standby must use PCR 7, and BitLocker in its default configuration binds to PCR 7 and PCR 11 when Secure Boot is correctly configured.

Likely causes in this environment include:

1. A Secure Boot configuration or certificate change (for example, Secure Boot DB/KEK updates, OEM firmware updates, or Secure Boot policy changes) that altered the PCR 7 measurements without BitLocker being suspended and resumed.
2. Group Policy that explicitly configures non‑default PCRs for the TPM protector, causing BitLocker to be sensitive to additional firmware/boot changes.

Recommended remediation steps:

1. Verify the BitLocker TPM protector PCR profile on an affected device:
   • Run in an elevated Command Prompt:

          manage-bde.exe -protectors -get <OSDriveLetter>:
     

   • Confirm which PCRs are in use. Default on modern devices is PCR 7 and PCR 11.
2. Restore default Secure Boot and PCR configuration:
   • Ensure Secure Boot is enabled and configured to the standard vendor/Microsoft configuration (for example, on Surface devices, set Secure Boot to “Microsoft Only”).
   • Remove or adjust any Group Policy Objects that explicitly configure non‑default PCRs for BitLocker TPM protectors. See BitLocker Group Policy settings for details.
3. Re‑seal BitLocker to the current Secure Boot state:
   • Suspend BitLocker on the OS volume, reboot once so the firmware/Secure Boot state is measured consistently, then resume BitLocker so the TPM protector is updated to the new PCR measurements. For example (PowerShell, elevated):

          Suspend-BitLocker -MountPoint "<DriveLetter>:" -RebootCount 0
     

   • Reboot the device, confirm it boots normally.
   • Then run:

          Resume-BitLocker -MountPoint "<DriveLetter>:"
     

   • This updates the TPM protector with the current Secure Boot/PCR 7 measurements and should stop the repeated recovery prompts as long as Secure Boot configuration remains stable.
4. For devices already stuck in recovery after a firmware/Secure Boot change:
   • Unlock using the recovery key.
   • Ensure Secure Boot is in the intended configuration.
   • Then perform the suspend/reboot/resume sequence above so BitLocker binds to the new, stable PCR measurements.

If Secure Boot or firmware continues to change (for example, staged Secure Boot certificate updates applied over multiple reboots), BitLocker may enter recovery again until those changes are complete and BitLocker is re‑sealed to the final configuration.

References:

• BitLocker preboot recovery screen
• BitLocker recovery: known issues