Microsoft fixes BitLocker recovery bug that locked Windows Server 2025 admins out after April updates

Microsoft has closed out a frustrating known issue that pushed some Windows Server 2025 machines into BitLocker recovery on the first reboot after installing the April 2026 security update. The fix landed in this month's Patch Tuesday cumulative updates, KB5094125 for Windows Server 2025 and KB5093998 for Windows 11 23H2, roughly two months after the company first acknowledged the problem.

For anyone who walked into a data center to find production servers sitting at a recovery key prompt, the resolution is overdue. But the more interesting part of this story is why a routine security update could trigger full-disk encryption recovery in the first place, and why it hit so few machines.

What actually went wrong

BitLocker encrypts your drives and ties the keys to the state of the boot environment. On systems with a TPM, the chip records measurements of the firmware, boot manager, and boot configuration into Platform Configuration Registers, or PCRs. PCR7 specifically captures the Secure Boot state. When BitLocker is sealed against PCR7, the TPM will only release the volume key automatically if those measurements match what they were when the drive was protected. Change the boot path, and the TPM refuses to hand over the key, which is the recovery prompt working exactly as designed.

The April update changed the boot path. As part of the ongoing Secure Boot certificate rollover, Microsoft has been moving devices over to a 2023-signed Windows Boot Manager. On a healthy system that switch updates the PCR7 measurement cleanly and BitLocker keeps unlocking without complaint. The trouble appeared on a specific combination of conditions where the device was eligible for the new boot manager but its PCR7 binding was effectively invalid.

Microsoft was precise about the conditions, and all of them had to be true at once:

• BitLocker is enabled on the OS drive.
• The Group Policy "Configure TPM platform validation profile for native UEFI firmware configurations" is set, with PCR7 included in the validation profile (or the equivalent registry value applied manually).
• msinfo32.exe reports the Secure Boot State PCR7 Binding as "Not Possible".
• The Windows UEFI CA 2023 certificate is present in the Secure Boot Signature Database, making the device eligible for the 2023-signed boot manager to become the default.
• The device is not already running that 2023-signed boot manager.

That "Not Possible" PCR7 binding is the tell. It means the system was sealing BitLocker to PCR7 even though the platform could not reliably support a PCR7 binding, which Microsoft flags as an unrecommended configuration. When the boot manager swap rewrote what PCR7 measured, the seal broke and recovery kicked in.

The good news for affected admins was that the prompt was a one-time event. "The BitLocker recovery key only needs to be entered once," Microsoft said, "subsequent restarts will not trigger a BitLocker recovery screen, as long as the group policy configuration remains unchanged." Annoying, but not a repeating loop, provided you had your recovery keys on hand.

Why most people never saw it

This bug could in theory touch Windows 11 as well, but Microsoft said personal devices were unlikely to be affected. The configurations that trip the issue, hardened TPM platform validation profiles pushed through Group Policy, are the kind of thing corporate IT teams configure deliberately. A consumer laptop running default BitLocker settings simply does not meet the criteria. This was an enterprise problem, and specifically an enterprise problem on the small slice of fleets running that particular PCR7 setup.

That narrowness is worth keeping in mind. The headline reads like a broad BitLocker failure, but the population of impacted machines was small and well defined.

How the fix works

Rather than changing how PCR7 is measured, Microsoft's fix sidesteps the trigger. "To prevent the unexpected BitLocker recovery key prompt, devices with this incompatible group policy configuration are prevented from installing the 2023-signed Windows Boot Manager," the company explained in its updated advisories. In other words, if your policy puts you in the risky bucket, the update no longer promotes the new boot manager on your machine, so the PCR7 measurement stays put and the seal holds.

There is a diagnostic breadcrumb too. "If your device was impacted, you will see Event ID 1032 in the System event log when installing Windows updates," Microsoft noted in a service alert. Admins reviewing their fleet for exposure should grep their event logs for that ID.

Practical advice for admins

If you can deploy the June updates, do that and the issue resolves itself. For teams that cannot roll out KB5094125 or KB5093998 yet, Microsoft offers two interim paths:

• Remove the offending Group Policy configuration before installing KB5082063 or later updates, and make sure BitLocker bindings actually use the PCR7 profile correctly rather than sealing against a binding the platform reports as "Not Possible".
• If you cannot touch the policy before deployment, apply a Known Issue Rollback (KIR) on affected devices. The KIR blocks the automatic switch to the 2023 Boot Manager, which is the action that sets off the recovery prompts.

Whatever route you take, this is a good reminder to verify that your BitLocker recovery keys are actually escrowed and retrievable, whether in Active Directory, Microsoft Entra, or your MDM of choice. A one-time recovery prompt is a minor inconvenience if you can pull the key in seconds, and a genuine outage if you cannot.

A recurring pattern

This is not the first time a security update has collided with BitLocker. In August 2024, Microsoft fixed a known issue that triggered recovery prompts across all supported Windows versions after the July 2024 updates. In May 2025, the company shipped emergency updates after the May 2025 security release pushed Windows 10 systems into recovery. The common thread is the same: anything that alters the measured boot environment, including the Secure Boot certificate transitions Microsoft is steadily rolling out, can break a TPM-sealed key.

That is the real takeaway for anyone running encrypted fleets. As Microsoft works through the multi-year Secure Boot certificate refresh, boot components will keep changing underneath your TPM measurements. Auditing your PCR7 bindings now, confirming that platform validation profiles match what your hardware can actually support, and double-checking recovery key escrow are the steps that turn the next one of these advisories from a fire drill into a non-event. The pattern is predictable enough that treating BitLocker recovery readiness as standing operational hygiene, not a reaction to each individual patch, is the sensible posture.