Three certificates expire, two UEFI stores are affected, and one permanent gap opens if you miss the deadline. You can use Eclypsium’s solution to identify these gaps that will inevitably affect your Windows fleet. Expiring Keys and Immediate Impacts On June 27, 2026, the Microsoft Corporation KEK CA 2011 expires. This is not a normal certificate rotation as the key itself is expiring. Specifically, the KEK (Key Exchange Key) will reach expiration and is the credential that authorizes Windows Update to push new entries to your devices’ Secure Boot allow list (DB) and deny list (DBX). When that authorization pathway collapses, no new revocation can reach the device. For example, past revocations have added entries to the DBX for attacks such as BlackLotus and BootHole. Even with Secure Boot enabled, the system keeps booting, allowing attackers to deploy malicious software in the boot process. Devices that have not been migrated to the 2023 certificate family before the deadline retain whatever DB and DBX state they had at the moment the KEK expires, and they hold that state forever, or until an OEM firmware update embeds the new certificates. Every future bootkit campaign targeting a known-revoked component will succeed on those devices because their DBX is frozen. Microsoft is calling this transition an “act now” event. The fwupd project , NSA , Red Hat , Dell , and HP have all published guidance. The story you are not hearing enough is what this means operationally for the enterprises that have to actually execute it. What Is Actually Expiring There are actually three certificates expiring, two in June 2026 and one in October 2026, with three distinct functions: Certificate UEFI Store Expires What It Does 2023 Replacement Microsoft Corporation KEK CA 2011 KEK June 27, 2026 Authorizes every DB and DBX update Windows pushes via Windows Update Microsoft Corporation KEK CA 2023 Microsoft Corporation UEFI CA 2011 DB June 27, 2026 Signs Linux shim, third-party option ROMs, non-Windows bootloaders Split into Microsoft UEFI CA 2023 (OS bootloaders) and Microsoft Option ROM UEFI CA 2023 (hardware option ROMs) Microsoft Windows Production PCA 2011 DB October 2026 Signs the Windows Boot Manager ( bootmgfw.efi ) and every Windows pre-OS component Windows UEFI CA 2023 A point of confusion worth addressing up front: none of these are Platform Keys. The PK is the OEM-owned root of trust at the top of the Secure Boot hierarchy, and Microsoft does not control it on shipping hardware. Lenovo, Dell, HP, and Supermicro own their respective PKs. The 2026 expiration does not touch the PK. It also does not destroy the chain of trust. What it destroys is the ability to update the chain of trust through Windows Update. The architectural change worth calling out is the split of the old monolithic Microsoft UEFI CA 2011 into two distinct 2023 certificates. One signs OS bootloaders (Linux shim). The other signs are third-party option ROMs (PCIe cards, NICs, GPUs, RAID controllers). The split is a real security improvement, as environments that have no business trusting arbitrary hardware vendor option ROMs can now exclude the option ROM CA without breaking the Linux shim. That option did not exist with the monolithic 2011 cert. What This Means for Your Enterprise For most security and IT teams, the practical questions are not about UEFI cryptography. They are about scope, exposure, and what breaks. Every Windows device shipped since 2012 is affected. Windows 10 (from 1607), Windows 11, Windows Server 2012 through 2025, every LTSC release. If a system shipped with Windows or advertised Secure Boot compatibility, it has these certificates in its DB and KEK stores, and it needs to be migrated. The Copilot+ PCs released in 2025 are the exception: they shipped with the 2023 certificate family already provisioned. Your Linux systems are part of this, too. Every modern Linux distribution that supports Secure Boot relies on the shim bootloader, and shim is signed by Microsoft Corporation UEFI CA 2011 . When that cert is gone or revoked, the old shim stops verifying. Until the distribution publishes a shim re-signed against the 2023 CA, systems with only the 2023 DB entry and the 2011 entry removed will not boot. Red Hat has published RHEL-specific guidance. Debian, Ubuntu, Fedora, SUSE, and Arch are tracking the transition through their own release cycles. Your virtualization infrastructure is also affected. Hyper-V, VMware ESXi, KVM/QEMU with OVMF, and Proxmox all maintain their virtual UEFI firmware separately from the host. Secure Boot-enabled VMs carry their own DB, DBX, and KEK state in OVMF or EDK2-based virtual firmware. Updating the host does not update the guest. Each VM needs its own certificate transition. In air-gapped environments where Windows Update is unavailable, this process must be performed manually for each virtual machine. OEM coverage is uneven. For example, Dell PowerEdge 14th through 16th generation servers received the necessary BIOS updates by the end of 2025. Dell PowerEdge 12th- and 13th-generation systems will not receive them at all because they are end of service. Your asset inventory needs to identify those EOL platforms specifically, because they are the systems where Windows Update is the only delivery mechanism, with no firmware-level fallback if the certificate state is wiped. The recovery scenario is dangerous. If a system loses its certificate state (motherboard RMA, CMOS clear, or some BIOS updates that revert to defaults) and the OEM never shipped a firmware update that embeds the 2023 certificates, the system can become unbootable. Microsoft provides C:\Windows\Boot\EFI\SecureBootRecovery.efi as a recovery mechanism, but users must know it exists. BitLocker sealed to PCR7 will demand its recovery key in this scenario. Have you tested this on a representative device? Most organizations have not. Your existing tools cannot see this state. No conventional vulnerability scanner enumerates UEFI variable contents. No EDR product compares DBX entries against the UEFI Forum’s published revocation list . Most enterprises cannot answer the basic question: “Which devices in my fleet still have the 2011 KEK?” That visibility gap is the operational core of the problem, and it is what the NSA’s December 2025 UEFI Secure Boot guidance is trying to push enterprises to address. The Threat Landscape Below the OS The 2026 deadline arrives amid a measurable surge in research and exploitation of bootkits and firmware implants. The DBX exists specifically to revoke vulnerable boot components upon discovery. Recent vulnerabilities make the case for why DBX currency matters. CVE-2020-10713 (BootHole, CVSS 8.2) . A buffer overflow in GRUB2 was originally discovered and disclosed by Eclypsium researchers Mickey Shkatov and Jesse Michael. Because GRUB2 is signed by the Microsoft UEFI CA and verified via the DB, virtually every Linux distribution is affected, as is every Windows device that trusts third-party UEFI components. Remediation depends on adding vulnerable GRUB2 signatures to the DBX. Without a valid KEK, no future BootHole-class remediation can be applied. CVE-2023-24932 (BlackLotus, CVSS 6.7) . A Secure Boot bypass in Windows Boot Manager. The BlackLotus bootkit exploits this to replace the current boot manager with a signed-but-vulnerable older version, then loads unsigned kernel drivers, disables BitLocker and HVCI, and persists below the OS. Microsoft patched the underlying vulnerability in May 2023, but the patch alone is not enough. Administrators must manually trigger DBX revocations to blacklist the vulnerable boot managers. Devices with an expired KEK cannot accept future DBX additions, which means this vulnerability class is permanently exploitable on those systems. CVE-2024-8105 (PKfail, CVSS 8.2 High) . Discovered by Binarly. A supply chain failure in which hundreds of OEM devices shipped with AMI test Platform Keys explicitly marked “DO NOT TRUST” were left in production firmware and eventually leaked on GitHub. Over 813 device models across Dell, Acer, Gigabyte, Intel, Supermicro, Lenovo, HP, and others are affected. An attacker with the leaked PK can sign malicious firmware and walk the entire PK → KEK → DB chain. PKfail is a reminder that the operational management of Secure Boot trust anchors is as important as the cryptography. The same is true for the 2026 transition. Bombshell (Framework Secure Boot bypass) . In October 2025, Eclypsium researchers found that over 200,000 Framework laptops and desktops shipped with legitimately signed UEFI diagnostic shells containing a memory modify (mm) command. That command provides direct read and write access to system memory and can be used to overwrite the gSecurity2 UEFI variable (the pointer to the Security Architectural Protocol that performs LoadImage signature verification) with NULL. Secure Boot signature checks are silently disabled. Windows continues to report Secure Boot as enabled. Framework has issued firmware and DBX updates. Once again, the revocations are only useful on devices that can still accept DBX updates. The pattern is clear. The threats live below the OS, where EDR cannot see them, where reinstalling Windows does not remove them, and where the only meaningful remediation is a DBX update. Lose the ability to receive DBX updates, and you lose the only remediation path for an entire class of attacks. What Happens If You Miss the Deadline Contrary to early panic reporting, devices do not stop booting on June 27, 2026. The already-installed 2011 certificates remain present in the firmware. The Windows Boot Manager continues to validate. Linux shim continues to load. What you lose is everything forward of that moment: Secure Boot Updates cannot be installed. Windows Update that pushes a new trusted CA or revokes a compromised key would either be signed by a key after it has expired (and therefore should not be a valid signature) or be signed by the new CA that isn’t installed on the system (and therefore also invalid). CVE-2023-24932 remediation is permanently incomplete. BlackLotus-class boot managers are still trusted on devices that never received the DBX entry. Newer bootloaders are not trusted. Anything signed only against the new CA fails verification on devices that still have only the 2011 entries. BitLocker hardening and boot-level integrity workflows degrade when they depend on updated Secure Boot trust entries. Default-reset scenarios become high-risk. A motherboard swap, a CMOS clear, or certain BIOS updates can wipe the certificate state back to factory defaults. If the OEM never shipped a firmware update embedding the 2023 certificates, the device can become unbootable, requiring the SecureBootRecovery.efi process and a BitLocker recovery key. The compounding factor is that the threat landscape does not freeze. As new bootkit vulnerabilities are discovered after June 2026, devices that were not migrated will face increased exposure. That exposure is irreversible without an OEM firmware update or manual recovery. Remediation Paths The path forward depends on the environment. Microsoft has announced a phased rollout through cumulative Windows Update cycles, but most organizations need to do more than just wait. Consumer and Microsoft-managed devices For devices receiving Windows Update with diagnostic data enabled, no manual action is required. Microsoft is using telemetry to group systems by OEM and firmware profile and is deploying the new certificates in waves. Status is visible in Windows Security → Device Security → Secure Boot . Enterprise IT-managed devices (Intune, GPO, MECM) The opt-in registry key tells Windows Update to proceed with the certificate transition: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot Value: MicrosoftUpdateManagedOptIn Type: DWORD Data: 0x5944 This triggers the deployment of the Windows UEFI CA 2023-signed Boot Manager. Distribute via Group Policy (Computer Configuration → Administrative Templates → Windows Components → Secure Boot), Intune (Microsoft has published a dedicated Settings Catalog profile), or Microsoft Configuration Manager (formerly SCCM). Apply OEM firmware updates before applying Windows Update certificate changes. This is the single most important sequencing decision in the entire rollout. OEM BIOS updates embed the 2023 certificates in the firmware image itself. That gives you a durable recovery path if the certificate state is reset for any reason. If you only push the certificates through Windows Update without the OEM firmware update, a BIOS default reset wipes them. Dell PowerEdge 14th through 16th gen platforms have updates available. 12th and 13th-gen platforms will not. Identify EOL platforms specifically in your inventory. Air-gapped and offline systems Microsoft cannot reach these devices through Windows Update. Hyper-V and other virtualization environments must update their virtual UEFI variable stores independently from the host, using the SecureBootRecovery.efi mechanism or hypervisor-specific tooling. Microsoft has published offline deployment tooling at aka.ms/GetSecureBoot . For pure air-gapped environments, build a tested offline workflow now rather than waiting for the deadline. Recovery If a device fails to boot after a certificate transition (typically after a BIOS default reset), C:\Windows\Boot\EFI\SecureBootRecovery.efi adds the Windows UEFI CA 2023 certificate back to the DB. BitLocker sealed to PCR7 will demand its recovery key. Test this process on representative hardware before deploying broadly, especially on systems with BitLocker enforced via Group Policy and TPM with PCR7 sealing. Linux and dual-boot For dual-boot Windows and Linux systems, the Windows Update deployment will update the DB certificates that the Linux shim depends on. For pure Linux systems with no Windows installation, the distribution maintainers must publish shim binaries re-signed against Microsoft UEFI CA 2023 . Verify your distribution has shipped that update before you remove the 2011 DB entry. The same applies to PXE network boot infrastructure: any boot images you serve must be re-signed against 2023 keys before the corresponding 2011 entries are revoked. Operational Visibility at Scale The remediation paths are well-documented. The operational problem is that most organizations cannot see the state of their UEFI variables to begin with. Vulnerability scanners do not enumerate the contents of DB and DBX files. EDR agents do not inspect the KEK store. The Windows Security app surfaces a binary “Secure Boot is on” indicator that says nothing about which certificates are present, whether the DBX has current revocations, or whether the firmware-level and OS-level certificate state are aligned. Without that visibility, you cannot answer the questions that matter for this transition: Which devices in my fleet still have the 2011 KEK and have not received the 2023 update? Which devices have a DBX that is missing the BlackLotus, BootHole, or Bombshell-class entries? Which devices have received the certificate update via Windows Update but not the corresponding OEM firmware update, leaving them exposed to a CMOS-reset failure mode? Which devices report Secure Boot as enabled at the OS level but have firmware-level configuration that contradicts that claim, as Bombshell demonstrated? Eclypsium’s platform was built to answer exactly these questions. It provides continuous visibility into PK, KEK, DB, and DBX state across the device fleet, including PCs, servers, network appliances, and cloud infrastructure. It monitors firmware against known-good baselines and detects when certificate stores or boot components change unexpectedly, including: Detection of systems still on 2011 certs. Eclypsium’s product will detect devices that still have Microsoft Corporation KEK CA 2011 , Microsoft Corporation UEFI CA 2011 , or Microsoft Windows Production PCA 2011 in their UEFI variable state. Examples include: Detection of the expiring Microsoft Corporation UEFI CA 2011 certificate in the DB that also affects Linux systems using Secure Boot. Detection of the Microsoft Corporation KEK CA 2011 certificate set to expire in June 2026. DBX comparison to the current revocation baseline. Eclypsium’s platform will compare each device’s DBX against the current published UEFI revocation list and flag missing entries (BlackLotus, BootHole, Bombshell, etc.). Example: The broader context for this transition is the December 2025 NSA cybersecurity information sheet on UEFI Secure Boot, which makes the same observation: TPM presence and BitLocker enrollment do not imply correct Secure Boot configuration, and the vast majority of enterprise environments still run on outdated or default configurations. The 2026 deadline is the forcing function. Visibility determines whether you are forcing the transition or being forced by it. Timeline and Action Checklist Date Event 2011 Original Microsoft Secure Boot certificate family issued May 2023 CVE-2023-24932 (BlackLotus) patched; DBX revocations required June 2025 Microsoft publishes a formal “Act Now” advisory October 2025 Registry monitoring keys deployed; Bombshell (Framework UEFI shell) disclosed by Eclypsium December 2025 NSA releases UEFI Secure Boot guidance; Eclypsium publishes operationalization guide Early 2026 Microsoft begins phased certificate deployment via cumulative updates June 27, 2026 KEK CA 2011 and UEFI CA 2011 expire October 2026 Windows Production PCA 2011 expires Pre-deadline checklist: Audit Secure Boot status across the fleet at the UEFI variable level, not just OS reporting Identify devices still on 2011 KEK, UEFI CA, or Windows Production PCA Compare DBX state against the current Microsoft revocation baseline Apply OEM BIOS firmware updates before applying Windows Update certificate changes Set MicrosoftUpdateManagedOptIn registry key via GPO, Intune, or MECM Identify EOL hardware that will not receive OEM updates and treat it as elevated risk Test the certificate transition on representative hardware, especially BitLocker with PCR7 sealed systems Update PXE boot images and network boot infrastructure to 2023-signed boot managers before pushing DBX revocations For hypervisors, plan to update virtual machine EFI variable stores independently of host OS updates For Linux environments, verify your distribution’s shim is signed by UEFI CA 2023 before removing the 2011 DB entry For air-gapped environments, build and test an offline deployment procedure now Frequently Asked Questions Will my devices stop booting on June 27, 2026? + No. The existing certificates do not vanish. Already-trusted components keep working. What stops is forward security. Is the Platform Key affected? + No. The PK is OEM-owned. Microsoft does not control it. The expiration does not touch it. Can I ignore this if I run only Linux? + No. Shim depends on Microsoft UEFI CA 2011 . When that cert is revoked or removed without a 2023-signed shim, Secure Boot Linux stops booting. Will Windows Update handle everything automatically? + For most consumer and Microsoft-managed devices, yes. For enterprise, air-gapped, and OEM-EOL devices, no. Plan accordingly. What is the worst-case scenario? + A device misses the transition. The KEK expires. A bootkit drops with a known DBX entry. That device is permanently exposed because no revocation can reach it. Why is the DBX so important? + The DBX is the only mechanism for revoking vulnerable boot components in the field. Patches do not revoke. DBX entries do. No KEK, no DBX updates. No DBX updates, no bootkit remediation. Are my virtual machines covered when I update the host? + No. Each VM carries its own UEFI variable store. Update them independently. What about devices behind air gaps? + Use Microsoft’s offline tooling at aka.ms/GetSecureBoot . Build the workflow now, not in June. Should I worry about PCR7 and BitLocker? + Yes, if BitLocker is sealed to PCR7. Certificate changes will require the BitLocker recovery key on first boot. Have the keys ready and the process tested. What is the single most important sequencing decision? + Apply OEM firmware updates before applying Windows Update certificate changes. The OEM update embeds the new certificates in the firmware image itself, providing a durable recovery path if the certificate state is ever reset. Sources and Further Reading Microsoft documentation Microsoft: When Secure Boot certificates expire on Windows devices Microsoft Windows IT Pro Blog: Act Now, Secure Boot Certificates Expire in June 2026 Microsoft: Secure Boot DB and DBX variable update events Microsoft: Secure Boot Playbook for Certificates Expiring in 2026 Microsoft: Secure Boot Certificate Updates Explained Microsoft: Ask Microsoft Anything, Secure Boot (February 2026) Microsoft: OEM Secure Boot guidance Microsoft: Windows Secure Boot Key Creation and Management Guidance NSA and government guidance NSA: Releases UEFI Secure Boot Guidance (press release) NSA: Hardware and Firmware Security Guidance, Secure Boot README NSA: GRUB2 BootHole Cybersecurity Advisory Eclypsium research Eclypsium: How to Operationalize NSA Guidance on UEFI Secure Boot at Scale Eclypsium: There’s a Hole in the Boot (BootHole, CVE-2020-10713) Eclypsium: A Brief History of How Iron Sharpens Iron in Firmware Security Eclypsium: Firmware Security for Enterprises Vendor guidance Dell: Microsoft Secure Boot 2011 Certificate Expiration Impact on PowerEdge Red Hat: Secure Boot Certificate Changes in 2026, Guidance for RHEL Proxmox Support Forum: UEFI 2011 Certificates Expire in June 2026 TUXEDO: Secure Boot certificates expire in 2026, what do I need to do? Fedora Devel: Windows Secure Boot Certificate Expiration (June 2026) Technical analysis and community resources fwupd: UEFI Secure Boot Certificates Matthew Garrett: Secure boot certificate rollover is real but probably won’t hurt you Thomas-Krenn Wiki: Windows Secure Boot certificate expiry GitHub Issue: Expiring signing CA in 2026 (Microsoft Corporation UEFI CA 2011), rhboot/shim#679 Lansweeper: Secure Boot Certificate Expiration WSU ITS: Windows Secure Boot Certificates Expire 2026 Borncity: Windows 10 Secure Boot Insides on UEFI Systems Heise: Microsoft warns of secure boot certificate update Windows Forum: Secure Boot Certificate Rotation 2023, OS Side Deployment and Troubleshooting Windows Forum: Secure Boot Certificate Expiry 2026 (KB5065790) Related vulnerabilities and research Huntress: CVE-2023-24932 (Secure Boot Bypass) Vulnerability Borncity: KB5025885, Secure Boot Hardening Against CVE-2023-24932 (BlackLotus) Binarly: PKfail Vulnerability Research (BRLY-2024-005) WinBuzzer: Researchers Find Malware-Threatening Secure Boot Bypass in Hundreds of Devices Security Affairs: 200,000 Framework Linux systems shipped with vulnerable signed UEFI components Framework Community: BIOS Release Notes not sufficiently transparent or accurate Paul Asadoorian (LinkedIn): UEFI shells and Secure Boot, A trust issue in Framework laptops Decryption Digest: Firmware and UEFI Security Enterprise Guide 2026 The post Microsoft Secure Boot Certificates Expiring in 2026: Enterprise Impact appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise .