Expiring Microsoft Secure Boot Keys
Expiring Microsoft Secure Boot keys will not brick unmigrated systems on June 27, 2026. However, they will silently freeze DB/DBX updates and lock affected Windows and Linux fleets out of future boot‑level protections.
On June 27, 2026, the Microsoft Corporation KEK CA 2011 used to authorize DB/DBX updates via Windows Update reaches its end of validity, alongside the Microsoft UEFI CA 2011 used to sign third‑party bootloaders and shim.
In October 2026, Microsoft Windows Production PCA 2011, which signs Windows Boot Manager and pre‑OS components, also expires, completing the transition to the 2023 certificate family.
Secure Boot itself does not enforce certificate expiry at boot time, so devices continue to start with the already‑enrolled 2011 CAs even after they expire.
The operational impact is that devices left on 2011 keys can no longer accept new Secure Boot certificate updates or DBX revocations pushed through Windows Update, freezing their trust and revocation state at the moment the KEK path breaks.
Three 2011 certificates drive this transition, each with a distinct role and a 2023 replacement.
CertificateUEFI storeExpiryFunction2023 successorMicrosoft Corporation KEK CA 2011KEKJune 2026Authorizes all DB/DBX updates from Windows UpdateMicrosoft Corporation KEK CA 2023Microsoft Corporation UEFI CA 2011DBJune 2026Signs Linux shim and third‑party option ROMsMicrosoft UEFI CA 2023 / Option ROM CA 2023Microsoft Windows Production PCA 2011DBOctober 2026Signs Windows Boot Manager and Windows pre‑OS componentsWindows UEFI CA 2023
None of these certificates is the Platform Key; OEMs like Dell, HP, Lenovo, and Supermicro retain ownership of the PK at the top of the Secure Boot chain.
The expiry therefore does not destroy the chain of trust, but it does destroy the ability to update that chain via Microsoft’s servicing channel once the 2011 KEK can no longer authorize new DB/DBX payloads.
An important architectural change is that the old monolithic Microsoft UEFI CA 2011 is split in 2023 into separate CAs for OS bootloaders and hardware option ROMs.
This separation lets enterprises trust Linux shim while excluding unneeded third‑party option ROM CAs in hardened environments, a level of granularity that was impossible with the single 2011 CA.
Expiring Microsoft Secure Boot Keys
According to Eclypsium, Microsoft notes that essentially every Windows device shipped since Secure Boot’s introduction relies on these 2011 certificates, including Windows 10, Windows 11, and Windows Server releases, with newer Copilot+ PCs shipping directly with the 2023 chain.
Red Hat guidance emphasizes that systems with the 2011 UEFI CA already enrolled will keep booting after June 27, 2026, but they will be unable to consume new Secure Boot protections once the older certs expire.
Linux distributions that use shim depend on the Microsoft UEFI CA 2011 signature, so they must publish shim builds re‑signed with the 2023 CA before administrators remove or revoke the old entries.
Virtualization stacks such as VMware ESXi,Hyper V and KVM/OVMF keep their own virtual UEFI stores; updating the host does not update Secure Boot state inside guest VMs, which must be migrated individually.
OEM coverage is uneven: some vendors, such as Dell on recent PowerEdge generations, have already shipped BIOS updates embedding the 2023 certificates, while older platforms remain end‑of‑service with no firmware fallback if certificate variables are wiped.
In such cases, a CMOS reset or board replacement that drops the device back to factory defaults can make it unbootable until SecureBootRecovery.efi is used to restore the new Windows UEFI CA 2023 and a BitLocker recovery key is supplied.
The 2026 deadline lands amid active research and real‑world exploitation of Secure Boot bypasses such as BootHole, BlackLotus, and vendor‑specific firmware issues, all of which ultimately depend on DBX revocations to close the loop.
Microsoft’s own documentation stresses that systems left on 2011 CAs will no longer receive updated revocation lists or boot‑manager mitigations, leaving them permanently exposed to future bootkit‑class vulnerabilities that rely on revoking signed‑but‑vulnerable components.
NSA’s December 2025 Secure Boot guidance similarly warns that TPM presence and BitLocker alone do not guarantee correct PK/KEK/DB/DBX configuration, and it urges operators to query UEFI variables directly and compare them against an expected baseline.
Detection of the expiring Microsoft Corporation UEFI CA 2011 certificate in the DB that also affects Linux systems using Secure Boot (Source : Eclypsium).
Numerous advisories around BlackLotus emphasize that patching the OS is not sufficient; administrators must also deploy DBX updates that add vulnerable boot managers to the revocation list, which is impossible once KEK‑mediated updates stop.
The net effect is that unmigrated devices become a permanent safe haven for bootkits: they will continue to trust all components that were valid before the KEK expired, but they will never learn to distrust anything discovered after that point.
Microsoft has published a Secure Boot certificate expiration playbook and an “act now” message for enterprise admins, including registry‑based opt‑in controls that allow Windows Update to deploy the 2023 chain and updated boot manager.
Guidance from Microsoft and ecosystem vendors is clear on one sequencing rule: apply OEM firmware updates that embed 2023 keys before relying on Windows Update alone, to avoid losing the new certificates on a later BIOS default reset.
Traditional vulnerability scanners and EDR agents generally do not enumerate UEFI variables, leaving most organizations blind to which devices still hold the 2011 KEK, which DBX sets are missing key revocations, and where OS‑reported Secure Boot state diverges from firmware reality.
Eclypsium’s platform is specifically positioned to close that visibility gap by continuously inventorying PK, KEK, DB, and DBX contents across physical and virtual assets, comparing DBX against the UEFI Forum’s published revocation list, and flagging systems that remain on the expiring 2011 CAs or have incomplete revocation coverage for threats like BootHole, BlackLotus, and Bombshell.
Armed with that visibility, enterprises can treat the 2026 certificate turnover as a controlled migration instead of a surprise outage, prioritizing high‑risk systems, validating SecureBootRecovery.efi workflows, and ensuring that DBX updates continue to flow to every device that depends on them.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.