Forum Discussion
BitLocker recovery still occurring after KB5089549 installation on HP EliteBook
Hi all,
We are experiencing ongoing BitLocker recovery prompts on a Windows 11 enterprise device even after successfully installing KB5089549, which Microsoft states fixes the recent Secure Boot / PCR7 BitLocker recovery issue.
Environment:
HP EliteBook G10
Windows 11 25H2
OS Build 26200.8457
Hybrid Azure AD Joined
BitLocker TPM protector enabled
Secure Boot enabled
VBS / Secure Launch enabled
What we already confirmed:
KB5089549 installed successfully
TPM healthy (Get-Tpm)
Secure Boot healthy (Confirm-SecureBootUEFI = True)
PCR7 Configuration = Bound
TPM protector recreated successfully
No pending HP BIOS/firmware updates via HP Image Assistant
BitLocker protection status healthy
Current issue:
The device still requests the BitLocker recovery key after every reboot.
We already tested:
Suspend BitLocker
Remove/re-add TPM protector
Multiple reboots
KB5089549 installation
No custom BitLocker PCR GPOs found
Hypervisor disabled using:
bcdedit /set hypervisorlaunchtype off
The issue still persists.
Interesting observations:
System has Secure Launch, SMM Firmware Measurement, and VBS enabled
USB4 / DisplayLink / dock-related drivers present
TPM protector uses PCR profile 7,11
Has anyone else seen:
continued BitLocker recovery after KB5089549,
especially on HP enterprise devices,
even when PCR7 shows “Bound” and Secure Boot/TPM health appear normal?
4 Replies
BitLocker recovery triggering after KB5089549 is consistent with what several organizations have reported when the update modifies boot configuration data in a way that the TPM interprets as a security state change. The update appears to be touching components that TPM monitors as part of the secure boot measurement chain, which causes the recovery prompt even on machines where nothing has actually changed from a security standpoint.
The most reliable resolution we found across multiple affected machines was suspending BitLocker before applying the update rather than dealing with recovery afterward. For machines already stuck in recovery, key retrieval from Azure AD or on-premises AD, depending on your backup configuration, should work cleanly if the keys were properly escrowed before the issue occurred.
It's worth checking whether your HP EliteBook BIOS is on the latest version as well because some EliteBook configurations have a BIOS interaction with this specific update that compounds the TPM measurement issue. HP released updated firmware that addresses part of this behavior on affected models.
We encountered this across several HP devices during a Microsoft 365 infrastructure rollout we were managing through Tech Distributor, our Microsoft distributor in Dubai. The pattern was consistent enough across machines that we flagged it before completing the full deployment, and the BIOS update combined with BitLocker suspension during patching resolved it on every affected unit.
Are the affected machines all on the same BIOS version, or is the issue appearing across different firmware revisions?
Thank you for the update and insight.
In my case, I believe the issue may have been triggered because KB5089549 was installed before suspending BitLocker protection. After the update and reboot process, the laptop now enters BitLocker recovery mode after every shutdown/restart.
I also checked BIOS/firmware through HP Image Assistant and the device is already on the latest available BIOS with no pending updates reported.
The logs show:
BitLocker Event 824
TPM-WMI Events 1796, 1800, and 1801
which seem related to Secure Boot/SBAT updates and TPM measurement changes during boot.
At this stage, it appears the system may still be in a partially synchronized Secure Boot measurement state even after the KB installation completed successfully.
Not sure if related, but have been facing a lot of issues since the latest April updates on our AVD Farms using Confidential Compute + Disk Encryption Set. All VM's immediately start in bitlocker recovery mode? Have tried the same steps during image build as mentioned above.
Based on the current behavior, this now appears more related to measured boot / PCR measurement drift rather than the original “invalid PCR7 configuration” issue Microsoft documented.
The symptoms seem closely related to the Secure Boot / BitLocker issue discussed in these articles:
https://support.microsoft.com/en-us/topic/may-12-2026-kb5089549-os-builds-26200-8457-and-26100-8457-28ec2a99-4bbe-481d-a340-5c6cf18d9acb
https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-bitlocker-recovery-issue-only-for-windows-11-users/
However, in this case:
KB5089549 installed successfully,
PCR7 is healthy/bound,
TPM and Secure Boot are healthy,
but BitLocker recovery still occurs after reboot.
I suspect there may still be an unresolved interaction involving:
