T The Triage ManualTechnical Guides for IT Emergencies
P1 · Endpoint & Device Management

BitLocker Recovery Prompt Triggered After Secure Boot Policy or Boot File Updates — TPM PCR Mismatch

BitLocker-protected drives enter recovery mode when changes to Secure Boot policy, bootloader files, or firmware alter TPM Platform Configuration Register (PCR) measurements, causing the TPM to refuse unsealing the Volume Master Key. This commonly occurs after Windows Updates touching boot components, UEFI firmware updates, or Secure Boot DB/DBX changes. A notable fleet-scale instance occurred after post-April 2026 structural Secure Boot DBX/DB validation updates, where devices running outdated OEM UEFI firmware with incompatible certificate storage entered persistent recovery loops due to invalid PCR7 states; Microsoft addressed this in the May 2026 quality update. Resolution requires the 48-digit recovery key to unlock the drive, followed by applying any required OEM UEFI firmware updates, then suspending and re-enabling BitLocker to re-seal against current boot measurements. Prevention requires escrowing recovery keys to AD/Azure AD, auditing PCR7 state fleet-wide before Secure Boot update rollouts, and suspending BitLocker before known boot-altering operations.

Indicators

Likely causes

Diagnostic steps

  1. Retrieve the BitLocker Recovery Key from the appropriate escrow location. For AD-joined devices: Active Directory Users and Computers → right-click the computer object → BitLocker Recovery. For Azure AD/Intune: Intune portal → Devices → select device → Recovery keys. For local backup: check saved .txt file or printed copy.
    Obtain the 48-digit recovery key required to unlock the drive and boot into Windows so further diagnosis can proceed.
  2. After successfully booting with the recovery key, open an elevated Command Prompt and run: manage-bde -protectors -get C:
    List all key protectors on the BitLocker volume, confirm the TPM protector is present, and identify the Key Protector ID associated with the TPM that failed.
  3. Check the BitLocker event log for the specific failure reason: Event Viewer → Applications and Services Logs → Microsoft → Windows → BitLocker-API → Management. Filter for Event IDs 853 and 24620 around the time of the failed boot.
    Identify which PCR or protector caused the recovery trigger, and whether it was a TPM measurement mismatch, Secure Boot policy change, or boot file modification.
  4. Run PowerShell command: Get-BitLockerVolume -MountPoint C: | Select-Object -ExpandProperty KeyProtector
    Confirm the TPM protector status, identify whether a TPM+PIN or TPM-only protector is in use, and verify no protectors are in an error state before re-sealing.
  5. Check which PCRs BitLocker is currently using: run manage-bde -protectors -get C: and review the 'PCR Validation Profile' line in the TPM protector section.
    Determine whether PCR 7 (Secure Boot state) is included in the validation profile — if so, any Secure Boot policy change will trigger recovery. This informs whether to adjust the PCR profile or simply re-seal.
  6. If the cause was a known update or firmware change, suspend BitLocker and re-enable it to re-seal the TPM against current measurements: manage-bde -protectors -disable C: followed by manage-bde -protectors -enable C:
    Re-seals the TPM key protector against the new (post-update) boot measurements, preventing recovery prompts on subsequent boots for the same configuration.
  7. On a functional baseline unit of the same hardware model, run 'msinfo32' and locate 'PCR7 Configuration' under System Summary. Confirm it reads 'Bound' or 'Available'.
    Establish the expected healthy PCR7 state for the hardware model before diagnosing affected devices.
  8. On the affected device (once booted via recovery key), run 'msinfo32' and compare the 'PCR7 Configuration' value against the healthy baseline. Also note 'BIOS Version/Date' and compare against the latest OEM firmware revision on the manufacturer's support portal.
    Confirm whether PCR7 is in an invalid/unbound state and whether an outdated UEFI firmware version is contributing to the issue.
  9. Check whether the May 2026 Windows quality update has been applied: Settings → Windows Update → Update History, or run 'Get-HotFix' in PowerShell.
    Determine whether the Microsoft-side fix for the post-April 2026 Secure Boot certificate compatibility issue has been deployed, isolating whether the remaining problem is the OEM UEFI firmware.

Resolution path

Prevention

Tools

References

bitlockersecure-boottpmrecoveryencryptionbootwindows-updatefirmwarepcrpcr7uefikey-managementactive-directoryazure-adintuneendpoint-securityevent-id-853event-id-24620certificate-updaterecovery-loopdbxoem-firmwarewindows-11april-2026may-2026-quality-update