Microsoft's original Secure Boot certificates, the cryptographic keystones that validate the integrity of every Windows PC's boot sequence, start expiring in June 2026. If your system's firmware hasn't been updated with the new certificates, you could face a machine that refuses to start. The clock is ticking, and the fix isn't always automatic.

The Silent Guardian at Startup

Secure Boot, a UEFI firmware feature, blocks unauthorized code during boot. It compares digital signatures on bootloaders and drivers against a database of trusted certificate authorities (CAs) stored in the firmware. Since Windows 8, Microsoft has used its own CA certificates—issued in 2011—to sign the Windows Boot Manager and kernel-mode components. These certificates have a 15-year validity. That lifespan looked generous in 2011, but June 2026 is now 15 years later.

The expiration applies to two specific Microsoft Windows Production PCA certificates:
- Windows Production PCA 2011 (SHA-256, thumbprint starts with 5C 0B 2E)
- Windows UEFI CA 2011 (thumbprint 31 9A 1C)

Both were embedded into the UEFI Secure Boot DB by PC manufacturers. When they expire, the firmware will distrust any bootloader signed with them—including Windows Boot Manager—unless a replacement certificate exists in the DB. Without intervention, a PC that only trusts these expiring certs will trigger a Secure Boot violation and potentially enter BitLocker recovery.

The Clock Has Been Ticking Since 2021

Microsoft began addressing this in 2021. The company released a replacement certificate set—Windows UEFI CA 2023—and started pushing it via Windows Update to compatible systems. The update adds the new certificate to the Secure Boot DB and the UEFI forbidden signature database (DBX) to block revoked bootloaders. KB article details vary per Windows version, but the common mechanism is a firmware capsule update delivered through Windows Update.

However, not every system receives this update automatically. PCs must meet specific requirements:
- The UEFI firmware must support capsule updates.
- Secure Boot must be enabled.
- The motherboard manufacturer must allow Windows to modify the Secure Boot DB.
- Windows must be configured to receive firmware updates (typically enabled by default).

Systems that fail any of these conditions won't receive the new certificates. Instead, users must manually install a firmware update from the manufacturer's website—if one is even provided.

Who Is at Risk? Five Groups to Check Now

1. Custom-Built Desktops
DIY PCs often use motherboards where Secure Boot is disabled or set to "Other OS" mode. Even with Secure Boot on, many motherboard vendors are slow to push firmware updates that include new UEFI revocation lists. If you built your own PC before 2022, verify that your UEFI DB includes the 2023 certificates.

2. Linux Dual-Boot Systems
Distributions like Ubuntu and Fedora use the Microsoft-signed shim bootloader. Shim itself is signed with the 2011 certificates. Updated shim versions exist, but older installations may still rely on expired signatures. Additionally, the UEFI DBX update that Microsoft distributes sometimes blocks older, vulnerable bootloaders (like older GRUB versions), which can break existing Linux installations. Check your distribution's documentation for "Secure Boot DBX update" compatibility guides.

3. Legacy Windows Versions (including Windows 7 and 8)
Windows 7 and 8 are out of support, but millions of systems still run them. No firmware capsule updates are being delivered through Windows Update. Users must manually obtain a firmware update from the PC vendor—unlikely for systems this old. The realistic path: disable Secure Boot entirely or upgrade to a supported OS.

4. Enterprise Fleets with Locked Firmware
Many organizations manage firmware updates through proprietary tools and deliberately block automatic Windows firmware patches. Unless IT departments validate and deploy the 2023 certificates before June 2026, managed notebooks and desktops will fail en masse. Group Policy settings can disable Secure Boot temporarily, but that weakens the security posture and may violate compliance mandates.

5. Virtual Machines and Nested Virtualization
Hyper-V and VMware often emulate UEFI with Secure Boot using templates that may only contain the 2011 certificates. VM templates created before 2023 likely lack the new CA. Administrators must update virtual hardware versions and, in some cases, modify the VM's UEFI NVRAM to inject the 2023 certificate manually.

How to Check Your Secure Boot Certificate Store

Open an elevated PowerShell or Command Prompt and run:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) | Select-String "Windows UEFI CA 2023"

If you see output referencing the 2023 certificate, your DB has been updated. A simpler visual check is to look for the certificate's thumbprint in the UEFI firmware settings (under Secure Boot, often in Advanced -> Key Management). The new certificate thumbprint begins with 48 E8 8C 7B C4 9D.

Alternatively, use the Microsoft-provided Confirm-SecureBootUEFI cmdlet or the msinfo32 tool. In msinfo32, under System Summary, check the "Secure Boot State" and look for the "PCR7 Configuration" line; it should show "Bound" on fully patched systems. However, the most reliable method remains a UEFI factory reset or a firmware inspection through the motherboard's setup utility.

For enterprise administrators, Microsoft publishes an updated Authenticode Signature Verification tool and a standalone PowerShell script to audit the DB across fleets. Search for "Microsoft Security Advisory 4535680" to find the latest script and documentation.

Microsoft's Phased Rollover Strategy

Rather than waiting until June 2026, Microsoft has staged the certificate replacement in two phases:

  • Phase 1 (2021–2023): Introduction of the 2023 certificates via Windows Update. The new certificates are placed into the DB alongside the expiring 2011 certificates. This ensures any future Windows or third-party bootloader signed with the new CA can boot on updated systems. Windows 11, Windows 10 (21H2 and later), and Windows Server 2022 receive the update as a priority.

  • Phase 2 (starting mid-2024): Enforcement through DBX updates. Microsoft begins adding the 2011 certificates to the forbidden signature database on patched systems. This step actively blocks bootloaders signed solely with the expiring certs, effectively forcing all vendors to migrate to the 2023 signatures. The DBX update also blocks the infamous "BootHole" (GRUB2) vulnerabilities and other revoked bootloaders.

As of January 2025, Phase 2 is ongoing. Windows 10 22H2 and Windows 11 23H2/24H2 have received multiple DBX updates, the latest being delivered via cumulative updates KB5041585 (Windows 11) and KB5041580 (Windows 10). These updates do not change the Windows bootloader's signature (it will still be signed by the 2011 cert until closer to expiration), but they prepare the firmware to accept the 2023 CA and reject known-bad bootloaders.

What Happens If I Miss the Deadline?

After June 2026, a PC with only the 2011 certificates will fail to boot Windows. The UEFI firmware, checking the bootloader's certificate chain, sees that every certificate in the chain ultimately chains to an expired CA. It then treats the bootloader as untrusted and halts the boot process.

On BitLocker-protected drives, the system enters recovery mode and prompts for the recovery key. Even after entering the key, Windows may not load because the bootloader itself is distrusted. In the worst case, you'll need to disable Secure Boot (which may require a firmware password, and on some devices, is impossible without vendor-specific tools), boot into Windows, install the firmware update, and then re-enable Secure Boot.

For devices where Secure Boot cannot be disabled (some tablets and locked-down enterprise devices), the only fix is a firmware reflash via a USB recovery tool or a motherboard replacement. Yes, a certificate expiration can effectively brick a PC.

Action Plan for Different User Profiles

Home Users

  1. Enable automatic Windows Update and ensure firmware updates are allowed. Check Settings > Windows Update > Advanced options > Optional updates for any pending firmware updates.
  2. If using a custom-built PC, visit the motherboard manufacturer's support page and download the latest UEFI BIOS. Install it according to the manual.
  3. Run the verification command above to confirm the 2023 certificate is in the DB.
  4. Keep Secure Boot enabled and test after a BIOS update.

Linux Users

  1. Update to the latest shim and GRUB packages provided by your distribution.
  2. After updating, regenerate the GRUB configuration and ensure the new bootloader is registered in the UEFI boot manager.
  3. Check your distribution's forum for known issues with Microsoft's DBX updates; some distributions revert the DBX update to avoid breaking older installations.
  4. If dual-booting with Windows, always apply Windows' DBX updates first, then update the Linux bootloader, then rebuild the UEFI boot order.

IT Administrators

  1. Inventory all PCs and identify models, BIOS versions, and current Secure Boot DB contents. Use a script based on the PowerShell Get-SecureBootUEFI cmdlet.
  2. Test the DBX update on a representative sample of hardware, including any Linux or custom-OS devices.
  3. Deploy firmware updates via Windows Update for Business or by uploading BIOS capsules to your management platform (Intune, SCCM).
  4. Set a firm cutoff date no later than Q1 2026 to ensure all devices are patched. Flag any non-compliant devices and consider hardware refresh for those that cannot be updated.
  5. Document the recovery procedure for a potential rollback if the DBX update breaks a critical bootloader.

The Third-Party Fallout

Microsoft is not the only UEFI CA. The other primary CA is the "Microsoft Corporation UEFI CA 2011," used by third-party vendors to sign their bootloaders. This certificate expires at the same time and triggers the same trust chain expiration. If a vendor (like a hardware diagnostics tool or a specialized network card) only signs with that CA, its components will be distrusted.

Third-party UEFI applications that still use the 2011 certificate face a hard stop. ISVs must re-register their software with Microsoft's Dev Center and obtain new signatures from the 2023 CA. Without re-signed bootloaders, these tools will fail and may prevent the OS from loading if they are part of the boot sequence.

A Hard Lesson in Certificate Lifetimes

The 15-year horizon that seemed safe in 2011 has created a planning burden reminiscent of the Y2K challenge, albeit focused on a narrower slice of the ecosystem. Microsoft handled its own migration well, but the diversity of UEFI firmware implementations means the last mile depends on hardware vendors—some of whom no longer exist. The June 2026 deadline will test how well the industry has absorbed the lesson that critical root-of-trust certificates need seamless rollover mechanisms, not just long expiry periods.

Check your system now. If you wait until the week before expiration, the download servers may be swamped, and the recovery process will be far more painful than a five-minute firmware update today.

Additional Resources