Why Microsoft's Secure Boot Changes Matter to Linux Users

Microsoft's 2011 Secure Boot signing certificate runs out on June 27, 2026, and if you run Linux with Secure Boot turned on, that date actually means something for you, even though your machine is not going to fail to boot the morning after.

Secure Boot on a typical PC works because Microsoft signs the first stage bootloader almost everyone uses, including the one baked into most Linux distros. That arrangement has worked fine for over a decade, but the key behind it has an expiration date like any certificate does, and that date lands this month. What is still genuinely unresolved is the long tail: machines from smaller vendors, old laptops nobody is patching anymore, and embedded devices that never see a firmware update again after they ship. Nobody has a clean answer for those yet, and probably won't until people start hitting the problem in the field.

What Actually Expires on June 27

The certificate in question is the Microsoft Corporation UEFI CA 2011, and its only job is signing third party boot components, the most relevant one being shim, the small bootloader most Linux distros use to satisfy Secure Boot before handing control to GRUB and the kernel. Once June 27 passes, Microsoft simply cannot use that key to sign anything new. It is the same thing that happens to any certificate once it ages out, nothing more dramatic than that.

A second, related certificate, the Microsoft Corporation KEK CA 2011, expires even earlier, on June 24. That one signs updates to the firmware's trusted database (db) and the forbidden database (dbx), which matters for how new keys eventually get enrolled or bad ones get blocked. It is a separate piece of the same expiring infrastructure, and it is worth understanding if you manage fleets rather than a single laptop, a topic covered in more depth in our Linux kernel security coverage.

Why Your Machine Keeps Booting Anyway

This is the part that gets garbled the most online. Expiration affects signing, not validation. The 2011 public certificate is already sitting in your firmware's trust database, and it stays there. Your existing, already signed shim was signed back when the key was valid, and firmware checks the signature against the certificate that was valid at signing time, not against today's date. So a system booting Linux successfully today keeps booting successfully after June 27, full stop.

What changes is everything pointed forward. Any new shim binary Microsoft would otherwise sign after the expiration date cannot be signed with that key anymore. That is the entire mechanism, and it is the reason distro maintainers spent the last several months getting dual signed shims ready rather than scrambling now.

Existing Red Hat Enterprise Linux systems that boot successfully today will continue to boot after June 27, 2026. The certificate expiration affects the ability to sign new boot components, not the ability to boot with already trusted ones.

Red Hat Developer, February 2026

Where Each Distro Stands Right Now

RHEL, AlmaLinux, and Rocky Linux are the furthest along simply because they all track the same shim packaging. Red Hat shipped a dual signed shim, meaning one binary carrying both the 2011 and 2023 signatures, for RHEL 9 and RHEL 10 back in May, with RHEL 8 following in June. That single binary boots on any machine that has either certificate enrolled, which is the whole point of dual signing: it works whether your firmware already trusts the 2023 key or is still stuck on the 2011 one.

Fedora is handling it in a way that fits its release model. Rawhide, the rolling development branch feeding into the next release, already ships the dual signed loader. Stable Fedora releases get it through the normal dnf update cycle, the same command covered in our look at Fedora 44's recent updates. Ubuntu and Debian are shipping their own updated shim packages too, and on both the fix is whatever you already run to keep a system current.

The Part Nobody Has a Clean Answer For

The shim side of this is mostly solved or close to it. The firmware side is messier, and it is messier because firmware updates depend on hardware vendors actually shipping them, which is historically the weakest link in this whole chain. A laptop or desktop from a smaller or less actively supported vendor might never get a firmware update that enrolls the 2023 certificate, and that is not something distro maintainers can fix from their side no matter how good their shim packaging is.

Fedora's own guidance on this is blunt: don't try to force an update if your firmware does not offer one, and definitely don't remove or revoke the 2011 key yourself. It is not compromised, only expiring, and it also signs option ROMs for things like network cards and RAID controllers, so yanking it can break hardware that has nothing to do with booting your OS.

On the desktop and hardware side, this overlaps with broader firmware support questions we have covered around devices like the Framework Laptop 13, where vendor firmware update cadence has been a recurring topic, and with general Ubuntu desktop security patching practices that already lean on fwupd for exactly this kind of update.

What To Actually Check On Your System

You can confirm which keys your firmware currently trusts with a single command. Running mokutil --db --short lists the certificates enrolled in your db, and if you see both "Microsoft Corporation UEFI CA 2011" and "Microsoft UEFI CA 2023" in that output, your firmware is already prepared for the transition, assuming your shim is dual signed too.

If you only see the 2011 entry, the fix in most cases is sudo fwupdmgr update, which pulls firmware updates through the Linux Vendor Firmware Service when your vendor has published one. Dell, HP, Lenovo, and several others have already pushed updates that include the 2023 certificate for current models. If fwupd has nothing for your hardware, checking the manufacturer's support page directly is the only real path left, the same kind of legwork covered for the recent Dirty Frag vulnerability response. And if Secure Boot is disabled on your machine already, none of this chain applies to you at all, though that trades away the bootkit protection Secure Boot exists for in the first place.

What Happens Next

Past June 27, the thing worth watching is whether any major vendor turns up missing a firmware update for a model that is still under support. That is the scenario that turns this from a non event into an actual headache. There is also a structural change worth knowing about: the 2011 key's other job, signing third party option ROMs for things like GPUs and NICs, is being split into its own separate 2023 certificate instead of staying bundled with OS bootloader signing. That is a real security improvement, letting environments trust Linux shim without also trusting arbitrary hardware option ROMs, but it is new enough that edge cases are still surfacing.

For most people on a maintained distro with hardware that still gets vendor support, this resolves with a routine package update, the same kind of maintenance covered in our breakdown of systemd 260's compatibility changes. The cases actually worth worrying about are the old, unsupported, or orphaned machines where nobody is shipping a firmware update at all.