Why the Windows 11 Secure‑Boot Update Triggers a BitLocker Recovery Loop

Microsoft’s 2023 Secure‑Boot certificate (CA 2023) replaces the 2011 certificate that many PCs still use. When the update is applied, Windows attempts to write the new certificate into the UEFI firmware. On certain HP and Dell machines the firmware is either defective or too old to accept the new certificate, so the write fails.

This failure leaves the Secure‑Boot configuration inconsistent, which in turn triggers BitLocker to consider the boot environment altered and repeatedly request the recovery key. The symptoms include:

Booting directly into the BitLocker recovery screen.

Even after entering the correct key, the next reboot again asks for the key, creating a loop.

In some cases the system hangs at the HP logo.

Another root cause identified is insufficient space on the EFI System Partition (ESP). The KB5094126 update, which expands the rollout of the CA 2023 certificate, needs to write new Secure‑Boot components to the ESP. Many commercial PCs have ESPs of only 100 MiB, which cannot accommodate the additional files, leading to an incomplete update and the same BitLocker recovery behavior.

Microsoft’s mitigation is to block the certificate update for high‑risk devices and display a Windows Security Center warning: “Secure‑Boot has been blocked due to a known issue.” The ultimate fix requires OEMs to release BIOS/firmware updates that correctly support the new certificate and provide enough ESP space.

For users experiencing the issue, the recommended steps are:

Do not panic; the hardware is not broken.

Wait for the OEM (HP, Dell, Lenovo, ASUS, etc.) to publish a BIOS/firmware update that resolves the Secure‑Boot incompatibility.

Before applying any BIOS update, back up the BitLocker recovery key as emphasized by Microsoft.

Additional cases involve a blue‑screen error (0xc0430001) caused by an outdated boot.stl file left on the EFI partition after a Windows Boot Manager update. Replacing boot.stl with a matching version resolves that specific problem.

Overall, the incident demonstrates that OS‑level updates alone cannot fix firmware‑level defects; cooperation between Microsoft and OEMs is essential for a reliable Secure‑Boot ecosystem.