Microsoft’s decade-old Secure Boot certificates will expire on June 24, 2026, and millions of Windows devices that remain unpatched could face boot failures or loss of critical security protections. The looming deadline affects Windows 10, Windows 11, Windows Server, and a wide range of managed enterprise systems that still trust the original UEFI signing keys issued in 2011. Without proactive updates, those machines will be unable to validate bootloaders and operating system components signed exclusively with the new replacement certificates, potentially rendering them unbootable.

The transition has been underway for years, but many IT administrators and individual users remain unaware of the implications. Microsoft began shipping updated certificates through Windows Update and firmware patches as early as 2023, but the sheer scale of the Windows ecosystem means a significant number of devices may miss the update window. This article explains the technical background, the exact impact on different Windows versions, step-by-step verification methods, and recommended actions to ensure your devices remain operational beyond the 2026 cutoff.

Understanding Secure Boot and the Role of UEFI Certificates

Secure Boot is a security standard enforced by the Unified Extensible Firmware Interface (UEFI) firmware. It ensures that only trusted software signed with valid cryptographic keys can execute during the boot process, protecting the system from rootkits, bootkits, and unauthorized operating systems. When a PC starts, the UEFI checks the signature of each boot component—such as the boot manager and the OS loader—against a set of certificates stored in a database. If the signatures are valid and the certificate chain is trusted, the boot process continues; otherwise, the system halts.

These trust anchors reside in several UEFI variables: the Platform Key (PK), the Key Exchange Key (KEK), the signature database (db), and the forbidden signatures database (dbx). The “Microsoft Corporation UEFI CA 2011” certificate, which is scheduled to expire on June 24, 2026, is one of the most critical elements in this chain. It has been present in the db of virtually every UEFI-based PC shipped with Windows 8, 8.1, 10, and many 11 systems. All Windows boot loaders and key drivers were signed directly or indirectly by this certificate.

In 2022, foreseeing the expiration, Microsoft created a replacement certificate authority, “Microsoft Windows UEFI CA 2023.” Throughout 2023 and 2024, the company began dual-signing boot components with both the old and new certificates and distributing the new CA to UEFI databases via updates. After June 2026, Microsoft will stop signing with the expiring CA, and devices that haven’t accepted the new certificate into their Secure Boot db will reject those components, potentially causing boot loops or outright failure to start.

Which Systems Are Actually at Risk?

The impact spans all currently supported Windows editions, but the risk varies based on how the device receives updates and whether its UEFI firmware has been refreshed by the manufacturer.

  • Windows 11: Most Windows 11 devices shipped after 2022 likely already have the new certificate in their UEFI db, but some early models and custom-built PCs may still rely solely on the 2011 CA. Microsoft’s KB5025885 (and related updates) add the certificate at the OS level, but for the change to survive an OS reinstall or disk wipe, a UEFI firmware update from the device OEM is required. Many manufacturers have yet to release such firmware updates for older Windows 11-capable machines.
  • Windows 10: All supported versions (21H2, 22H2) can receive the necessary OS-level update via Windows Update. However, the update is optional and must be manually installed on many systems unless configured for automatic update. PCs on Long-Term Servicing Channel (LTSC) editions will require separate servicing stack updates. Devices that are isolated from the internet, such as air-gapped systems in industrial environments, are particularly vulnerable.
  • Windows Server: Windows Server 2022, 2019, and even 2016 (in extended support) are affected. Server installations often have conservative update policies, which can delay the deployment of the certificate update. Furthermore, hypervisor and virtualized environments may need explicit configuration to pass the new certificate through to Secure Boot-enabled virtual machines.
  • Managed Enterprise Devices: Organizations using Windows Defender Application Control (WDAC) or custom Secure Boot policies must ensure that the new CA is explicitly added to their policies. Some third-party antivirus and disk encryption tools interact with the boot chain and may need compatibility updates from vendors.

Microsoft’s Phased Rollout and the Updates You Need

Microsoft adopted a phased approach to minimize disruption. The update mechanism differs slightly between Windows versions, but the core component is the same: a servicing update that adds the “Microsoft Windows UEFI CA 2023” to the system’s Secure Boot signature database.

The following table summarizes the primary updates:

Windows Version Update Identifier Notes
Windows 11, version 22H2 and later KB5025885 (or cumulative update) Included in monthly security updates from July 2023; manual verification possible via PowerShell
Windows 10, version 22H2 KB5025885 May require separate MSI package download for specific CPU architectures; not always offered automatically
Windows Server 2022 KB5025885 May require servicing stack update first
Windows Server 2019 KB5025885 (explicit download) Same as Windows 10 1809-based core; separate update for Server Core installations
Windows 11, version 21H2 (original) KB5012170 Also includes Secure Boot DBX update for revoked signatures
Windows 10, version 21H2 KB5012170 DBX update only; full CA addition through later cumulative

It is critical to understand that KB5025885 does not immediately enforce the new certificate as the sole trust anchor; it only adds it to the db alongside the 2011 CA. Microsoft will cease dual-signing after June 2026, making the new CA the only valid signer for future boot components. Devices that installed the update but subsequently had their UEFI variables cleared (e.g., due to a firmware reset or battery failure) may lose the new certificate unless the UEFI firmware itself incorporates it—hence the importance of OEM firmware updates.

How to Check Your Workstation or Server Right Now

You can verify whether the new 2023 certificate is already present in your system’s Secure Boot database using built-in tools. The inspection requires administrator privileges.

Using PowerShell

  1. Open PowerShell as Administrator.
  2. Run the following command:
    powershell Get-Partition | ? IsBoot | % { $_ | Get-Disk | Get-Firmware } | fl *
    This provides high-level firmware details but not certificate specifics. For certificate details, use:
    powershell certutil -store -v -silent SPC | Select-String “Microsoft Windows UEFI CA 2023”
    If output appears, the certificate is present.
  3. For a more precise check, list the secure boot certificates via:
    powershell [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -split “Microsoft Windows UEFI CA 2023”
    Again, any output confirms the certificate is enrolled.

Using System Information (msinfo32)

  1. Press Win+R, type msinfo32, and press Enter.
  2. In the System Information window, locate Secure Boot State. If it says “On,” Secure Boot is enabled.
  3. To see the certificates, expand ComponentsSecuritySecure Boot and look for entries containing “Microsoft Windows UEFI CA 2023.”

Validation at Scale for IT Administrators

Organizations can use Microsoft Endpoint Manager (Intune) or Group Policy to push a script that checks the Secure Boot db across all managed devices. A sample PowerShell script published in the Microsoft Security Baselines can be deployed to generate a compliance report.

If the new CA is missing, the update must be applied immediately. However, simply installing the update does not guarantee the certificate is written to the UEFI variable. In some cases, the update script requires a reboot and a specific set of conditions: Secure Boot must be enabled, and the system must not be in a “secure boot is off” state or have third-party certificates that conflict.

The Danger for Dual-Boot and Customized Setups

Dual-boot configurations, where Windows coexists with Linux or another OS, introduce additional complexity. The Linux bootloaders (typically shim and GRUB) must also be signed with a certificate trusted by the UEFI. If the 2011 CA is removed from the db after expiry, older shim versions signed only with that CA may break. Most major distributions have already updated their shims to include the new Microsoft CA, but older installations may fail to boot after the transition.

Custom PC builders and enthusiasts who assemble their own machines often purchase motherboards from vendors that may be slow to release UEFI firmware updates containing the 2023 CA. Without such a firmware update, the new certificate must be applied manually or via the Windows update mechanism, which persists only until the UEFI is reset. ASUS, Gigabyte, MSI, and ASRock have issued updates for current-generation boards, but older AM4 and LGA1200 platforms may remain unpatched.

OEM Responsibility and the Slow Pace of Firmware Updates

While Microsoft provides the OS-level certificate update, the permanent integration rests with motherboard manufacturers and OEMs. Some enterprise-class devices from Dell, HP, and Lenovo already include the new CA in firmware released through their respective update utilities. However, a spot check of consumer-grade laptops and desktops reveals a patchy landscape. Many models from 2019–2021 still show no firmware updates that add the 2023 certificate.

This gap is particularly concerning because a common troubleshooting technique—resetting the UEFI to default settings—clears the Secure Boot variables, potentially removing the OS-added certificate. If the firmware does not rebuild the db with the new CA after a reset, the device will fail to boot until the Windows update is reapplied, creating a chicken-and-egg scenario for recovery.

The UEFI Forum, which governs the standard, has warned about such pitfalls. In a 2023 whitepaper, members recommended that all system firmware issued after January 2024 should include the replacement certificate. Yet compliance is voluntary, and there is no mandatory certification check.

What Happens After June 24, 2026?

Microsoft’s plan is unambiguous: after the 2011 CA expires, it will be retired. That means:
- New Windows updates and boot components will be signed only with the 2023 CA.
- The old certificate will no longer be trusted for new signatures, but may remain in the db for backward verification of older components that do not require signing. In practice, however, the key Boot Manager (bootmgfw.efi) and OS loader (winload.efi) will be updated over time and eventually drop the 2011 signature.
- Systems that have not added the new CA will not trust these updated components, resulting in a “Boot Device Not Found,” “Inaccessible Boot Device,” or Secure Boot violation error.
- The Windows Recovery Environment (WinRE) will also be affected, potentially blocking offline repair attempts unless the recovery media has been refreshed to include the new certificate.

It’s not a hypothetical Y2K-style disaster, but it mirrors the 2020 transition when Microsoft revoked old UEFI signed bootloaders via the DBX update (KB4524244) and inadvertently caused boot failures on some HP devices. Back then, the revocation was postponed. This time, the expiration is date-coded in the certificate itself—it cannot be delayed.

Mitigation Steps for Individuals and Organizations

  1. Accept all pending Windows updates immediately. Go to Settings > Windows Update and install everything offered, especially any updates that mention “Secure Boot” or KB5025885. If it’s not offered, download it from the Microsoft Update Catalog and install manually.
  2. Check your OEM’s support site for a UEFI firmware update that mentions “UEFI CA 2023” or “Secure Boot certificate update.” Apply it even if your system currently boots fine. The firmware update ensures permanent trust.
  3. Enable Secure Boot if it is currently off. The update can only apply the certificate when Secure Boot is active. On some systems, you may need to switch from Legacy BIOS to UEFI mode first.
  4. Back up your BitLocker recovery key. Any major firmware change can trigger BitLocker recovery. Ensure the key is saved to your Microsoft account or a secure location.
  5. For enterprise admins: deploy the certificate update via WSUS or Configuration Manager. Use a phased rollout and monitor for boot failures. Update any custom Secure Boot policies and validate with third-party drivers (e.g., SentinelOne, CrowdStrike) that operate at the boot level.
  6. In virtual environments: update the UEFI firmware of the virtual machine if using Hyper-V Generation 2 VMs. VMware and VirtualBox also require host-level updates to expose the new certificate to guests.

The Long-Term Shift in UEFI Trust

Beyond the immediate expiration, this event signals a broader shift in UEFI security. Microsoft is moving toward more granular certificate control, such as the Secure Core PC initiative, which mandates specific firmware hardening. The 2023 CA is likely the first of many, establishing a cadence for regular certificate rollover—similar to the way SSL/TLS root certificates expire and are replaced.

Industry insiders expect that future Windows releases will tie Secure Boot trust even more tightly to hardware-backed attestation, making certificate management a routine part of device lifecycle management. For now, the clock is ticking. The 2026 deadline may seem distant, but given the fragmentation in firmware update delivery, the time to act is now.

Microsoft has published a comprehensive FAQ that addresses specific scenarios, such as devices with “Windows UEFI CA 2023” already present but missing in certain UEFI variables, and workarounds for systems where the update fails to apply. Consulting that documentation is strongly advised for anyone encountering errors during deployment.