Starting June 24, 2026, Microsoft's original Secure Boot certificates from 2011 will begin expiring, forcing a mandatory transition to the newer 2023 certificate chain for millions of Windows PCs, servers, virtual machines, and even Linux systems that rely on Microsoft-signed UEFI boot components. This long-planned rollover, first communicated by Microsoft in early 2023, is not a security flaw but a routine certificate lifecycle event—however, its scale and deep integration into the boot process mean unprepared systems could fail to start or silently lose Secure Boot protection.

Secure Boot is a UEFI firmware feature that checks the digital signature of every piece of boot software before execution, blocking unsigned or tampered code. Microsoft's role as a Certificate Authority (CA) means many devices ship with Microsoft's public keys preloaded, from the Key Exchange Key (KEK) level down to the authorized signature database (db). The original "Microsoft Corporation KEK CA 2011" and the "Microsoft Windows Production PCA 2011" certificates are set to expire in 2026, with the KEK expiring precisely on June 24, 2026. Without these certificates present and valid, UEFI firmware will refuse to load signed bootloaders, even legitimate ones like Windows Boot Manager or the Linux shim loader.

The 2011 roots: a decade and a half of boot security

When Secure Boot was rolled out with Windows 8 in 2012, Microsoft generated a set of certificate authority keys intended to last roughly 15 years. The KEK 2011 certificate, which signs the db and dbx (revocation list) updates, has a validity period ending in 2026. The production signing certificate used to sign Windows boot loaders and other first-party software also expires around the same time. These certificates were embedded into UEFI firmware by OEMs and are present in the NVRAM variables of every Secure Boot–enabled machine.

For years, this 2011 infrastructure worked seamlessly, signing not only Windows but also the third-party shim bootloader used by most Linux distributions for Secure Boot compatibility. As a result, a single root of trust—Microsoft's 2011 KEK—became a cornerstone of cross-platform boot security.

Enter the 2023 certificate chain

To avoid a Y2K-style crunch, Microsoft began the rollout of a new UEFI certificate authority in 2023. The new "Microsoft Corporation KEK CA 2023" and "Microsoft UEFI CA 2023" (sometimes referred to as the "Microsoft Windows UEFI Driver Publisher") were created with validity periods extending into the 2040s. The key difference: the 2023 chain uses SHA-256 signing exclusively, whereas the 2011 chain still supported SHA-1 in some contexts (though Microsoft deprecated SHA-1 signing for UEFI in 2020).

Microsoft started quietly distributing the new certificates through Windows Update in early 2023. Updates such as KB5025885 (for Windows 10 and 11) and later cumulative updates push the new KEK and db certificates into the system's UEFI firmware store, alongside the existing 2011 certificates. This gradual, side-by-side deployment ensures that when the 2011 certificates expire, the firmware already trusts the 2023 chain, and bootloaders signed with the new certificate can validate properly.

Who is affected—and what happens if you don't act?

Windows PCs and servers: If a machine is fully updated and the UEFI firmware accepts the new certificates, the transition is seamless. In fact, many users may already have the 2023 certificates installed and not realize it. However, systems that have been offline, that are in sealed-off environments (such as air-gapped industrial PCs), or that have custom UEFI settings disabling certificate updates may fail to boot after June 2026. The symptom: a non-existent bootable device error or Secure Boot violation message, because the firmware will refuse to load the 2011-signed Windows Boot Manager.

Virtual machines: Hypervisors that emulate UEFI—such as Hyper-V, VMware, and VirtualBox—maintain their own NVRAM stores. By default, many VMs created before 2023 include only the 2011 certificates. Administrators must manually inject the 2023 certificates or recreate the VMs with updated templates. Failure to do so means that when the 2011 certificates expire, VMs will fail to start or will have Secure Boot disabled, lowering the security posture.

Linux dual-boot and standalone systems: Most Linux distributions use the shim bootloader signed by Microsoft's 2011 certificate. Shim itself is then able to load a secondary bootloader (GRUB, systemd-boot) that may be signed by the distribution's own key. The expiration of the 2011 certificate means shim must be re-signed with the 2023 certificate. The shim project and major distributions have been preparing: shim 15.7 and later include the 2023 CA, and updated versions are being distributed through standard package updates. However, a Linux system that hasn't updated shim or that uses a custom, hand-signed shim will break. In dual-boot configurations, the Windows update that inserts the 2023 certificates typically updates the UEFI firmware variables, but if the Linux boot chain hasn't been updated, selecting Linux from the boot menu may result in a Secure Boot error.

Embedded and IoT devices: Any Windows-based kiosk, digital signage, or embedded system running Windows 10/11 and Secure Boot is equally at risk. These devices often run untouched for years and may miss certificate updates, leading to a sudden failure in 2026.

A phased expiration: not just one date

The June 2026 date marks the expiration of the KEK 2011 certificate. The Windows Production PCA 2011 expires later, on October 19, 2026. Other certificates in the chain have varying sunset dates stretching into 2028. This phased schedule means that even after June 2026, some signatures may still validate, but relying on that is risky. A uniform upgrade to the 2023 chain before mid-2026 is the only safe path.

How to check your system's readiness

Microsoft provides several administrative tools to inspect the Secure Boot certificate store. On Windows, PowerShell can enumerate the KEK and db certificates with a few commands. For instance, Get-SecureBootUEFI -Variable KEK returns the current KEK entries. If the output includes a certificate with Subject "CN=Microsoft Corporation KEK CA 2023" or similar, the system is prepared. Alternatively, the Microsoft system information tool (msinfo32) reports whether Secure Boot is on and can sometimes indicate certificate details.

For Linux, the mokutil --list-enrolled command shows all certificates enrolled in the MOK (Machine Owner Key) list and the platform keys. Look for the 2023 CA in the output. Additionally, the sbverify tool can be used to check the signature chain of a shim image.

For hypervisors, administrators should consult vendor documentation. VMware has published KB articles (e.g., KB90947) detailing how to import the 2023 certificates into existing VMs. In Hyper-V, the Set-VMFirmware cmdlet can manipulate the Secure Boot template.

What you must do now

For individual users: Ensure Windows Update is enabled and all recent cumulative updates are installed. There is no separate download required; the 2023 certificates are delivered as part of the monthly servicing stack. If you have customized the Secure Boot policy (e.g., to add your own KEK), you will need to manually import the 2023 certificate using tools like Set-SecureBootUEFI.

For IT administrators and enterprises: Audit your fleet. Use a configuration management tool to check for the presence of the 2023 certificates across all managed endpoints. For devices that are offline or air-gapped, download and manually deploy the appropriate update packages from the Microsoft Update Catalog. Pay special attention to any system that dual-boots with Linux, as those require coordination between Windows and Linux updates. Test the transition on a representative sample to ensure that all custom or line-of-business UEFI applications continue to boot.

For Linux users and distribution maintainers: Verify that the distribution's shim package includes the 2023 CA (any shim released after mid-2023 should). If running a custom kernel or bootloader signed by the user's own key, ensure that the key is enrolled in the MOK and that the shim chain can verify it using the new CA. Distributions like Ubuntu, Fedora, and openSUSE have already incorporated the updated shim, but manually installed systems may need a shim-install command or a full shim reinstallation.

For cloud and virtualized environments: Update your golden VM images and templates. In Azure, Microsoft has been updating the platform, but older custom images may need intervention. AWS's EC2, Google Cloud, and others all use UEFI for newer instance types; consult the provider's documentation for Secure Boot certificate management.

Historical context: not the first certificate change

This is not the first time Secure Boot certificates have been rotated, though it is the broadest. In 2015, Microsoft issued a revocation for a leaked bootloader signing certificate, requiring systems to update their dbx to block the compromised software. That event taught the industry that certificate management in UEFI is a delicate dance between security, compatibility, and user education. The current rollover is far smoother because it doesn't involve a revocation—only an addition of new trust anchors before the old ones lapse.

Potential pitfalls and edge cases

  • Self-built systems and custom UEFI firmware: Enthusiast motherboards often allow users to delete all factory keys and enroll their own. If a user has cleared the default keys but later reinstalled only the 2011 certificates, the 2023 chain will be missing. Re-enrolling the default keys from the motherboard's UEFI menu usually restores the full set, including the 2023 certificates, assuming the firmware is up to date.

  • Third-party UEFI drivers and Option ROMs: Some hardware, like discrete RAID controllers or network boot ROMs, ship with UEFI drivers signed by the 2011 CA. If the device vendor hasn't released an updated driver signed with the 2023 CA, the system may fail to initialize that hardware during boot. Contact the hardware vendor for a firmware update.

  • Legacy and unsupported operating systems: Windows 7 and Windows 8.1 do not receive the 2023 certificate updates. If you are still running these operating systems (both well past end of support) with Secure Boot enabled, you will need to either disable Secure Boot or manually import the certificates—an unsupported and complex procedure.

The bigger picture: moving to a more flexible trust model

The certificate rollover is part of a broader effort to reduce reliance on a single root of trust. The 2023 chain, coupled with initiatives like Linux's "SBAT" (Secure Boot Advanced Targeting) and the Machine Owner Key (MOK) concept, allows for more granular control. For example, a hypothetical future where Microsoft is no longer the default KEK on consumer devices is more feasible if ecosystems already handle certificate transitions smoothly.

Final checklist: six steps to June 2026 readiness

  1. Inventory: Identify every device that uses Secure Boot, from desktops to cloud instances.
  2. Update: Apply the latest Windows or Linux updates and firmware patches.
  3. Verify: Use the tools mentioned to confirm the 2023 certificates are enrolled.
  4. Test: In a non-production environment, simulate the 2026 state by manually deleting the 2011 certificates (and re-adding them later) to see if boot succeeds.
  5. Remediate: For any device that fails, manually inject the certificates or consult vendor guidance.
  6. Document: Record the process for compliance and future certificate rollovers.

Two years may seem like ample time, but certificate transitions have a habit of sneaking up on organizations that defer them. The 2026 Secure Boot deadline is not negotiable—it's baked into the cryptographic validity of the keys. Preparing now will avoid a world where your PC greets you with "Secure Boot Violation" instead of the login screen.