To stop BitLocker from asking for the 48‑digit recovery key on every restart, the root cause of recovery must be fixed and BitLocker protection reset. Simply turning BitLocker off risks data if something goes wrong during decryption, so the safer approach is to:
- Unlock with the recovery key
- At startup, enter the 48‑digit recovery password to boot Windows.
- Identify why the device is going into recovery
- Sign in to Windows with an admin account.
- Open an elevated Command Prompt (Run as administrator).
- Run:
manage-bde -status - Use this to check:
- Which protection mode is configured (TPM, TPM+PIN, startup key, etc.).
- Also review the event logs for BitLocker/boot events to see if recovery is triggered by:
- Boot file changes (firmware/BIOS/UEFI updates, bootloader changes)
- Hardware changes
- A forgotten PIN or missing startup key
- Fix common causes
Typical scenarios and actions:
- Forgotten PIN (TPM+PIN configured):
- While signed in, open BitLocker settings (Control Panel → BitLocker Drive Encryption).
- For the OS drive, choose Change PIN → Reset a forgotten PIN.
- Set a new PIN so future restarts use the PIN instead of the recovery key.
- Boot file or firmware changes:
- If a recent BIOS/firmware/bootloader change was intentional and the system is now stable, reset BitLocker’s validation profile by suspending and resuming protection (next step).
- Unknown/uncertain cause:
- Still proceed with suspend/resume to reset validation after confirming the system is clean and stable.
- Forgotten PIN (TPM+PIN configured):
- Reset BitLocker validation (suspend and resume)
This is the standard way to stop repeated recovery once the system is in a good state.
- In an elevated Command Prompt:
(This suspends BitLocker protection on the OS drive.)manage-bde -protectors -disable c: - Then re‑enable protection:
manage-bde -protectors -enable c: - Alternatively, in the BitLocker Control Panel, choose Suspend protection for the OS drive, then Resume protection.
- This resets the BitLocker validation profile so normal boots should no longer trigger recovery, assuming the underlying cause is resolved.
- In an elevated Command Prompt:
- Ensure recovery information is safely backed up
- Confirm the recovery key is stored in a secure location (for work devices, typically Microsoft Entra ID/AD DS or the organization’s portal).
- For self‑service, keys can be stored in Microsoft Entra ID and accessed via
https://myaccount.microsoft.com→ Devices → View BitLocker Keys, if your organization uses that.
- If recovery continues every restart
- There may be a persistent configuration or hardware issue (for example, unsupported TPM configuration, secure launch policies, or repeated boot file changes).
- In that case, involve the organization’s IT/helpdesk so they can:
- Review Group Policy (for example, virtualization-based security / secure launch settings).
- Check hardware/firmware compatibility.
- Decide whether to adjust security policies or re‑provision the device.
These steps preserve data while addressing the repeated recovery prompts. Decryption or OS reinstall should only be considered by IT as a last resort if the drive is accessible and data has been backed up.
References: