Windows 11 KB5083769 BitLocker recovery bug and install problems

The April 2026 cumulative update for Windows 11 25H2 and 24H2, shipped as KB5083769 (builds 26200.8246 and 26100.8246), introduced a known BitLocker recovery bug affecting a narrow set of managed devices. Microsoft added the known issue to the update's support page after release, and the same flaw is present in the Windows 11 23H2 update (KB5082052) and the equivalent Windows 10 and Windows Server patches.

Quick answer: After installing KB5083769, some devices prompt for a BitLocker recovery key on the first reboot. It only happens when BitLocker is on the OS drive, the TPM platform validation Group Policy includes PCR7, msinfo32 shows PCR7 Binding as "Not Possible," and the device is eligible to switch to the 2023-signed Windows Boot Manager. The key is only required once.

What KB5083769 is​

KB5083769 is the April 14, 2026, Patch Tuesday cumulative update for Windows 11 version 25H2 and 24H2. It pushes 25H2 systems to build 26200.8246 and 24H2 systems to 26100.8246, and it ships alongside servicing stack update KB5088467 (26100.8247). The package rolls up security fixes and the non-security improvements previewed in March.

Notable changes include a Secure Boot certificate status surface in the Windows Security app, improved SMB compression reliability over QUIC, stricter default prompts when opening .rdp files, and a fix for the March 2026 hotpatch bug that could break "Reset this PC."

---

The BitLocker recovery known issue​

The headline problem is a one-time BitLocker recovery prompt on the first restart after the update installs. It is tied to how the update handles the transition to the 2023-signed Windows Boot Manager when the device is sealed to PCR7. If the PCR7 binding cannot be used, but Group Policy still forces PCR7 into the TPM validation profile, the measurement changes, and BitLocker falls back to recovery.

Microsoft's guidance is clear that this only affects a limited set of systems, almost entirely in managed environments. The same fault path was confirmed in KB5082052 for Windows 11 23H2, KB5082200 for Windows 10, KB5082063 for Windows Server 2025, and KB5082142 for Windows Server 2022.

Conditions that trigger the prompt​

Condition	Required state
BitLocker	Enabled on the OS drive
Group Policy	"Configure TPM platform validation profile for native UEFI firmware configurations" is configured and includes PCR7 (or the equivalent registry value is set)
msinfo32.exe	Secure Boot State PCR7 Binding reports "Not Possible"
Secure Boot DB	Windows UEFI CA 2023 certificate is present, making the 2023-signed Boot Manager eligible as default
Boot Manager	Device is not already running the 2023-signed Windows Boot Manager

All five conditions must be true at the same time. If any one is false, the update will not trigger the recovery prompt for this reason. The key is only needed on the first reboot after the update; subsequent reboots will not show the screen again, provided the Group Policy configuration stays the same.

How to prepare before installing​

Enterprises should audit BitLocker policies for explicit PCR7 inclusion and check PCR7 binding status on target devices before deploying the update. The recommended fix is to remove the unrecommended policy, so BitLocker uses the Windows-selected default PCR profile.

Step 1: Open the Group Policy Editor with gpedit.msc or your Group Policy Management Console, and go to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.

Step 2: Set "Configure TPM platform validation profile for native UEFI firmware configurations" to Not Configured.

Step 3: Apply the change on affected devices by running gpupdate /force.

Step 4: Refresh the BitLocker bindings by suspending and resuming protection on the OS drive.

manage-bde -protectors -disable C:
manage-bde -protectors -enable C:

Refresh BitLocker bindings on C:

After those commands complete, BitLocker will re-seal against the default PCR profile chosen by Windows, and the update can be installed without triggering a recovery prompt.

For environments that cannot remove the PCR7 Group Policy before deployment, a Known Issue Rollback (KIR) is available. The KIR stops the automatic switch to the 2023 Boot Manager, so BitLocker does not see a measurement change. It must be deployed before the update reaches affected devices, and admins need to request it through Microsoft's Support for business.

If a device has already hit the recovery screen, entering the BitLocker recovery key once will complete the boot. After that reboot, the device will start normally as long as the Group Policy configuration is unchanged. Recovery keys backed up to Microsoft Entra ID, Active Directory, or a Microsoft account can be retrieved from account.microsoft.com/devices/recoverykey.

---

Installation failures and reboot loops​

Separate from the BitLocker issue, some users have reported trouble getting KB5083769 to finish installing. Error codes seen during failed attempts include 0x800f0991, 0x800f081f, 0x800736b3, 0x800719e4, 0x800f0823, and 0x80071a2d. In some cases, the update appears to install, reports success, then shows as missing after reboot, and installs correctly only on a second attempt.

There are also reports of Windows rebooting three or more times during the "Working on updates" stage before reaching the lock screen. This pattern does not match any confirmed Microsoft bug for consumer PCs and may be related to a .NET Framework update that shipped on the same day. A separate, unrelated known issue covers repeated reboots on Windows Server instances.

RMM dashboards have also shown false failures. NinjaOne in particular flagged the update as failed on machines where build 26100.8246 was actually present, which points to a detection sync lag rather than a real install failure. Verify the update state on the device itself with PowerShell before treating a dashboard status as accurate.

Get-HotFix -Id KB5083769
winver

If Get-HotFix returns the KB and winver shows build 26100.8246 or 26200.8246, the update is installed regardless of what a management console reports.

Removing the update​

Microsoft strongly advises against uninstalling security updates, since doing so re-exposes the device to the vulnerabilities the patch closed. If removal is still required, the LCU portion can be uninstalled with DISM, but the servicing stack update bundled with it cannot be removed.

DISM /online /get-packages
DISM /online /remove-package /PackageName:[LCU package name from the list above]

Remove the LCU while keeping the SSU

Running wusa.exe /uninstall against the combined package will not work because of the embedded SSU. A permanent fix for the BitLocker recovery trigger is planned for a future Windows update, and Microsoft has indicated a server-side mitigation is already rolling out to reduce how often the prompt appears during deployment.