Stop a repeated BitLocker recovery prompt after a BIOS, firmware, or Windows update

This writeup is an explicit exception to the standing unlocked-volume assumption. BitLocker can request the 48-digit recovery password after firmware, TPM, Secure Boot, boot-manager, or measured-boot changes. A one-time prompt can be expected after a legitimate change. A prompt on every boot usually means the trusted boot state is not stable or the TPM protector has not resealed to the current configuration.

Searchable Windows error codes and exact messages

Use this procedure when the correct recovery password is accepted and Windows can boot, but recovery returns on later restarts after a known update or firmware/security change. The TPM and Secure Boot configuration must be intended and stable before resealing.

Do not use it when the recovery password is unavailable, the Key ID does not match, the volume will not unlock, the disk has I/O errors, Windows never reaches the desktop after the key is accepted, or the next failure is a separate boot problem. Use FIX-056 when the key is accepted but Windows returns to recovery or Automatic Repair.

The exact PCR that changed may remain unknown. The matching recovery password, recovery Key ID, current encryption state, current protectors, and intended TPM/Secure Boot state may not remain unknown.

• Matching 48-digit recovery password stored safely
• Administrative Windows session after successful recovery
• Stable AC power for any authorized firmware work
• Current firmware/update history
• A second copy of the recovery information before protector changes

Enter the matching recovery password once and boot Windows. Do not clear TPM, delete protectors, decrypt the drive, or keep changing firmware settings between test boots.

1. Photograph the recovery screen and record its Recovery Key ID and reason text.

2. After Windows starts, open an elevated Command Prompt:

   manage-bde -status
   manage-bde -protectors -get C:
   

   In a running Windows session, C: is normally the system volume; confirm it from the output.

3. Confirm the volume is protected, the TPM-related protector exists where expected, and the recovery password protector is present.

4. Record msinfo32 values for BIOS Mode, Secure Boot State, BIOS version/date, and Windows build. Detection is the goal; do not ask the reader to guess firmware mode.

5. Review Windows Update history and the OEM firmware history. Identify whether each recovery prompt follows a restart, full shutdown, dock change, or firmware-setting loss.

6. Reboot once without changing anything. If recovery does not return, treat it as a one-time expected recovery and do not reseal unnecessarily.

1. Save the recovery password and current protector inventory outside the computer.

2. Stabilize the intended platform state first. If firmware settings reset on every power loss, Secure Boot or TPM repeatedly disables itself, or the BIOS clock/settings do not persist, stop and repair that platform problem before BitLocker.

3. If another authorized firmware update or boot-chain change is still pending, suspend protection for a bounded number of restarts:

   manage-bde -protectors -disable C: -RebootCount 2
   

4. Verify the command reports protection suspended. Complete only the planned, exact-model update or configuration correction.

5. Boot Windows in the final intended configuration. Confirm TPM and Secure Boot state again.

6. Resume protection:

   manage-bde -protectors -enable C:
   manage-bde -status C:
   manage-bde -protectors -get C:
   

7. If no additional platform change was pending and the state is already stable, one suspend/restart/resume cycle can reseal protection:

   manage-bde -protectors -disable C: -RebootCount 1
   shutdown /r /t 0
   

   After the restart, verify protection resumed automatically. Do not repeat cycles indefinitely.

• One prompt, then normal boots: expected recovery after a measured change; no further action may be needed.
• Repeated prompts stop after a bounded suspend/resume: the protector resealed to the stable configuration.
• Prompt returns because TPM/Secure Boot state changes again: firmware/platform instability remains; do not delete protectors to mask it.
• Key is accepted but Windows enters repair: route to FIX-056 and diagnose the next screen.

Do not clear the TPM, delete the only recovery-password protector, turn BitLocker off as a first response, disable Secure Boot merely to avoid the prompt, or publish the recovery password in screenshots or logs. Do not suspend indefinitely.

If a planned platform change causes new recovery prompts, return the single changed setting or exact OEM firmware through its supported rollback method, then boot with the recovery password and reassess. Protector suspension itself does not decrypt data; re-enable protection once the intended state is restored.

Verify manage-bde -status reports protection on, retain an external copy of the recovery information, then perform two restarts and one full shutdown/start. Confirm the Key ID does not reappear and Secure Boot/TPM state remains unchanged.

Confidence is about 80% when the prompt began after a documented measured-boot change, the matching key works, platform state is stable, and a bounded suspend/resume prevents recurrence. Stop if settings will not persist, the TPM is unavailable, the key does not match, the disk reports errors, or the computer is organization-managed and policy controls protector configuration.