What happened
Microsoft has fixed a bug that pushed some Windows Server 2025 machines into the BitLocker recovery screen after the April 2026 security update. The fix shipped in the June 2026 Patch Tuesday updates: KB5094125 for Windows Server 2025 and KB5093998 for Windows 11 23H2, which was also affected.
If you spent part of April hunting down 48-character recovery keys for servers that were working fine the night before, this is the official close-out. In Microsoft's words, the update "addresses an issue where some devices might enter BitLocker Recovery after updating boot files on systems with certain Trusted Platform Module (TPM) validation settings."
The bug did not put data at risk. BitLocker did exactly what it was designed to do: the boot environment changed in a way the TPM measurements no longer matched, so the drive refused to unlock automatically and demanded the recovery key. The problem was that the change came from Microsoft's own update, on configurations Microsoft itself describes as "unrecommended," at scale.
Background
BitLocker on a TPM-protected system seals the volume encryption key against Platform Configuration Registers (PCRs), which hold measurements of the boot chain. If a measured component changes, the TPM will not release the key and the machine drops to recovery. PCR7 is the register tied to Secure Boot policy, and binding to it is normally the resilient choice because it tolerates routine boot file updates as long as Secure Boot policy itself is unchanged.
The April update tripped over a narrow but very enterprise-shaped combination of settings. A device had to meet all five of these conditions to be affected:
- BitLocker enabled on the OS drive.
- The Group Policy "Configure TPM platform validation profile for native UEFI firmware configurations" configured with PCR7 included in the profile.
- System Information reporting Secure Boot State PCR7 Binding as "Not Possible".
- The Windows UEFI CA 2023 certificate present in the Secure Boot Signature Database.
- The device not yet running the 2023-signed Windows Boot Manager.
That last pair of conditions is the interesting part. Microsoft is in the middle of rolling the Windows boot chain over to components signed by the newer Windows UEFI CA 2023 certificate, because the 2011-era Secure Boot certificates are reaching expiry. The April update swapped in the 2023-signed boot manager on eligible systems. On machines where an admin had hard-coded a custom TPM validation profile that included PCR7, but where PCR7 binding was not actually possible, that boot manager swap changed the measured values and BitLocker fell back to recovery.
Home users were largely spared. The trigger requires a deliberately configured Group Policy, which is why the impact landed almost entirely on domain-joined servers and managed Windows 11 23H2 fleets.
This is also not new territory. It is the third BitLocker recovery incident tied to a Windows update in recent memory, after similar episodes in July 2024 and May 2025. The pattern is consistent: an update modifies the boot chain, a subset of TPM validation configurations cannot absorb the change, and helpdesks spend a week reading recovery keys over the phone.
The fix and the workarounds
The June updates take a pragmatic approach: rather than making the custom PCR profile tolerate the new boot manager, Microsoft simply prevents affected devices from installing the 2023-signed Windows Boot Manager. When the fix lands on an affected machine, it logs Event ID 1032 in the System event log so you can identify which devices were held back. Microsoft notes that "subsequent restarts will not trigger a BitLocker recovery screen, as long as the group policy configuration remains unchanged."
For fleets that cannot deploy the June updates yet, there are two documented paths:
- Remove the Group Policy. Clear the custom TPM platform validation profile before installing KB5082063 or later, and let BitLocker re-bind using the default PCR7 profile. This is the durable fix, since the default profile is what Microsoft designs updates around.
- Known Issue Rollback (KIR). Apply the KIR policy on affected devices to stop the automatic switch to the 2023 boot manager.
Note what the fix does not do: it does not migrate those machines to the 2023-signed boot chain. The certificate rollover still has to happen eventually, so devices held back by this fix are accumulating a deferred migration. Treat Event ID 1032 as a to-do list, not just a log entry.
Analysis
There are two lessons here worth more than the incident itself.
First, custom TPM validation profiles are a liability you have to actively manage. The affected configuration exists because, at some point, an administrator decided the default PCR binding was not strict enough and pinned a custom profile. That is a defensible hardening decision, but it creates a standing assumption that the boot chain will not change, and the vendor does not share that assumption. If you customize the platform validation profile, you own the testing burden for every update that touches boot files. If nobody on your team can explain why the custom profile is there, that is a strong signal it should go back to default.
Second, recovery key escrow is the control that decides whether this is an annoyance or an outage. Organizations that escrow BitLocker recovery keys to Active Directory or Entra ID and have a tested retrieval procedure experienced April as a nuisance. Organizations that did not had servers they could not boot and no way in. The time to verify escrow coverage is before the next boot-chain update, not during it. Run the report now: every BitLocker-protected device should have a current recovery key in escrow, and your helpdesk should know the retrieval procedure without looking it up.
For CISSP candidates, this story is a clean real-world bridge between domains. The TPM, PCR measurements, and Secure Boot certificate chain are Domain 3 security architecture material. The patch management discipline, staged deployment rings, and recovery key escrow procedures are Domain 7 security operations. The exam loves scenarios where a security control functions correctly and still causes an availability incident, and that is exactly what happened here: confidentiality protection worked as designed, and availability paid for it.
Takeaways
- Deploy KB5094125 (Windows Server 2025) or KB5093998 (Windows 11 23H2) to close out the issue, and watch for Event ID 1032 to see which devices were held back from the 2023-signed boot manager.
- Audit your fleet for the "Configure TPM platform validation profile for native UEFI firmware configurations" Group Policy. If the custom profile has no documented justification, revert to the default PCR7 binding.
- Verify BitLocker recovery key escrow coverage in Active Directory or Entra ID now, while nothing is on fire.
- Plan for the Secure Boot certificate rollover. Devices held back by this fix still need to move to the 2023-signed boot chain eventually.
- Stage boot-chain updates through a test ring that includes your hardened configurations, not just default builds. Three incidents in two years says this class of bug will recur.
