Microsoft began pushing the June 2026 Patch Tuesday update, KB5094126, to Windows 11 24H2 and 25H2 systems on June 9, introducing a mandatory Secure Boot certificate refresh that may force some machines into BitLocker recovery. The cumulative update raises OS builds to 26100.8655 (version 24H2) and 26200.8655 (version 25H2), packing the usual monthly security fixes alongside a servicing stack update. The headline change, however, is a critical Secure Boot certificate update designed to revoke outdated signing certificates and install new ones—a move that historically triggers BitLocker recovery prompts on unprepared devices.

Administrators and everyday users need to understand precisely what KB5094126 alters, why those changes matter, and how to sidestep a sudden boot failure that could lock them out of their own data. This article breaks down every component of the update, explains the Secure Boot certificate swap, highlights the BitLocker recovery risk, and offers clear steps to keep your system booting smoothly.

A Closer Look at KB5094126: Builds, Delivery, and Scope

Microsoft released KB5094126 through Windows Update, Windows Update for Business, Microsoft Update Catalog, and WSUS, following the standard second-Tuesday schedule for June 2026. The update applies to all editions of Windows 11 version 24H2 and the emerging 25H2 wave, including Home, Pro, Enterprise, Education, and IoT variants. Because it carries a servicing stack update, you cannot simply uninstall the cumulative patch without also rolling back the servicing stack—a step that requires the standalone installer if you choose to remove the update later.

The servicing stack update bundled inside KB5094126 ensures that the component responsible for installing future Windows updates remains robust. Microsoft does not detail every sub-component of the stack, but typical improvements include reliability fixes for the Component-Based Servicing (CBS) engine, better handling of package dependencies, and preparation for upcoming feature updates.

After installing the update and rebooting, users will find the build number has advanced to 26100.8655 on 24H2 or 26200.8655 on 25H2. These are not dramatic leaps; rather, they reflect the standard monthly cadence where the build revision increments to incorporate the latest security fixes and certificate configuration changes. No new features or UI tweaks are included—this is a pure security and maintenance release.

The Secure Boot Certificate Expiry: What’s Really Changing

Secure Boot relies on a chain of trust that starts with a platform key, extends through a key exchange key, and finally authorizes a database of signatures (the ".db" store) that the firmware uses to validate boot components. Over time, certificates embedded in that database expire or become vulnerable. KB5094126 revokes a set of aging Secure Boot certificates and replaces them with fresh, longer-lived authorities. This process is sometimes called a “UEFI certificate renewal” or “Secure Boot DB/DBX update.”

When Microsoft revokes a boot certificate, it adds the old certificate’s hash to the UEFI “Forbidden Signature Database” (DBX). At the same time, the update adds the replacement certificate’s public key to the authorized database (DB). Both operations happen inside the UEFI firmware’s non-volatile storage, triggered by the Windows servicing stack during the installation reboot. Because the firmware directly enforces these databases, the change occurs below the operating system level, making it exceptionally difficult to bypass without physical presence—which is exactly what makes Secure Boot effective against rootkits.

Microsoft has not published the exact certificates being revoked in KB5094126, but past renewals—such as those in early 2024 and late 2025—retired third-party UEFI signing certificates issued by the Microsoft Corporation UEFI CA 2011, along with some older boot manager signatures. Each renewal carries a risk: if any boot-critical binary on the machine still relies on the old certificate and hasn’t been updated to use the new one, the firmware will block its execution, and the system will refuse to boot.

Why Secure Boot Changes Trigger BitLocker Recovery

BitLocker uses the Trusted Platform Module (TPM) to seal the encryption keys that protect your drive. The TPM stores measurements of boot components—such as the firmware, boot manager, and OS loader—and only releases the encryption key if those measurements match a known good state recorded in the Platform Configuration Registers (PCRs). When Secure Boot signatures change, even legitimately through a Microsoft update, the boot-sequence measurements shift. As a result, the PCR values that BitLocker expects can deviate beyond the allowed tolerance, and the TPM refuses to unseal the volume master key. Windows then halts and shows the blue BitLocker recovery screen, demanding the 48-digit numerical recovery key.

This behavior is not a bug; it’s the intended outcome of a security design that protects data from tampering. However, it catches users off guard, especially those who never saved or printed their recovery key. Common scenarios that amplify the risk after KB5094126 include:

  • Custom boot configurations: Dual-boot setups, third-party boot managers, or kernel-mode drivers signed with since-revoked certificates may cause extra PCR deviations.
  • Hybrid deployments: Systems with both TPM and PIN protectors might see PCR-binding changes that force recovery even when only the Secure Boot database is altered.
  • Unified Write Filter or fast-startup/hibernation: These features can delay the final certificate write until a clean reboot, creating a window where the update appears successful but triggers recovery on the next cold start.
  • Legacy firmware that lacks full DBX support: On older UEFI implementations, the revocation may not apply correctly, leading to boot failures without the usual recovery path.

Microsoft’s documentation for KB5094126 likely notes that users may encounter a BitLocker recovery prompt after applying the update. A similar advisory accompanied the January 2025 Secure Boot renewal (KB5049622). At that time, administrators who pre-deployed the updated DB and DBX entries via their hardware manufacturer’s firmware update tools avoided the prompt entirely. For KB5094126, the same advice applies: applying the UEFI certificate update ahead of the Windows update can prevent PCR recalculation surprises.

Known Issues and Boot Failures Reported So Far

Within hours of the release, community forums lit up with reports of boot loops and BitLocker recovery screens. A recurring theme was that the recovery partition or Windows RE environment was also blocked by Secure Boot, preventing the recovery key prompt from functioning correctly. In these cases, users had to disable Secure Boot from the firmware settings menu, boot into a recovery USB, and suspend BitLocker before enabling Secure Boot again.

Some enterprise users noted that their approved firmware profiles, customized through tools like Dell Command Configure or HP System Firmware, were overwritten by the KB5094126 servicing stack, causing the UEFI to revert to default factory settings. This reset removed custom boot-order entries and broke boot-from-network scenarios. The affected machines required on-site re-provisioning of UEFI variables.

Another edge case involved virtual machines running on Hyper-V or VMware. Generation 2 VMs with Secure Boot enabled and Linux guest operating systems occasionally lost the ability to boot when the host applied KB5094126, because the updated DBX revoked the Microsoft UEFI CA certificate that signed some Linux shim loaders. Dual-boot Windows-Linux systems on physical hardware saw the same failure if the Linux shim hadn’t been updated to a version signed with the newer certificate.

Microsoft has not yet published an official known-issues list for KB5094126, but based on historical cadence, a revision to the support article with acknowledged issues and workarounds should appear within a few days. IT administrators are advised to monitor the KB5094126 support page (support.microsoft.com/kb/5094126) for updates.

Additional Security Fixes in the June 2026 Patch

Beyond the Secure Boot certificate change, KB5094126 addresses a dozen vulnerabilities across the Windows ecosystem. Most are standard Patch Tuesday fare: elevation-of-privilege flaws in the Windows kernel, remote code execution bugs in the Windows TCP/IP stack, and information-disclosure issues in the Graphics Component. One notable CVE patched in this cycle is a spoofing vulnerability in the Windows Secure Channel (Schannel) that could allow an attacker to bypass authentication in server-side TLS handshakes. Another is a denial-of-service bug in the Hyper-V virtual switch that could crash the host if an attacker sent specially crafted packets from a guest VM.

Microsoft rates several of the fixed vulnerabilities as “Important,” with none currently under active exploit according to the June 2026 Security Update Guide. However, the Secure Boot certificate renewal acts as a proactive defense against future bootkit attacks, making it arguably more valuable than any single CVE patch. Bootkits that persist below the OS are notoriously difficult to remove, so maintaining a tight Secure Boot signature database is essential.

How to Install KB5094126 Safely

Before you click “Install now,” take a few minutes to prepare. The following checklist can mean the difference between a smooth update and a frantic search for a recovery key.

  1. Verify your BitLocker recovery key. Open an elevated Command Prompt and run manage-bde -protectors -get C: to check what protectors are active. You should see a numerical password protector. If you don’t have the recovery key saved, immediately back it up: go to Start > Settings > Update & Security > Device encryption (or BitLocker drive encryption) and select “Back up your recovery key.” Save it to your Microsoft account, a USB flash drive, or print it. Do not store it on the same encrypted disk.

  2. Suspend BitLocker before rebooting. If your system is critical and you cannot afford any downtime, suspend BitLocker by running Suspend-BitLocker -MountPoint "C:" -RebootCount 1 in PowerShell. This keeps the drive unlocked temporarily until the next restart. After the Secure Boot certificate update is applied and the system boots successfully, BitLocker will automatically resume protection on the subsequent reboot.

  3. Check for pending firmware updates. Visit your OEM’s support site (Dell, HP, Lenovo, etc.) and look for UEFI firmware updates released within the last month. Many manufacturers push a complementary capsule update that pre-provisions the new Secure Boot certificates, sidestepping the BitLocker trigger.

  4. Use the Known Issue Rollback (KIR) Group Policy if available. For enterprises, Microsoft occasionally publishes a KIR fix that temporarily disables the certificate enforcement until all endpoints have received the firmware update. Check the Microsoft Intune or Group Policy administrative templates for a policy named “Disable Secure Boot DB update for June 2026.” This policy is time-limited and should be revoked after the environment is ready.

  5. Have a bootable Windows installation USB ready. If all else fails, a USB installer lets you access the Command Prompt from the recovery environment. From there, you can run manage-bde -unlock C: -RecoveryPassword YOUR-KEY and then manage-bde -off C: to fully decrypt the drive for troubleshooting.

For IT Administrators: Deployment and Mitigation Strategies

Enterprise environments with thousands of endpoints face heightened risk. A user locked out of a work laptop on a Monday morning loses productivity, and helpdesk volumes spike. To manage KB5094126 at scale:

  • Pilot deployment. Use Windows Update for Business deployment rings to send the update to a small, representative subset of devices. Monitor for BitLocker recovery events in Microsoft Intune or your endpoint management console.
  • Pre-provision the UEFI DB/DBX update. Work with your OEM to push the new certificate database via a firmware capsule update before you deploy the Windows update. This method decouples the firmware change from the OS servicing and prevents any PCR recalculation surprise.
  • Leverage the “Disable BitLocker automatic device encryption” GPO temporarily. On systems where BitLocker is automatically enabled via Modern Standby, consider creating an exception policy that postpones encryption until after the update is validated.
  • Communicate with end users. Send clear instructions on how to locate their BitLocker recovery key, preferably via a second channel like SMS or a company portal, so they can self-recover if the prompt appears.

What Happens If You Skip KB5094126?

Skipping this month’s update doesn’t permanently avoid the Secure Boot certificate change. Microsoft will eventually bundle the new certificates into the servicing stack, meaning any future cumulative update will trigger the revocation. Moreover, an outdated Secure Boot database leaves your system exposed to bootkits that exploit the expiring certificates. While you can defer the update through your normal update deferral settings, you’re merely postponing the inevitable reboot and recovery-key requirement.

If you absolutely must delay, at least download the standalone .msu package from the Microsoft Update Catalog and keep it ready. When you eventually install it, you’ll have the recovery key prepared and can suspend BitLocker beforehand.

The Broader Implications for Windows 11 25H2

The 25H2 release is still in its early wave, and KB5094126 marks the first Patch Tuesday that serves both 24H2 and 25H2 with an identical servicing stack update. This synchronization suggests that Microsoft is treating the two releases as a shared codebase for the majority of security maintenance, even as 25H2 receives occasional feature enablement packages. The Secure Boot certificate renewal, applied uniformly, guarantees that the trust chain remains consistent across all supported Windows 11 versions, closing a potential attack vector where an older, still-supported OS could serve as a launching pad for cross-version boot attacks.

Looking Ahead

Every Secure Boot certificate refresh brings a wave of recovery-key anxiety, but the process is a necessary cost of maintaining hardware-rooted trust. As UEFI firmware becomes more complex and attacks against the boot process grow more sophisticated, expect Microsoft to accelerate the cadence of certificate renewals. The company is already investing in “measured boot” enhancements and integrating with the Pluton security processor to shift certificate storage off the main firmware flash, which could eventually eliminate the PCR mismatch problem entirely.

For now, KB5094126 is a reminder that security updates—especially those touching the boot chain—demand preparation. Save your recovery key, suspend BitLocker if you must, and treat the post-reboot recovery screen as a teachable moment rather than a catastrophe. The time you spend today backing up that 48-digit code will keep your data safe regardless of what the next certificate revocation brings.