Microsoft's Secure Boot ecosystem faces a watershed moment in June 2026 when the original 2011 root certificates begin to expire, threatening the bootability of millions of Windows PCs that fall outside the reach of Extended Security Updates. Without intervention, systems running unsupported Windows 10 builds could encounter boot failures, error screens, or be locked out entirely as the UEFI firmware can no longer trust the digital signatures on critical boot components.

The Silent Guardian of PC Boot Integrity

Secure Boot has been a cornerstone of Windows security since the launch of Windows 8 in 2012. The technology ensures that when a PC turns on, only firmware and software that are cryptographically signed by trusted authorities are allowed to execute. This prevents rootkits, bootkits, and other low-level malware from hijacking the boot process before the operating system even loads. At the heart of this chain of trust lies a set of digital certificates burned into the UEFI firmware by the OEM, which ultimately validate Microsoft's own signing certificate—the KEK (Key Exchange Key)—and from there, the bootloader and OS components.

Those initial certificates, issued by Microsoft to OEMs starting in 2011, come with a finite lifespan. The critical Microsoft Corporation KEK CA certificate, used to sign the third-party UEFI certificates that authenticate Windows bootloaders, carries an expiration date of June 2026. When it lapses, any firmware that has not been updated to trust a newer certificate will reject boot files signed under the old chain, rendering the system unbootable.

The Ticking Clock: Certificate Expiration Mechanics

Certificate expiration in Secure Boot is not like a website SSL cert that gracefully degrades; it is a hard failure. UEFI firmware validates signatures using a strict set of databases: the Platform Key (PK), the Key Exchange Key (KEK), and the Allowed Signature Database (db). If the signing certificate of a boot loader is no longer valid because its issuer's KEK has expired, the firmware will refuse to execute that loader. For most Windows PCs, this means the familiar Windows Boot Manager (bootmgfw.efi) will fail validation, and the system will either hang, display a blue error screen, or enter a recovery loop.

Microsoft recognized this looming problem years ago and began laying the groundwork for a certificate rollover in 2022. The company started distributing updated UEFI revocation lists and new certificates through Windows Update, via monthly cumulative updates, to gradually prepare the ecosystem. The process hit a significant milestone in the April 2023 security update, followed by further deployments in October 2023, where a new Microsoft Corporation KEK CA certificate (valid through 2035) was pushed to the Secure Boot signature databases. These updates add the new certificate to the db and KEK, and also set a timed revocation to ignore the old certificate after the 2026 deadline.

The Rollout So Far: Phased Changes and KB Numbers

To date, Microsoft has issued multiple updates across supported Windows versions to accomplish this transition:

  • KB5012170 – initially released in August 2022, this update added the new DB and DBX (revocation list) entries for Secure Boot Forbidden Signature Database.
  • KB5025885 – an October 2023 update for Windows 10, 11, and Windows Server that further expanded the certificate deployment and set the revocation timing.
  • KB5031539 and subsequent monthly updates have continued to refine the boot manager and boot-stress components to ensure smooth handling of the transition.

The phased approach ensures that a majority of active, internet-connected devices will already have the new certificate in place long before the expiration. When June 2026 arrives, firmware that has been updated will seamlessly switch to validating boot components using the new 2035 certificate chain, effectively ignoring the expired one.

Windows 10 End of Support and the ESU Factor

Here is where the story gets complicated for Windows 10 users. Mainstream support for Windows 10 ended in October 2025, and even the last regular security updates stopped after that date. Microsoft introduced the Extended Security Updates (ESU) program for organizations and later for consumers to purchase an additional three years of critical patches—but only for the latest feature updates of Windows 10, versions 22H2 and 21H2. These ESU packages will include the necessary certificate updates to keep Secure Boot functional.

Devices that cannot or do not enroll in ESU—including any consumer PC running older builds like 1909, 2004, or even 21H2 after it exits ESU—will stop receiving updates entirely. If those systems have never installed the certificate rollover updates (KB5025885 and its predecessors), their firmware databases lack the new KEK CA certificate. Come June 2026, the boot manager, which is itself signed with a certificate chaining to the old expiring root, might be rejected. The crux of the problem is timing: the boot manager (bootmgfw.efi) on an unsupported system will still be the version signed with the old chain, and if the firmware revocation is set to block that chain after the expiration date, the system fails to boot.

Real-World Implications for Unsupported Systems

For the everyday user running Windows 10 Home or Pro without ESU, the first sign of trouble might occur after a routine restart following the June 2026 cutoff date. The PC could stall at the manufacturer logo screen, display an “Invalid signature detected. Check Secure Boot Policy” error, or boot into a Windows Recovery Environment loop from which there is no obvious escape. Attempts to repair using a Windows 10 installation media may not help if the media’s boot files are also signed with the old certificates.

Businesses that have not yet migrated to Windows 11 or enrolled in ESU face the risk of widespread PC downtime. Imaging and deployment scenarios become particularly thorny. A fresh installation of Windows 10 from an older recovery or installation USB created before the certificate updates will produce a non-bootable system because the boot media itself is signed with the old certs. IT departments must ensure that any deployment images are rebuilt using updated installation sources post-2023 to include the new certificates.

The only reliable recourse is to update the UEFI firmware’s Secure Boot databases before the expiration. This can be done by:

  • Applying the relevant Secure Boot DBX update (KB5012170 or newer) before Windows 10 reaches end-of-support.
  • Ensuring the October 2023 or later cumulative update is installed, which includes the new KEK CA.
  • For systems already past support, a one-time boot from a specially prepared Windows PE environment or Linux USB stick might allow manual injection of the new certificates using UEFI firmware management tools—but this is far from user-friendly.

Microsoft’s Guidance and the Path Forward

Microsoft’s official documentation, last updated in mid-2024, outlines three phases of the certificate rollover:
1. Phase 1 (Completed): Manufacturers integrate the new 2023 certificate into UEFI firmware for new devices shipped.
2. Phase 2 (2024–2025): Older devices receive the new certificate through Windows Update, and revocation of the 2011 certificate is set with a deferred effective date.
3. Phase 3 (Post-June 2026): Revocation takes effect; only the 2035 certificate is trusted for boot.

The company has stressed that users who keep their systems updated automatically through Windows Update need take no action. The challenge lies with offline, air-gapped, or unmanaged PCs that miss the update window. Microsoft’s Security Response Center (MSRC) has published a technical guide (ADV230001) detailing the database variable updates and the expected behavior. However, no amount of guidance can reach a machine that is not connected or whose user ignores update notifications.

The looming deadline has sparked discussions within enterprise IT forums. Many admins are proactively auditing their device fleet for the presence of the new KEK certificate by checking the UEFI variable dump. Tools like PowerShell’s Get-SecureBootUEFI or third-party utilities can enumerate the KEK and db contents to verify that the new certificate (with thumbprint 81b7... for the 2023 CA) is present. Devices found lacking are being prioritized for remediation.

The Role of Linux Dual-Boot and Third-Party Drivers

The certificate rollover does not only affect pure Windows systems. Many dual-boot configurations rely on the Microsoft-signed Shim bootloader to launch Linux distributions. Shim’s binary is signed with a certificate that ultimately chains to Microsoft’s KEK. As the old root expires, older Shim versions may also fail verification unless they are updated to one signed by the new CA. Linux distributions that update shim with a newer signing chain will continue to work; older ISOs or persistent installations could break. This adds another layer of complexity for users who keep an older Windows 10 partition alongside a Linux distribution that hasn’t been updated.

Similarly, third-party drivers or firmware option ROMs that are signed with certificates chaining to the 2011 KEK will become invalid. Hardware manufacturers like graphics card vendors and network adapter OEMs that load UEFI drivers during boot must ensure their signing chains point to the new root, or their devices may fail to initialize, leading to hardware seemingly disappearing after a firmware update.

The Windows 11 Perspective and Future Proofing

Windows 11 systems are inherently safer in this transition because they already require TPM 2.0 and Secure Boot, and Microsoft has baked the new certificate handling into their servicing stack from early builds. A fully patched Windows 11 22H2 or 23H2 installation will have the new certificates long before June 2026. The platform’s higher baseline ensures that any system natively running Windows 11 has likely received the rollover updates as part of normal cumulative updates. However, lingering Windows 10 to Windows 11 in-place upgrades that brick due to certificate issues are a corner case that support teams might encounter.

For new hardware, OEMs have been embedding both the 2011 and 2023 certificates in firmware since late 2021. After 2026, firmware shipping with only the 2023 certificate will become the norm, and booting older Windows 10 media on such hardware will be impossible without injecting the certificates post-installation—akin to the classic “slipstreaming” driver dramas of a decade ago.

What Users and IT Can Do Now

The message from Microsoft and security experts is consistent: do not wait until 2026 to check your device’s readiness. Immediate steps recommended are:
- For home users: Ensure Windows Update is enabled and all available updates—especially the monthly cumulative updates and the standalone KB5012170—are installed. If your PC is still on Windows 10 and you intend to keep using it beyond October 2025, purchase an ESU license before end-of-support to continue receiving security and certificate maintenance.
- For enterprises: Inventory all UEFI-enabled systems, use compliance scanning tools like Microsoft Intune or System Center Configuration Manager (now Microsoft Endpoint Manager) to check for the presence of the new KEK CA. Deploy the October 2023 cumulative update (or later) universally. For air-gapped systems, create an offline media pack containing the DBX update and the latest servicing stack.
- For dual-boot/enthusiasts: Update your Linux distribution’s shim bootloader to the latest version and verify it chains to the new Microsoft KEK. Keep recovery media up to date, and consider disabling Secure Boot temporarily if you need to rescue an unbootable system after the rollover—though this is not a secure long-term solution.

The Bigger Picture: Certificate Lifecycle Management

The Secure Boot certificate expiration is a reminder that software supply chain trust relies on finite cryptographic assets. Previous certificate expirations in other domains—like the Let’s Encrypt root expiry in 2021 or the Sectigo intermediate CA expirations—caused disruptions because many clients failed to update their trust stores. Microsoft’s staged rollout for Secure Boot is designed to avoid such chaos, but its success depends on end-user action.

Windows 10’s end-of-support timing exacerbates the challenge. Had Microsoft extended the free update period for Windows 11 to cover more hardware, the pool of vulnerable systems might be smaller. As it stands, millions of perfectly functional PCs cannot officially run Windows 11 due to TPM 2.0 and CPU requirements, leaving their Secure Boot trust in a precarious state. The ESU program provides a lifeline, but at a cost that many consumers will find prohibitive.

The certificate rollover also tests the durability of the UEFI Secure Boot standard itself. The Forum (UEFI Specifications body) had long anticipated certificate agility, but real-world implementation reveals friction. OEMs are tasked with updating firmware, but some older motherboards may never receive newer firmware builds that properly integrate the 2023 root. In such cases, the only fallback is to disable Secure Boot entirely, reducing security to pre-2012 levels.

Conclusion: A Hard Deadline with Real Consequences

June 2026 is not a Y2K-esque false alarm; it is a genuine hard deadline built into the cryptographic architecture of millions of PCs. Microsoft’s phased certificate rollover is both necessary and well-communicated, but the fragmentation of the Windows install base—especially the persistent Windows 10 holdouts—creates a scenario where many systems will stumble into this trap unawares. For users willing to invest in ESU or migrate to Windows 11, the path is clear and manageable. For everyone else, the countdown is on, and the cost of inaction could be a system that refuses to wake up one morning.