You power on your Snapdragon laptop and instead of the sign-in screen you get a blue BitLocker recovery prompt demanding a 48-digit key. You enter the key, Windows boots — and the next morning the prompt is back again. The loop feels like the laptop forgot how to trust itself.

On Copilot+ PCs and Windows 11 on ARM, BitLocker seals its encryption key to the TPM along with measurements of the boot chain: firmware version, Secure Boot state, and boot configuration. Any change to that chain — a BIOS update, a Secure Boot toggle, a cleared TPM, even an interrupted update — invalidates the seal, and the TPM refuses to release the key silently. One prompt after a firmware change is normal; a prompt on every boot means the trust chain is still broken.

This guide gives you six fixes in technician order: recover the key safely first, then identify what broke the seal, then restore the TPM trust chain so automatic unlock returns. Do not change boot settings until your recovery key is safely stored on a second device.

Why this happens

  • Firmware update invalidated the TPM seal: BIOS/UEFI updates change the measured boot state, so the TPM no longer matches the seal it made — the most common trigger on ARM laptops, where firmware updates arrive bundled with Windows Update.
  • Secure Boot was toggled or reset: Turning Secure Boot off, or a firmware update resetting its keys, changes a measured component and forces recovery on every boot until protection is re-sealed.
  • TPM was cleared or ownership changed: A cleared TPM (sometimes after a motherboard-adjacent firmware repair) loses the stored key; until BitLocker re-takes ownership, every boot asks for the recovery key.
  • Boot configuration data changed: Switching boot order, enabling a new boot device, or a failed BCD edit alters what the TPM measures, breaking the seal even though nothing about the OS changed.
  • TPM driver or firmware out of sync: ARM platforms rely on firmware TPM (fTPM); if the fTPM firmware is stale relative to the OS TPM stack, releases can fail intermittently and land you on the recovery screen.
  • Thunderbolt/USB boot devices attached: Some ARM laptops measure attached bootable USB devices into the PCR state — leaving a bootable flash drive plugged in can trigger the prompt on an otherwise healthy machine.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Secure your 48-digit recovery key on a second device

Nothing else in this guide is safe until the key is retrievable from somewhere other than the locked laptop. This takes five minutes and prevents a routine fix from becoming a data-loss event.

  1. On a phone or second computer, sign in at Microsoft’s Windows support hub to find guidance on locating your 48-digit recovery key — it is usually stored under your Microsoft account’s devices list. Work and school devices store it in Entra ID.
  2. Open the laptop’s entry and expand BitLocker info — copy the 48-digit key (in groups of six) somewhere durable, like a password manager.
  3. If the device is work-managed, ask your IT admin for the key from Entra ID / Intune instead.
  4. Test-read the key back once to confirm you copied it correctly — a single wrong digit wastes a boot attempt.
  5. Keep that second device nearby for the rest of this guide; you may need the key one or two more times.

Fix 2: Identify what changed — the single-boot test

A one-time prompt after a change is normal; a loop is not. Before repairing anything, determine whether the prompt is a single event or a genuine loop, because the repair path differs.

  1. Enter the recovery key and boot into Windows fully.
  2. Open an elevated Command Prompt and run manage-bde -status C: — note whether protectors show as enabled and whether the TPM protector is present.
  3. Restart immediately (Start > Power > Restart, not Shut down) with no USB drives attached.
  4. If the prompt returns on this clean restart, you have a broken seal — continue to Fix 3. If it boots cleanly, the prompt was a one-time seal break and you are done; consider what changed recently (firmware update, Secure Boot toggle) and note it.
  5. While you are here, check for TPM firmware updates that fail mid-install if Windows Update recently attempted one — a half-applied fTPM update is a classic loop trigger.

Fix 3: Suspend BitLocker, update firmware, then resume protection

Firmware drift is the top cause. The correct sequence is: suspend protection (which stores a clear key temporarily), apply all firmware, then resume so the TPM re-seals against the new measurements.

  1. In Windows, open an elevated Command Prompt and run manage-bde -protectors -disable C: to suspend BitLocker.
  2. Install every pending firmware/driver update: check Windows Update > Advanced options > Optional updates, then your maker’s support page — Dell , HP , or Lenovo — for a BIOS/UEFI update for your exact model.
  3. Apply the firmware update on AC power with nothing else running; do not interrupt it.
  4. After the firmware update completes and Windows boots, run manage-bde -protectors -enable C: to resume protection and re-seal the key to the new measurements.
  5. Restart twice to confirm the prompt is gone on both boots — the re-seal only proves itself after a full power cycle.

Fix 4: Restore Secure Boot to its sealed state

If Secure Boot was toggled off — by you, by a repair tool, or by a firmware reset — the TPM seal breaks because Secure Boot state is part of the measured boot chain. Re-enabling it usually restores silent unlock.

  1. Enter the recovery key and boot into Windows, then restart into UEFI: Settings > System > Recovery > Advanced startup > Restart now > Troubleshoot > UEFI Firmware Settings.
  2. Find the Secure Boot option (usually under Security or Boot) and set it to Enabled.
  3. While there, confirm TPM / Security Device is enabled too — a disabled TPM produces the same loop with a different cause.
  4. Save and exit; enter the recovery key one final time if prompted.
  5. Back in Windows, run manage-bde -protectors -enable C: if protection shows as suspended, then restart to verify silent boot.

Fix 5: Clear the TPM and let BitLocker re-take ownership

When the TPM’s stored state is corrupt — after a failed firmware flash or an interrupted update — the cleanest repair is a TPM clear followed by BitLocker re-initialization. The recovery key you secured in Fix 1 makes this safe.

  1. With protection suspended (manage-bde -protectors -disable C:), open Windows Security > Device security > Security processor details > Security processor troubleshooting.
  2. Click Clear TPM and restart when prompted — the firmware will ask for confirmation on the next boot.
  3. Confirm the clear at the firmware prompt; Windows will re-initialize the TPM automatically on the next boot.
  4. Back in Windows, run manage-bde -protectors -enable C: to re-seal BitLocker to the fresh TPM.
  5. Restart twice and confirm no prompt appears. If it does, the firmware itself is the problem — check your maker for a newer BIOS rather than clearing again. Similar firmware-first logic applies when Intel Arc drivers keep crashing on Lunar Lake after updates — the platform firmware is the foundation everything seals against.

Fix 6: Remove boot-chain variables and check for deeper issues

If the loop survives a re-seal, something in your boot environment keeps changing the TPM measurements. Eliminate variables before suspecting hardware.

  1. Disconnect all USB drives, docks, and SD cards, then restart — a bootable device in the chain can flip PCR measurements on some ARM firmware.
  2. Run bcdedit /enum in an elevated prompt and look for duplicate or orphaned boot entries; a failed dual-boot experiment is a common hidden cause.
  3. If you recently ran x64 emulation-heavy workloads, confirm your tooling matches the platform — running VS Code ARM-native versus x64-emulated makes no difference to BitLocker, but knowing your software stack is correct rules out a misattributed cause when PyTorch workloads skip the NPU and you start suspecting the whole system.
  4. As a last resort, back up your data and use Settings > System > Recovery > Reset this PC with the “keep my files” option, which rebuilds the boot chain cleanly.
  5. If the loop persists past a reset, the TPM hardware or firmware is faulty — contact your laptop maker’s support with the exact prompt text and your service tag.

Closing

A BitLocker recovery loop on an ARM laptop is the TPM telling you the boot chain changed — usually firmware drift or a Secure Boot toggle. Secure the key first, suspend protection, update firmware, re-enable, and let the TPM re-seal. The prompt is a symptom of a broken measurement, not broken encryption, and a clean re-seal fixes it in nearly every case.

Frequently asked questions

Why does my ARM laptop ask for a BitLocker recovery key on every boot?
Every-boot prompts mean the TPM stopped releasing the key automatically — usually after a firmware update, a Secure Boot change, or a TPM clear. Fix the underlying trust break (firmware, Secure Boot state, TPM ownership) rather than typing the key forever.
Where do I find my BitLocker recovery key?
Sign in to your Microsoft account and check account.microsoft.com/devices — the 48-digit key is usually stored there. Work and school devices store it in Entra ID. Keep it retrievable from a second device before changing boot settings.
Does disabling Secure Boot trigger the BitLocker prompt?
Yes. The TPM seals the BitLocker key to the Secure Boot state, so toggling Secure Boot, updating BIOS firmware, or changing boot options all invalidate the seal and force the recovery screen on ARM laptops.
Can a Windows Update cause the recovery key loop?
Occasionally. A feature or firmware update that touches the boot chain or TPM driver can break the TPM’s sealed state. The fixes in this guide — suspend protection, update firmware, then re-enable — resolve most post-update loops.