Got an HP laptop demanding the 48 digit BitLocker recovery key on every restart since the June update? You're not imagining it. A Secure Boot change in the June 2026 servicing cycle is tripping BitLocker on some business machines, and HP EliteBook 840 G-series devices are showing up the most. The error usually reads "Secure Boot policy has unexpectedly changed."

Here's the fix.

Quick Fix

Suspend BitLocker, reboot once, then let it resume. This re-seals the encryption key to the new Secure Boot state.

PowerShell, run as administrator:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1
Restart-Computer

-RebootCount 1 tells BitLocker to turn protection back on automatically after the next reboot, so you don't have to remember to resume it.

Prefer the GUI? Open Control Panel, go to BitLocker Drive Encryption, click Suspend protection on the OS drive, restart, then click Resume protection.

What This Does

BitLocker ties its key to a set of firmware measurements stored in the TPM, and one of those measurements covers the Secure Boot policy. When the June update rotated the Secure Boot certificate, that measurement changed, so the TPM stopped releasing the key automatically and Windows fell back to asking for the recovery key.

Suspending protection lets the new measurement become the trusted baseline. When you resume, BitLocker re-seals the key to the current state and the prompts stop.

If That Didn't Work

A few things to check when the prompt keeps coming back.

Use an external USB keyboard for key entry. On some HP models the built-in keyboard isn't active at the pre-boot recovery screen, so you can't type the key at all without one plugged in.

Update the BIOS and firmware. HP has pushed firmware that handles the new Secure Boot certificate cleanly. Pull the latest from HP's support site for your exact model before assuming the update itself is broken.

Confirm the recovery key is escrowed. Before you touch anything, make sure the key is saved in Microsoft Entra ID, Active Directory, or a printout. You can pull it from the command line if you have admin access. See Get BitLocker Recovery Key (CLI).

What Causes This

Microsoft is in the middle of a multi-month Secure Boot certificate rollout. The original certificates that sign the Windows boot components are expiring this year, so updated certificates are being pushed in stages. The June update advances that rollout, and on affected hardware the new policy changes the value the TPM measured when BitLocker first sealed its key.

BitLocker is doing exactly what it's designed to do. A changed Secure Boot policy looks like tampering, so it refuses to release the key and demands proof you own the machine. The suspend and resume cycle just re-baselines that trust.

Prevent It On Your Fleet

If you manage business laptops, get ahead of this before users hit it.

Suspend BitLocker before pushing firmware or major Secure Boot updates, then resume after the reboot. A short script with Suspend-BitLocker -RebootCount 1 across the fleet saves a lot of help desk calls.

Verify every device has its recovery key escrowed to Entra ID or Active Directory. Unmanaged or BYOD machines are where this bites hardest.

Watch the Secure Boot status in Windows Security on machines you don't manage centrally. Many will quietly flip to "Updated" on their own, but the stragglers are the ones that surprise people.

This is the same class of issue we covered for the April update. The trigger changes month to month, but the suspend and resume fix is consistent.

Fix BitLocker Recovery Prompt After KB5082063

Fix Secure Boot Certificate Expiration Before June 2026

Get BitLocker Recovery Key (CLI)

Need help managing BitLocker across a fleet of business laptops? Contact Rain City Techworks.