Secure Boot's 2011-era keys start expiring, cutting off boot updates on unpatched PCs

Microsoft’s Secure Boot signing certificates started expiring on June 24. The keys were baked into nearly every x86 PC shipped since 2011, and when they lapse, firmware can stop trusting freshly signed bootloaders. Most machines keep running. The security safety net underneath them quietly stops updating.

Here’s the stake. Secure Boot is the check that stops malware from hijacking your computer before Windows or Linux even loads. The certificates that make that check trustworthy were issued back in 2011 with a 15-year clock, and that clock has run out. LWN put it plainly on July 1: “Secure Boot certificate expiration is here.” The replacement exists and is already shipping through ordinary updates. The real risk is the pile of machines that never receive it, because for them the boot layer freezes in place with no way to patch the next bootkit.

What Secure Boot actually does

Secure Boot lives in your PC’s UEFI firmware, the low-level code that runs before the operating system. Its job is narrow and important. At power-on, the firmware checks the digital signature on each piece of boot code against a list of certificates it trusts, and it refuses to run anything that isn’t signed by a key on that list. That trust list is called the db. A companion deny list, the dbx, holds signatures that got revoked after someone found a way to abuse them. Together they are why a stolen or tampered bootloader can’t quietly load itself ahead of your kernel. When it works, you never notice it. That is the point.

One more key sits above both lists. The KEK, or Key Exchange Key, is the certificate that authorizes changes to those lists. When Microsoft needs to revoke a newly discovered malicious bootloader, it signs a fresh dbx entry with the KEK, and your firmware accepts the update because it trusts that key. Pull the KEK out of the chain and the update path closes. Nothing new gets added to the allow list, and nothing new gets added to the deny list either.

What breaks when the keys expire

The expirations land in stages, not all at once. Per Microsoft’s own guidance, the Microsoft Corporation KEK CA 2011 expired June 24, 2026. The Microsoft UEFI CA 2011, which signs third-party bootloaders including the Linux shim, expires June 27. The Windows Production PCA 2011, which signs the Windows boot manager itself, runs until October 19. Three dates, one underlying problem: after each one, Microsoft can no longer sign new boot components with that old key.

This is where the panic needs a correction. An expired certificate does not brick your machine. Expiry stops Microsoft from signing new things; it does not revoke the keys your firmware already trusts. A PC that boots today keeps booting tomorrow. What it loses is the future. Without the replacement certificates, issued in 2023, it can’t accept new Secure Boot updates, new revocations, or bootloaders signed after the cutoff. Microsoft says it bluntly: affected devices “will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.” Translate that from support-speak and it means a machine stuck on the 2011 keys is defenseless against the next boot-level attack, forever.

Why should you care about a deny list you’ve never touched? Because it’s the only thing that stops a real class of malware. The dbx exists precisely so Microsoft can blacklist bootkits like BlackLotus, the UEFI implant that bypassed Secure Boot on fully patched Windows in 2023 and forced a wave of emergency revocations. Those revocations only reach a machine through the KEK. A PC frozen on the expired 2011 keys can never receive the next one. So the day a new bootkit lands, and one always does, the patched world gets a dbx entry and the un-updated world gets nothing. That gap is the whole story here.

Windows, Linux, and who’s most exposed

For most Windows users this resolves itself. Microsoft is delivering the new 2023 certificates through the regular monthly updates, and from the April 2026 update the Windows Security app shows Secure Boot status under Device security. Microsoft also started escalating warnings on May 13 for Windows 10 and May 16 for Windows 11 when a PC still lacks the new certs. Install the updates, glance at the app, and most people are done. The catch is that on some builds the certificate swap is opt-in rather than automatic, so a machine can look patched while its Secure Boot keys are still stuck in 2011.

Linux is the sharper edge, especially on dual-boot laptops. Distributions boot under Secure Boot using a small signed program called the shim, and that shim is signed by the exact Microsoft UEFI CA that expired June 27. Red Hat, Rocky Linux, and others have shipped dual-signed shims that carry both the old and the new signatures, so they validate on either side of the transition. Delivery of the underlying certificate change runs through fwupd: version 2.0.8 and later can enroll the new db and KEK entries, pulled down through the Linux Vendor Firmware Service. One command, sudo fwupdmgr update, then a reboot, and the firmware trusts both the old and new Microsoft keys. This isn’t an untested pipe. The same service has already pushed dbx revocation updates more than 10 million times at better than 99% success, so the plumbing is proven even if this specific KEK swap is new territory.

There’s a catch nobody has tested at scale. A KEK update has never happened before, so some firmware handles it badly. Certain HP and Fujitsu models block standalone db updates outright, after real boot failures in the field, and need a firmware update applied first. That’s why the distro maintainers are nervous about people going off-script. Rocky Linux’s advice is blunt: “Do not attempt to manually enroll the new KEK or CAs unless you know exactly what you’re doing and have a tested recovery path.” Enroll a KEK the firmware chokes on and you can lock yourself out of your own boot process.

What this means for you

Three moves, ranked by effort. If you run Windows, keep installing the monthly updates, then open Windows Security, go to Device security, and confirm Secure Boot lists the updated 2023 certificates. If the status looks stale, the rollout may be opt-in on your build, and aka.ms/GetSecureBoot has the registry key that switches it on. If you run Linux, update fwupd to 2.0.8 or newer, run sudo fwupdmgr update, reboot, and check the keys enrolled with mokutil or efi-readvar before you trust it. If you dual-boot, do the Linux update and confirm both operating systems still start before you rely on the machine for anything. And whatever you run, don’t hand-edit the KEK yourself. That one move is how a non-event becomes a brick.

An expired certificate was never going to stop your PC from turning on, and the headlines calling this a shutdown got it backwards. The machine that never gets the 2023 replacement is the one to watch, because it’s the one that stays vulnerable to every boot-level attack that ships after today.