June 2026 Secure Boot Certificate Deadline: What Windows Admins Must Do Now to Avoid Boot Failures

Microsoft’s 2011 Secure Boot certificates expire in June 2026. If your organization hasn’t installed specific Windows updates that add the new certificates, Secure Boot‑enabled devices will fail to start—displaying a black screen, a boot loop, or a dreaded “Verification failed” error. This isn’t a distant concern; it affects millions of corporate PCs, servers, and embedded systems that still rely on the original Microsoft Corporation UEFI CA 2011 trusted root.

IT teams have roughly one year to act. The fix is straightforward: deploy the cumulative updates that inject the Microsoft Corporation UEFI CA 2026 certificate into the UEFI firmware’s db variable. But straightforward doesn’t mean painless. Reboot cycles, firmware revision dependencies, and frozen legacy images all create roadblocks. This guide breaks down the deadline, the technical risk, the exact update paths, and the rollout strategies that will keep your fleet bootable on June 8, 2026.

What’s expiring and why it matters

Secure Boot relies on a chain of trust anchored by certificates stored in the UEFI firmware. When the PC powers on, the firmware checks the signature of each boot component against a list of allowed certificates (the db) and a forbidden list (the dbx). The 2011 Microsoft Corporation UEFI CA certificate has been the primary trust anchor for Windows boot loaders, Option ROMs, and UEFI drivers for over a decade.

That certificate’s validity period ends on June 8, 2026. After that date, firmware will consider any component signed solely by the expiring CA as invalid—even if the component itself is legitimate. The result: Windows won’t load, and recovery environments may become inaccessible unless the firmware already trusts the replacement certificate.

“This is similar to what happened when the SHA‑1 deprecation forced firmware updates, but more binary,” said a senior engineer on WindowsForum. “Either the new cert is in the db or the box doesn’t boot. No intermediate states.”

The expiration doesn’t just affect full Windows OS boots. It also impacts WinPE, Windows Recovery Environment (WinRE), and even certain UEFI‑based firmware updates. Systems that perform a PXE boot from a Windows Deployment Services server signed with the old certificate will fail as well.

The fix: Windows updates that embed the new certificate

Microsoft began seeding the Microsoft Corporation UEFI CA 2026 certificate in early 2024 via cumulative updates for supported Windows versions. The updates don’t patch Windows itself; they signal the UEFI firmware to append the new certificate to the authorized signature database (db). The firmware must support the UEFI SetVariable() call with the appropriate capsule update mechanism. Nearly all devices manufactured after 2015 support this, but confirm with your OEM.

Specific update paths

• Windows 10 (22H2): KB5028400 or later monthly cumulative updates include the certificate payload. Microsoft originally released this servicing stack improvement for manual download; today any cumulative update dated April 2024 or later carries it.
• Windows 11 (21H2, 22H2, 23H2, 24H2): All cumulative updates since March 2024 include the certificate. The 2026‑04 monthly “B” release will be the final automatic injection for older LTSC editions.
• Windows Server 2022: The March 2024 update (KB5035857) and all subsequent cumulative updates inject the certificate. Server Core and Desktop Experience are both covered.
• Windows Server 2019 and 2016: Updates released in April 2024 (KB5036896 for 2019, KB5036899 for 2016) contain the certificate when installed onSecure Boot‑capable UEFI hardware.
• Windows 10 LTSC 2019 and earlier: These editions do not receive the certificate automatically. Administrators must manually apply a standalone servicing stack update or use the Microsoft Update Catalog to download and install the specific package.

Deployment mechanism details

The update works by writing two binaries to the EFI System Partition (ESP) during the update installation: bootmgfw.efi and a capsule file. On the next boot, the firmware’s capsule update process runs and installs the new certificate into the db. No user interaction is required beyond allowing the system to reboot completely. The process typically completes in under 60 seconds on modern hardware.

If the firmware update fails, Windows logs event ID 1795 in the System log with source “Microsoft-Windows-Kernel-Boot”. The update will retry on subsequent boots. You can also check whether the certificate is present by running Get-SecureBootUEFI in PowerShell and examining the db list.

What happens if you ignore the deadline

On a fully updated system, the firmware db contains both the 2011 CA and the 2026 CA. Boot components signed by either certificate will pass signature verification. After June 8, 2026, the 2011 CA is no longer valid. The firmware will not trust signatures made by a certificate whose validity window has ended, even if the certificate is still physically present in the db.

If the 2026 CA wasn’t added, the Windows Boot Manager (signed with a certificate chaining to the 2026 CA) will fail verification. The firmware will either:
- Show a blue “Verification failed: (0x1A) Security Violation” screen.
- Fall back to a boot loop that ends in automatic repair.
- On older firmware, silently drop to a UEFI shell or network boot attempt.

“We tested this by rolling a VM’s system clock forward on a clean install of Windows 11 without the update,” one WindowsForum member reported. “The VM booted to the recovery environment but refused to load Windows. Only disabling Secure Boot allowed a temporary boot.”

Disabling Secure Boot is a workaround, not a fix. It exposes the device to bootkits, weakens BitLocker protection (when TPM‑bound, BitLocker will still seal keys, but the pre‑boot environment is no longer integrity‑checked), and creates a false sense of security. In regulated industries, disabling Secure Boot may violate compliance requirements.

Additional risks beyond the boot loader

Windows Recovery Environment (WinRE)

The WinRE image that ships inside the recovery partition is a slimmed‑down Windows PE image. If the PC was deployed with an older WinRE that hasn’t been regenerated after the certificate update, WinRE itself may not boot. That breaks Reset this PC, System Restore, and the ability to access advanced recovery tools. Microsoft’s January 2024 guidance recommends running reagentc /enable after the update to rebuild WinRE.

BitLocker scenarios

BitLocker can be configured with pre‑boot authentication or just TPM‑only validation. When Secure Boot is on, BitLocker is more resilient against offline attacks. If you temporarily disable Secure Boot to bypass the certificate issue, BitLocker will typically enter recovery mode on the next boot—presenting the 48‑digit recovery key. In large fleets, manually entering recovery keys for hundreds of devices is a helpdesk nightmare. Pre‑emptive updating avoids this entirely.

Virtual machines and cloud instances

Hyper‑V Generation 2 VMs and Azure Confidential VMs rely on the host’s virtual firmware, which in turn uses certificates matched to the guest OS. If the guest OS is updated but the host doesn’t expose a virtual firmware that trusts the new certificate, the VM may fail to start after the deadline. Ensure your Hyper‑V host and Azure Stack HCI clusters receive the necessary host updates.

IT rollout strategy: a phased approach

Discovery

First, inventory which machines have the certificate. Use a script that queries the UEFI db variable:

$db = Get-SecureBootUEFI -Variable db
$cert2026 = $db | Where-Object {$_.Subject -like "*Microsoft Corporation UEFI CA 2026*"}

Machines missing the certificate need the update. Integrate this check into your SCCM or Intune compliance baseline.

Pilot ring

Deploy the update to a subset of devices representing your hardware diversity—different OEMs, models, firmware revisions. Monitor for boot failures and capture logs. Some Dell, HP, and Lenovo models released before 2018 may have capsule update issues. Test with firmware revisions older than the date when the OEM enabled the SetVariable() capsule.

Broad deployment

Use your regular patch management tool. The certificates are carried by standard cumulative updates, so if you’re current, you’re protected. For LTSC and Server Core installations that intentionally lag, treat the certificate update as a critical out‑of‑band update and deploy the specific KB immediately.

Validation

After deployment, verify at scale. A simple WMI query can check if the update is installed:

wmic qfe list brief | findstr "KB5028400"

But that only confirms the Windows package, not whether the firmware actually accepted the certificate. A boot‑time log or the PowerShell check above provides firmware‑level confirmation.

Dealing with failures

When the certificate injection fails, common causes include:
- Full EFI system partition (less than 5% free space). Clean up abandoned boot entries and language packs.
- BIOS-locked firmware update capability. Some corporate laptops prevent capsule updates when configured for “Managed UFEI”. A temporary BIOS password change may be needed.
- Third‑party full‑disk encryption that intercepts EFI writes. Suspend encryption for one boot cycle or use a pre‑boot authentication bypass.

Keep a stash of recovery USB drives containing a bootable Windows PE image signed with the new certificate. You’ll need these to recover machines that accidentally miss the deadline.

Timeline and key dates

Microsoft has not announced any extension. Treat this as a hard deadline.

The quiet rollout: why many admins missed the news

The certificate injection was buried in monthly cumulative updates without a prominent enablement package. Microsoft described it in KB articles KB5028400 and KB5036210, but the rollout wasn’t as widely communicated as the Spectre/Meltdown mitigations. Consequently, some organizations that test only feature updates skipped the servicing stack changes.

“Our change control board barely discussed it because it was marked ‘security update’ and we assumed it was just another patch,” wrote an IT manager on WindowsForum. “We didn’t realize it was a prerequisite for future boot integrity until we saw the expiration date.”

To prevent this, Microsoft added detection logic to Windows Update for Business reports and Endpoint Analytics in Intune, flagging devices that require the certificate. If you use those tools, review the “Secure Boot certificate” report now.

What about Windows 10 end of support?

Windows 10 22H2 exits support on October 14, 2025—about eight months before the certificate expires. Machines still running Windows 10 after that date won’t receive any further updates, including future certificate lifecycle management. If you plan to keep Windows 10 devices in service past October 2025, you must manually install the certificate‑containing update before end of support. Alternatively, migrate to Windows 11 or switch to Windows 10 LTSC (which receives updates through 2027).

Embedded and industrial systems

Medical devices, kiosks, and factory-floor machines often run Windows 10 IoT Enterprise or even Windows Embedded. These systems may have custom UEFI firmware that doesn’t support capsule updates. Engage your OEM early. Some will provide a firmware update tool that directly programs the certificate into the SPI flash. Others may require a physical reflash.

The bottom line

The June 2026 Secure Boot certificate expiration is not a theoretical risk. It will cause immediate, hard‑to‑recover boot failures on any device that hasn’t received the replacement certificate. The fix is available now and is bandwidth‑friendly, but it requires planning and validation. Start your inventory this quarter. By Q4 2025, every Secure Boot‑enabled PC in your environment should have the 2026 CA in its db. When the calendar flips to June 2026, you’ll be watching others scramble—not joining them.