Entering a 48-digit key once after a big change is BitLocker doing its job. Entering it every single morning means something keeps changing in your boot chain — or the TPM stopped trusting it. Here is how to find which.
The recovery screen exists for one reason: before unlocking your drive, the TPM compares the current boot state against the state it trusted when BitLocker was set up. If they differ, it asks for the key instead — by design. A one-off prompt after a BIOS update is normal. A prompt at every boot means the difference never goes away. This page lists the real causes, from the embarrassingly simple to the genuinely broken, and the fix order that solves the loop without turning encryption off.
The most common trigger. A BIOS update changes the firmware code the TPM measures, so the old seal no longer matches. Honest behaviour: one recovery prompt after the update, then normal booting once you have entered the key and Windows re-seals to the new state. If the update is still pending on your machine, suspend BitLocker first — and if the prompts continue long after the update finished, keep reading; something else is changing daily.
Switching Secure Boot off or on, changing the boot device order in BIOS, or booting from a USB drive all alter the measured chain. The classic pattern: someone enabled or disabled Secure Boot while fixing something else and never connected it to the new morning ritual. Set the BIOS the way you intend to keep it — Secure Boot on, Windows Boot Manager first — enter the key once, and the loop should end. A BIOS that forgets its settings (dying CMOS battery on older desktops) recreates this fault forever until the battery is replaced.
A new motherboard is a new TPM trust relationship entirely — expect recovery and a re-seal. Docking stations rarely cause it, but replaced drives, moved boot disks between machines, and dual-boot setups that modify the boot loader can. Linux installs that rewrite the boot chain are a frequent silent culprit on dual-boot PCs: the honest fixes are to let each OS keep its own boot path, or accept the key prompt as the price of that layout.
Once you have entered the key and reached Windows, force BitLocker to re-seal against the current state:
The command-line equivalent is manage-bde -protectors -disable C: -RebootCount 1 followed by manage-bde -protectors -enable C: after the restart.
Clear signs the problem is deeper: the prompt survives a suspend-resume cycle, BIOS settings revert on their own, or the date in BIOS is wrong after every shutdown. On older desktops, replace the CMOS battery. As a last resort, clearing the TPM (tpm.msc → Clear TPM) forces a completely fresh trust setup — but do it only with the recovery key in your hand, because the next boot will demand it, and afterwards confirm protection shows On again with manage-bde -status.
BitLocker enable karne ka pura process — recovery key save karne se lekar verify karne tak, live step-by-step is video me dikhaya gaya hai.
▶️ Watch Full VideoYes — once. A BIOS update legitimately changes the boot measurements, the TPM asks for the key a single time, and Windows then re-seals to the new state. Asking at every boot afterwards is not normal and has a separate cause.
No. Suspend only pauses the TPM check — the drive stays fully encrypted the whole time, and resume re-seals the protectors against the current boot state. Nothing is decrypted and no files are touched.
The usual suspects are BIOS settings that do not survive shutdown (a failing CMOS battery), a dual-boot loader being rewritten, or Secure Boot being toggled by another tool. Fix the thing that changes, then suspend and resume once to re-seal.