Secure Boot certificates expire in 2026: what changes and how to check your PC

In short

Secure Boot is a firmware check that only lets signed boot software run. The Microsoft certificates it relies on, issued in 2011, expire on June 24 and June 27, 2026 (two of them) and October 19, 2026 (the Windows boot loader certificate). Your PC does not stop working: Microsoft says devices without the new 2023 certificates keep starting and installing normal Windows updates, but they stop receiving new boot-level protections. Most PCs are meant to get the new certificates automatically through Windows Update; you can check with one PowerShell command, and Linux dual-boot machines, virtual machines and old hardware need extra care.

Why this suddenly matters

Every time a PC starts, the firmware (UEFI) has to decide whether to trust the first program it loads. If Secure Boot is on, it trusts only programs signed by a key it holds. Those keys are certificates, and certificates expire. The ones Microsoft has used since 2011 are reaching their end dates in 2026, and replacing them is a coordinated change across Windows, PC makers' firmware, Linux distributions and virtual machine platforms. Microsoft says both the Secure Boot DB and the KEK need to be updated with the matching 2023 certificates. The topic already shows up in Microsoft's October 2026 preview update notes say the certificates used by most Windows devices began expiring in June 2026 and that updated certificates continue to roll out through Windows Update. (See our article on KB5127936.)

How Secure Boot decides what to trust

Microsoft's documentation describes a key hierarchy with four parts:

• PK (Platform Key): the root of trust at the top. Eclypsium notes that PC makers such as Lenovo, Dell, HP and Supermicro own it, not Microsoft.
• KEK (Key Exchange Key): certificates allowed to change the two lists below. Windows Update uses a KEK to push changes.
• DB (allowed signature database): the allow list of certificates and hashes of trusted boot software.
• DBX (disallowed signature database): the deny list of revoked boot components. When a boot-level vulnerability is found, the fix is often a new DBX entry.

Think of it as a chain of permission. The KEK decides who may edit the lists; the lists decide what boots. If the KEK certificate in the chain has expired, the machine can still boot what it already trusts, but it can no longer be updated with new trust decisions.

The four certificates and their dates

Microsoft's support page lists these expiring certificates and replacements:

• Microsoft Corporation KEK CA 2011 (stored in the KEK, signs updates to DB and DBX) expires June 24, 2026; replaced by Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 (stored in DB, signs third-party boot loaders and option ROMs) expires June 27, 2026; replaced by two certificates, Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023. The split lets a system trust option ROMs without trusting third-party boot loaders.
• Microsoft Windows Production PCA 2011 (stored in DB, signs the Windows boot loader) expires October 19, 2026; replaced by Windows UEFI CA 2023.

Sources differ in small ways: Eclypsium's table gives June 27 for the KEK certificate and only "October 2026" for the Production PCA, while Microsoft gives June 24 and October 19. We use Microsoft's dates. We also noticed one outlet writing that the 2011 certificates expire in June 2027; Microsoft's page, which we treat as authoritative, shows 2026.

What actually happens after expiry

The key sentence from Microsoft: devices "will continue to start and operate normally, and standard Windows updates will continue to install." What stops is new protection at the earliest stage of boot. Per Microsoft, a device without the 2023 certificates cannot receive updates to the Windows Boot Manager, Secure Boot databases and revocation lists, or mitigations for newly discovered boot-level vulnerabilities. Over time that weakens protection and may affect BitLocker hardening and third-party boot loaders.

Eclypsium explains why that matters with real incidents. BlackLotus (CVE-2023-24932) is a bootkit that needs DBX revocations to be blocked, and a device that cannot take new DBX entries cannot get future ones either. Eclypsium lists BootHole (CVE-2020-10713) and PKfail (CVE-2024-8105, leaked test Platform Keys across more than 813 device models) as other cases of boot-level trust failing. These are the reason Microsoft describes the loss as a gradual weakening and not a sudden failure.

How the new certificates arrive

According to Microsoft, most Windows devices should receive the updated certificates automatically, Microsoft manages the process for a significant portion of devices, and many PC makers provide firmware updates where needed. Organizations that manage their own updates get separate guidance, including registry, Group Policy, WinCS API and Intune methods. Eclypsium recommends applying the PC maker's firmware update before the Windows Update certificate change, so that a CMOS reset or BIOS default reset has somewhere safe to fall back to, and it describes an opt-in registry value, MicrosoftUpdateManagedOptIn set to 0x5944 under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot. We have not tested it, so treat it as the vendor's claim and check Microsoft's current guidance first.

Microsoft's October preview notes also say a limited number of devices may need one extra restart after a Secure Boot certificate update, as BleepingComputer reports.

How to check your own PC

1. Is Secure Boot on? Run msinfo32 and read "Secure Boot State," or run Confirm-SecureBootUEFI in an elevated PowerShell window. It returns True when Secure Boot is enabled. If it is off, expiry does not change how your PC checks boot software, though you are missing the protection.
2. Does the active database hold the 2023 certificate? Microsoft's guidance (KB5093574) describes Get-SecureBootUEFI -Name db -Decoded, which shows the database in readable form. Look for an entry whose subject is CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US. The -Decoded parameter was added in the April 14, 2026 cumulative updates, so older systems will not have it.
3. Fallback. Dell's article suggests matching the raw bytes: ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'). Dell also distinguishes the active database (what the machine boots from) from the default database (a backup copy).
4. Do not rely on "Secure Boot is on" alone. Eclypsium advises auditing at the UEFI variable level, since the operating system's summary says nothing about which certificates are present.

Special cases

• Linux and dual boot. Eclypsium says Secure Boot Linux distributions use a shim signed by the 2011 UEFI CA. If that certificate is removed without a shim signed against the 2023 CA, those systems stop booting. Check that your distribution has shipped a 2023-signed shim before any 2011 entry is removed. Dual-boot machines are updated through the Windows deployment, and PXE boot images must be re-signed.
• Virtual machines. Eclypsium notes that Hyper-V, ESXi, KVM/QEMU and Proxmox guests each have their own UEFI variable store, so each must be updated separately.
• BitLocker. A certificate-state change can prompt for the recovery key if BitLocker is sealed to PCR7, according to Eclypsium. Make sure you have the key before changing anything.
• Old hardware. Eclypsium says some enterprise servers will not get updates (it names Dell PowerEdge 12th and 13th generation), and that Windows devices shipped since 2012 are affected, with 2025 Copilot+ PCs the exception. Check with your hardware vendor.
• Air-gapped systems. Eclypsium points to Microsoft's offline tooling at aka.ms/GetSecureBoot.

Quick answers

Will my PC refuse to boot after the date? Microsoft says devices keep starting and operating normally and standard Windows updates still install.

What is lost? Updates to the Windows Boot Manager, Secure Boot databases and revocation lists, and mitigations for newly found boot-level vulnerabilities.

Do I need to do anything on a home PC? Microsoft says most devices will receive the new certificates automatically. Keep Windows Update on, install your PC maker's firmware updates, and run the check above once.

Does this affect Windows 10? We did not find a statement about Windows 10 in the sources we read, so we do not make a claim here. Check Microsoft's page for your Windows version.

Is Secure Boot the same as TPM or BitLocker? No. Secure Boot checks boot software signatures. BitLocker can be sealed to Secure Boot state (PCR7), which is why certificate changes can trigger recovery-key prompts in some setups, per Eclypsium.

Common mistakes

• Treating the date as a shutdown. Microsoft says nothing stops booting on that date.
• Updating Windows but not firmware on old machines, then finding no OEM firmware carries the new certificates.
• Resetting BIOS defaults after the update without reading the vendor note; Eclypsium warns that a CMOS clear or default reset can wipe certificate state.
• Assuming Windows Update will fix Linux. It will not replace your distribution's shim.

What to do this week

1. Run the two checks above on one test PC.
2. List machines that are old, dual-booting or virtualized.
3. Look up your PC maker's firmware page.
4. Back up BitLocker recovery keys before touching firmware.
5. If you manage a fleet, read Microsoft's organization guidance and pilot on representative hardware.

Sources

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates
• Microsoft Support: Using the -Decoded parameter in Get-SecureBootUEFI (KB5093574)
• Microsoft Support: KB5127936 release notes
• Eclypsium: Microsoft Secure Boot certificates expiring in 2026, enterprise impact
• Dell: How to check Secure Boot certificates
• BleepingComputer: Windows 11 KB5127936 update released