The most important security deadline in Windows’ 15-year Secure Boot history arrives this Wednesday. On June 24, 2026, the Microsoft Corporation KEK CA 2011 — the cryptographic Key Exchange Key that authorizes Windows to update your device’s boot security databases — officially expires. For the Windows devices that have not yet received Microsoft’s 2023 replacement certificates, the consequence is not a broken PC. It is something more permanent: the irreversible loss of every future Secure Boot bootkit revocation, for as long as the device operates.
The device will keep booting. Standard Windows updates will continue to install. But the trust chain that allows Microsoft to push new entries to your device’s boot security blocklist will be severed. Every bootkit discovered after June 24 — not just BlackLotus, not just BootHole, but every future bootkit not yet written — will have a permanent, irremediable attack surface on any Windows PC that misses this transition.
What Secure Boot Actually Does Before Windows Loads
Secure Boot is a UEFI firmware mechanism that runs before Windows itself. When a PC powers on, the firmware checks the cryptographic signature of every component loaded in the boot sequence — bootloaders, firmware drivers, and ultimately the OS itself — against databases stored in the motherboard’s non-volatile RAM. Only software with trusted signatures is allowed to run. Anything on the blocklist is stopped at the firmware level, before Windows can even begin loading.
The system works through a hierarchy of three nested keys stored in firmware. At the top is the Platform Key (PK), owned by your PC’s manufacturer. The PK is the root of trust, and it authorizes changes to everything below it. Below the PK sits the Key Exchange Key (KEK), which Microsoft controls. The KEK is the credential that grants Windows Update the authority to modify the two databases that Microsoft’s Secure Boot documentation describes as the foundation of the trust chain: the Signature Database (DB) — the trusted guest list of certificates that allow bootloaders and drivers to run — and the Forbidden Signature Database (DBX), the blocklist of signatures for known-malicious software that Secure Boot will refuse to execute.
The DBX is how the security industry responds when a bootkit is discovered in the field. When BlackLotus was identified in 2023 — the first publicly confirmed bootkit capable of bypassing Secure Boot on a fully updated Windows 11 system — Microsoft pushed the exploit’s signature to every connected device’s DBX through Windows Update. Every Secure Boot-enabled PC could then reject that specific threat at the firmware level. That entire response mechanism depends on the KEK being valid.
Why the KEK Expiry Matters More Than the Others
Microsoft issued three certificates in 2011 that have collectively underpinned Secure Boot for every Windows device sold since Windows 8. All three are expiring:
| Certificate | Role | Expiry Date |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | Authorizes DB and DBX updates | June 24, 2026 |
| Microsoft Corporation UEFI CA 2011 | Signs third-party bootloaders including Linux Shim | June 27, 2026 |
| Microsoft Windows Production PCA 2011 | Signs the Windows bootloader | October 19, 2026 |
The KEK expiry on Wednesday is the most operationally critical. Once it lapses on a device that has not received the 2023 replacement, Microsoft permanently loses the cryptographic authority to push new entries to that device’s DB or DBX using the old certificate chain. The architectural difference from an ordinary Windows patch is significant: the 2011 KEK and its replacements live in firmware NV-RAM, not in the Windows software layer. A conventional OS patch cannot restore this authority. Only an OEM firmware update that embeds the 2023 certificates at the hardware level can recover a stranded device — and many OEMs will never ship such an update for hardware they no longer support.
What Happens to Your Device After June 24
The good news is simple and bears repeating: your PC will not stop booting. Standard Windows updates — drivers, security patches, feature releases — will continue to install normally. The transition date is not a cliff.
The bad news is precisely what you permanently lose. According to Microsoft’s own documentation, a device that misses the transition will be frozen at whatever DB and DBX state it held at the moment of expiry, with no path forward. Future Secure Boot database updates, new Windows Boot Manager versions signed with the 2023 certificates, and any subsequent bootkit revocations cannot reach it.
There is also a practical implication for dual-boot Linux users. Red Hat released a new dual-signed Shim for RHEL 8, 9, and 10 on June 10, 2026, signed with both the 2011 and 2023 certificates. After the UEFI CA 2011 expires on June 27, future Shim updates will be signed only with the 2023 key. A dual-boot device that never receives the 2023 certificate update will eventually be unable to install new Shim versions — which means it cannot apply Shim security patches for future CVEs discovered in the bootloader chain.
Every Future Bootkit Wins on Devices Frozen After Wednesday
The most consequential implication of this deadline is one that most coverage has understated. The DBX freeze problem is not bounded to the bootkits already discovered. What the KEK expiry permanently disables is the discovery-to-revocation pipeline for all future bootkits.
Firmware security firm Eclypsium has described the result as a permanent two-tier security ecosystem. Updated devices remain capable of receiving new DBX entries when future bootkits are discovered and revoked. Unupdated devices are frozen indefinitely — meaning that every future bootkit campaign targeting any known-revoked bootloader component will succeed on those devices, because their DBX cannot be updated to block it.
This gap is invisible to standard enterprise security tooling. As Eclypsium noted, no conventional vulnerability scanner currently enumerates UEFI variable contents, and no endpoint detection and response product compares a device’s DBX entries against the UEFI Forum’s published revocation list. Most organizations cannot currently answer the basic question: which devices in their fleet still hold the 2011 KEK?
The NSA’s December 2025 cybersecurity information sheet on UEFI Secure Boot reinforced exactly this point: TPM presence and BitLocker enrollment do not imply correct Secure Boot configuration, and most enterprise environments run on outdated or default configurations that may not reflect current certificate state.
BlackLotus, the UEFI bootkit that ESET confirmed in the wild in early 2023, demonstrated what a frozen DBX means in practice. Exploiting CVE-2022-21894 and CVE-2023-24932, the bootkit replaced a legitimately signed but vulnerable boot manager with an older version, then loaded unsigned kernel drivers. Microsoft’s DBX-based mitigation response — adding the vulnerable boot manager signatures to the blocklist — required years of staged rollout precisely because getting the revocation wrong can strand legitimate systems. Devices that never receive the KEK transition cannot receive any comparable response to the next bootkit.
Who Is at Risk: The Devices That May Never Get the Fix
Microsoft began a phased automatic rollout of the 2023 replacement certificates through Windows Update in early 2026. PCs manufactured since early 2024 already ship with the 2023 certificates pre-installed. For most consumer devices managed by Microsoft with automatic updates enabled, the transition should arrive silently.
The structural risk lies at the edges of the ecosystem. XDA Developers reported in March 2026 that some pre-2020 Windows hardware will likely never receive the fix. The most vulnerable categories include older enterprise hardware where OEM firmware was never updated to support the 2023 certificates. Some HP and Fujitsu platforms specifically require firmware updates before DB and KEK changes can safely be applied — and standalone DB updates are blocked on those platforms until the firmware prerequisite is met.
IoT and Windows-on-ARM edge devices with limited or no firmware update paths face the same exposure, as do air-gapped networks and IT-managed environments that block or throttle Windows Update access. Virtual machines carry their own independent UEFI variable stores and must be updated separately from the host. As Google Cloud documented, Shielded VM instances created before November 7, 2025 require separate certificate update actions. Devices with OEM hardware that reached end-of-support before early 2026 face permanent limitations — if no firmware update exists that embeds the 2023 certificates, the only remediation paths are manual recovery processes or hardware replacement.
The Architecture Upgrade: How the 2023 Certificates Differ
The 2023 certificate set is not a simple one-for-one renewal of the 2011 credentials. Microsoft restructured how the certificates work, in a change that matters for understanding what the transition actually enables.
The original Microsoft Corporation UEFI CA 2011 was a monolithic signing authority: it signed everything, including third-party bootloaders, option ROMs for add-in cards such as graphics cards and network adapters, and various firmware components. The 2023 architecture splits this into two distinct certificates. The Microsoft UEFI CA 2023 handles third-party bootloader signing. A separate Microsoft Option ROM UEFI CA 2023 specifically covers option ROM signing for add-in card firmware.
This separation means systems that do not need to trust option ROMs no longer have to. A server or workstation operator can enroll the bootloader signing CA without granting implicit trust to firmware on every PCIe card in the system. This closes a supply chain attack surface that existed in the original 2011 architecture — one where a compromised or malicious option ROM signed by the same CA as the Windows bootloader was implicitly trusted during boot. The replacement KEK, Microsoft Corporation KEK 2K CA 2023, takes its name from its larger 2K key size. The 2023 certificates are valid through 2038.
How to Check Whether Your Device Has Made the Transition
Microsoft’s central resource hub for the transition is at aka.ms/GetSecureBoot, which includes offline tooling for environments where Windows Update cannot be used directly.
Administrators can verify certificate status through the UEFICA2023Status registry value under HKLM:SYSTEMCurrentControlSetControlSecureBootServicing. A value of "Updated" confirms the 2023 certificates are installed. Values of "NotStarted" or "InProgress" indicate the rollout has not yet completed on that device. Event ID 1808 in the Windows System Event Log indicates successful certificate deployment; Event ID 1801 signals that updated certificates have not been applied.
For consumer Windows 11 users, the Windows Security app under Device Security shows a Secure Boot status indicator — a green badge signals the transition is complete; yellow or red indicates action is required.
For devices with BitLocker enabled and PCR7 binding in place, administrators should be aware that the certificate change triggers a BitLocker recovery key prompt on the first boot after the update — expected behavior that should be communicated to end users in advance. That interaction was already documented in recent weeks when KB5094126, the June 9 Patch Tuesday update, pushed Secure Boot certificate data and triggered BitLocker recovery on some enterprise devices.
A Two-Tier Security Ecosystem, Permanently
The expiry creates what Eclypsium has called a permanent two-tier security ecosystem. Updated devices remain capable of receiving future DBX revocations for every bootkit yet to be discovered. Unupdated devices are frozen at a 2026 baseline — no conventional security tool will detect the gap, because no vulnerability scanner looks inside UEFI variable contents.
For organizations with compliance postures that depend on measured boot, TPM attestation, or BitLocker — all of which interlock with the Secure Boot chain — confirming fleet status before Wednesday is no longer optional.
The 2023 replacement certificates are valid through 2038. After that, the industry will face another transition driven by the post-quantum cryptography mandate. Microsoft Principal Software Architect Scott Shell confirmed in the March 2026 AMA session that new hardware manufactured from the 2030s onward will ship with entirely new post-quantum certificate architectures.
The Checklist for the Next Two Days
For organizations and individuals who have not yet confirmed their status:
Check the UEFICA2023Status registry value on representative devices. Any device showing "NotStarted" or "InProgress" needs immediate attention. For enterprise environments using Microsoft Intune, the Secure Boot status report in Windows Autopatch shows compliance across the fleet.
Consult your OEM’s firmware update page if devices are not progressing through the rollout. HP and Fujitsu devices in particular require firmware updates before DB and KEK changes can safely be applied. Do not force-install certificate updates on devices marked as temporarily paused — Microsoft has warned this can cause boot failures on platforms with specific firmware requirements.
For virtual machine environments, updating the host does not update guest VMs. Each VM with Secure Boot enabled needs to be updated separately through the appropriate hypervisor management path.
For dual-boot Linux systems, verify the installed Shim version supports dual-signing. Red Hat has released dual-signed Shim for supported RHEL 8, 9, and 10 releases. Ubuntu, Debian, and Fedora have issued equivalent updates.
Before the update applies on any BitLocker-protected device, ensure the BitLocker recovery key is retrievable — whether from Microsoft Entra ID, Active Directory, or a securely stored local backup.
The remediation path for devices that miss Wednesday without a viable OEM firmware update path is narrow: manual recovery processes, hardware replacement, or accepting permanent firmware-level security stasis. For consumers on mainstream hardware with automatic Windows Updates enabled, the transition is likely already complete and no action is needed.
Frequently Asked Questions
Will my PC stop working after June 24 if I haven’t updated Secure Boot?
No. Devices that have not received the 2023 certificate update will continue to boot and receive standard Windows patches normally. What they permanently lose is the ability to receive future Secure Boot database updates — meaning Microsoft cannot push new bootkit revocations to those devices. The consequence is a gradual degradation of boot-level security rather than an immediate failure.
How do I check whether my Windows device has the updated Secure Boot certificates?
Open the Windows Security app, select Device Security, and look for the Secure Boot status indicator. A green badge means the transition is complete. Alternatively, navigate in the Registry Editor to HKLM:SYSTEMCurrentControlSetControlSecureBootServicing and check the UEFICA2023Status value — it should read “Updated” on a fully migrated device. Microsoft’s full guidance hub is at aka.ms/GetSecureBoot.
Does the Secure Boot certificate expiry affect Linux or dual-boot systems?
Yes. Every major Linux distribution that supports Secure Boot relies on a first-stage bootloader called Shim, signed by the Microsoft Corporation UEFI CA 2011 certificate that expires June 27. Red Hat released a dual-signed Shim for RHEL 8, 9, and 10 on June 10, 2026; Ubuntu, Debian, and Fedora have issued equivalent updates. On dual-boot systems, after the UEFI CA 2011 expires, only Shim versions signed with the 2023 certificate will be trusted on devices that have made the transition — so firmware and Linux package updates should ideally happen in coordination.
What is a DBX revocation and why does it matter after this deadline?
The DBX, or Forbidden Signature Database, is the Secure Boot blocklist stored in firmware. When a bootkit or vulnerable bootloader is discovered, Microsoft adds its cryptographic signature to the DBX and pushes the update to connected devices. That update requires a valid KEK to authorize it. After the KEK CA 2011 expires, a device that has not received the 2023 replacement can no longer accept new DBX entries — meaning every future bootkit discovered after June 24 has a permanent, unblockable path into unupdated devices’ boot chains.
