Microsoft’s original Secure Boot certificates are reaching the end of their 15-year life in stages, beginning with the Microsoft Corporation KEK CA 2011 certificate on June 24, 2026. Machines that miss the replacement certificates will not suddenly die on the next reboot. They will keep starting, while part of the trust system that blocks future boot-level threats begins to age underneath them.
The change replaces the 2011 Secure Boot trust anchors stored in firmware with newer 2023 certificates. Microsoft says most Windows devices will receive the update automatically through Windows Update, but enterprise fleets, older hardware, servers, virtual machines, dual-boot systems and unusual firmware configurations are where the deadline becomes operationally messy.
The stakes are not abstract. Secure Boot is the pre-operating-system gatekeeper that decides which boot managers, firmware components and early startup code are allowed to run. If that trust chain cannot be updated, future revocations against compromised bootloaders may never reach the machine.
What expires first
Microsoft’s own Secure Boot certificate table lists three original certificate lines reaching expiration in 2026: Microsoft Corporation KEK CA 2011 on June 24, Microsoft UEFI CA 2011 on June 27, and Microsoft Windows Production PCA 2011 on October 19. The replacement set uses 2023 certificates, including separate certificates for third-party UEFI bootloaders and option ROMs.
The June 24 date matters because the KEK, or Key Enrollment Key, signs updates to the allowed and disallowed Secure Boot databases. Microsoft explains in its Secure Boot certificate expiration guidance that devices without the newer certificates will continue to start and install standard Windows updates, but will lose access to new early-boot protections over time.
That is the crucial distinction. This is not a one-day mass boot failure. It is a quiet shift into a degraded security state, where future updates to Windows Boot Manager, Secure Boot databases, revocation lists and boot-level mitigations may no longer apply.
What June 24 does not do
During a June 4 Microsoft Ask Microsoft Anything session covered by Windows Latest, Microsoft engineer Scott Shell said June 24 is not a hard stop for the manual rollout mechanism. Payloads already signed under the old certificates, including the DB update, registry key and scheduled task path, continue to work.
What changes is Microsoft’s ability to sign new DBX payloads with the old KEK. DBX is the disallowed signature database, the blacklist that tells Secure Boot which compromised or malicious bootloaders must no longer be trusted.
A machine without the 2023 KEK will not suddenly fail to boot on June 25. It will instead become less able to receive the next wave of revocations, which is exactly the kind of slow-moving infrastructure failure that tends to show up only after the next bootloader vulnerability is disclosed.
Why boot-level trust matters
Secure Boot exists because the firmware and bootloader layer loads before the operating system and before most endpoint security tools. Microsoft describes Secure Boot as a UEFI-based feature that verifies pre-boot software against trusted certificates stored in firmware before handing control to the bootloader.
Bootkits abuse that early moment. A 2005 Black Hat presentation on eEye BootRoot showed how boot-sector code could execute after the BIOS but before Windows, patching the startup path before the operating system had fully taken control.
The threat later moved lower. In 2018, ESET reported LoJax, the first UEFI rootkit found in the wild, attributed to Sednit, also known as APT28, Sofacy and Fancy Bear. ESET said the implant was written into SPI flash memory and could survive an operating system reinstall or even a hard drive replacement.
In 2020, Kaspersky described MosaicRegressor as the second known public case of malicious UEFI firmware used by a threat actor in the wild. That case involved modified UEFI firmware modules that dropped malware into Windows and rewrote it if it disappeared from disk.
The LogoFail reminder
The urgency around Secure Boot did not come only from certificate age. In 2023, Binarly disclosed LogoFail, a set of UEFI vulnerabilities involving the image parsers that display boot-time logos.
The bugs mattered because logo parsing happens during the firmware boot process, before the operating system starts. In the wrong conditions, that meant an attacker could use a logo image path to interfere with the very trust boundary Secure Boot is supposed to defend.
Rotating Secure Boot certificates does not patch LogoFail. Firmware updates from vendors do that. But the certificate refresh gives Microsoft, OEMs and operating-system vendors a current trust base for future revocations and boot-level mitigations.
What ordinary users should do
For most Windows 10 and Windows 11 users on supported systems, the action is simple: keep Windows Update and firmware updates current. Microsoft says most devices with Microsoft-managed updates will receive the new certificates automatically, although some machines may require firmware updates from the manufacturer.
The Windows Security app can show Secure Boot certificate status on supported systems. A green status means the device is already updated. A warning generally means the user should check the PC maker’s support page for a compatible firmware update before forcing anything manually.
Unsupported Windows versions are different. Microsoft says devices that no longer receive Windows updates will not receive the new certificates, except where an Extended Security Updates path applies. Those machines may continue to run, but their boot-level trust will not age safely.
Where enterprises get caught
The hard part is enterprise inventory. A fleet may contain thousands of machines that share a model name but not a firmware version, firmware date, platform key state or telemetry history. Microsoft’s high-confidence rollout system evaluates those combinations before automatically applying Secure Boot certificate updates.
That is why one laptop can update cleanly while another nominally identical laptop sits in a paused bucket. A temporarily paused state usually means Microsoft detected a firmware-level compatibility concern and expects an OEM firmware update before the certificate change is attempted.
Devices outside high confidence, including white-box PCs, older servers, sparse-telemetry machines and uncommon firmware variants, may require administrators to use Intune, Group Policy, registry settings or scripted remediation. The safe sequence is to test one representative unit per firmware variant, confirm event logs and certificate state, and only then widen the rollout.
Machines with Secure Boot disabled create a separate trap. Microsoft cannot update the firmware certificates while Secure Boot is off. Windows may still update the boot manager to a 2023-signed version, and a later attempt to re-enable Secure Boot can fail if the firmware still trusts only the 2011 certificate.
PXE boot environments need the same kind of sequencing. Systems that trust only the 2011 certificate can continue to boot media signed under that certificate as long as it has not been revoked in DBX, but newer devices that trust only 2023 certificates may reject older PXE media. During the transition, deployment teams may need parallel boot media until every target class trusts the same certificate set.
The certificates expire in stages. The machines keep running. What changes is the invisible list of who can still receive the next revocation, the next bootloader block and the next firmware-layer mitigation when the attack surface moves again.
