SEAN GLADWELL via Moment / Getty Images
Follow ZDNET: Add us as a preferred source on Google.
ZDNET’s key takeaways
- Linux has a new Secure Boot problem.
- But it’s not nearly as bad as some people make out.
- Here’s what you can do to address the issue.
Back in the late 2000s, computer firmware was moving from legacy BIOS to UEFI Unified Extensible Firmware Interface (UEFI). Alongside it came Secure Boot. This Microsoft-supported security mechanism was designed to stop bootkits and firmware‑level malware that traditional operating system security couldn’t detect in its tracks. Secure Boot was messy, but it did the job. For people trying to install and run Linux on Windows PCs, this setup was a real pain in the rump. Here we are, 14 years after Secure Boot first appeared on Windows 8 PCs, and it once again has the potential to give Linux users a real headache.
Once again, some Linux lovers are in a panic that “Microsoft is locking Linux out!” That’s not what’s going on. As Microsoft pointed out, “Secure Boot certificates have always had expiration dates.” Yes, yes, they have. Besides, as Ed Bott recently observed, while it’s not nearly as annoying for Windows users, some people may still have trouble with expiring Secure Boot certificates.
The good news is that this concern is not a doomsday event for Linux. Your existing systems aren’t going to wake up one morning and refuse to boot just because a date rolled over. But it is a moment of truth about how the Linux world has handled Secure Boot for more than a decade, and an opportunity for users to take more control, rather than quietly hoping that Microsoft and OEMs keep the lights on forever.
Also: I tested the best MacOS alternative on Linux again – and it even mimics Liquid Glass now
Let’s walk through what’s actually happening, why Linux is involved, and what you should be doing before 2026 and beyond.
An old compromise comes due
To understand why, you have to go back to 2011 to 2012, when UEFI Secure Boot first landed on mass‑market PCs. The design goal sounded reasonable: stop untrusted code from running before the operating system by having firmware verify signatures of bootloaders, kernels, and option ROMs.
In practice, though, Microsoft effectively defined the trust roots for almost every consumer PC. Rather than creating — or having users create — Secure Boot keys and certificates, most hardware vendors shipped machines with a set of keys and certificates embedded in the firmware. Most of these keys and certificates were “Microsoft 3rd‑party UEFI CA” that could sign third‑party bootloaders. Distributions that wanted to “just boot” on these systems without asking users to flip obscure firmware switches basically had two options:
- Ship instructions for users to disable Secure Boot.
- Or play along and get a tiny first‑stage bootloader (shim) signed by Microsoft’s UEFI CA.
Most major Linux distributions chose shim. Matthew Garrett, a well-known Linux programmer, created the shim approach, and it’s still used today.
This approach was a pragmatic compromise: Microsoft verifies the shim, the shim verifies the rest of the Linux boot chain, and users don’t have to hand‑edit UEFI key databases or turn off security features.
Also: Windows Subsystem for Linux gives developers a compelling reason to stick with Microsoft – here’s why
That compromise worked remarkably well. For more than a decade, you could buy a random laptop, flip Secure Boot on, and boot Fedora, Ubuntu, openSUSE, Debian, RHEL, and others, all thanks to the Microsoft key stored in your firmware and a Microsoft‑signed shim binary in your EFI System Partition.
But certificates, unlike compromises, have expiration dates.
What’s expiring in 2026?
The root of today’s drama is that the 2011 certificates Microsoft has been using to sign Secure Boot components are nearing the end of their formal validity period. Several of the 2011‑era Microsoft Secure Boot certificates reach their end of life in 2026, in two main waves (mid‑year and later in the year).
To address this issue, Microsoft created a new set of Secure Boot certificates in 2023 and began distributing them to OEMs and platforms. Firmware updates are supposed to do the quiet work: adding new keys, keeping the old ones for compatibility, and ensuring future boot components can be validated.
Also: Microsoft continues its big Linux push at Build 2026
For Windows‑only shops, this is mostly an automatic patch job. For the Linux world, it’s a different story,
When people hear “certificate expiration,” they tend to imagine something like an SSL certificate: once it’s past the “notAfter” date, clients refuse to talk to the server. That mental model makes 2026 sound like a cliff edge: June 24 arrives, and suddenly your distro won’t boot.
Secure Boot doesn’t work that way. If your firmware already trusts the 2011 Microsoft UEFI CA today, it will almost certainly continue to trust it after the calendar rolls into the expiration window. Existing Linux installs, with their existing shim and bootloaders, will continue to boot as they always have. Nothing will magically brick itself at midnight.
Here’s the problem
The trouble is not your present boot; it’s your future boot. If your older PC’s firmware never gets the 2023 keys, and the rest of the world starts assuming those keys exist, you can end up stuck in a weird limbo. While your existing Linux install will still boot, a new or updated distro won’t.
Also: Microsoft surprises with its first server Linux distribution: Azure Linux 4.0
Hopefully, your PC vendor will ship firmware with the new keys, the Linux distros update their shims to be compatible with the new keys, and everything works out. We should be so lucky.
Here’s what to do:
1. Update your firmware
Every major vendor has been shipping updates that, among other things, add or adjust Secure Boot keys in response to Microsoft’s 2023 certificates and the upcoming expirations. You don’t need to know the exact key IDs to benefit; you need to make sure your system receives those updates.
On a typical Linux machine, that approach means checking your vendor’s support site for BIOS/UEFI updates released in the last year or two. On many systems, you can use Linux’s firmware update stack, fwupd, to handle this from within your distro. To take this step, run the following commands as the root user:
- fwupdmgr refresh
- fwupdmgr get-updates
- fwupdmgr update
If your hardware is supported, these steps will pull down firmware capsules and UEFI db/dbx updates that include the new Microsoft Secure Boot certificates. After the update, you’ll need to reboot once or twice; the firmware will update itself, and you’re done.
Also: My top 5 Linux desktops of 2026 (so far) – and I’ve tried them all
On some older systems, you may still have to download an .exe or .iso from the vendor and follow their dance. This procedure is annoying, but it’s a one‑time chore that buys you years of smoother Secure Boot behavior.
2. Check how your distro handles certificates
Most mainstream Linux distributions have already considered the 2026 expiration and concluded that it is not an emergency but something to address carefully.
Many distributions are aligning their shim builds and signing processes to remain compatible throughout the transition. If you’re on a modern release of a big‑name distro and your firmware is up‑to‑date, chances are high that “it just works” will continue to be true.
For you, the simplest test is also the most practical:
Do this test once now, so you know what the new normal looks like. If a future image fails to boot with Secure Boot enabled, you’ll be able to tell whether the regression is in the firmware (keys not updated), the distro’s image, or a nasty interaction between the two.
Also: After 30 years with Linux, I gave Windows 11 a chance – and found 9 clear problems
Many of the most popular Linux distros have already addressed the Secure Boot issue. Red Hat has published dedicated guidance on Secure Boot expiration and maintains RHEL/Fedora shim/bootloader stacks that are signed and aligned with Microsoft’s trust model. Canonical’s Ubuntu family has long shipped full Secure Boot support. Ubuntu’s current installers and kernels are signed under the existing Microsoft 3rd‑party UEFI CA.
SUSE and openSUSE are also ready to go with the new CAs. Debian’s Secure Boot infrastructure is important because its shim is used by many distros and was developed by a cross‑distro team. Some Linux distros, however, such as Arch and its relatives, do not make it easy to support Secure Boot.
The tempting workaround
If you hang around Linux forums long enough, you’ll see the same advice repeated whenever Secure Boot comes up: “If it gives you trouble, just disable Secure Boot.”
I get it. I’ve done it myself. Secure Boot has been a pain since it first appeared. For many users, the easiest path has been to turn it off and make the problem disappear.
The danger is when the temporary hack becomes permanent. With Secure Boot disabled, you lose the Secure Boot defense against rootkits and the like. While “script‑kiddie” rootkits are less common than they were a decade ago, modern user‑, kernel‑, and even hypervisor‑level rootkits are still very much in active use by both crooks and high‑end attackers. Rootkits remain one of the nastier classes of malware because they focus on stealth and persistence.
Also: What is immutable Linux? Here’s why you’d run an immutable Linux distro
Is Secure Boot a silver bullet? No. Does it replace good system hygiene, patching, and backups? Absolutely not. But Secure Boot is a meaningful shield, and the Linux ecosystem has worked hard to make it mostly invisible to everyday users. Throwing Secure Boot away because it’s a pain today is a mistake.
Here, specifically, is what you should do about the expiring certificates.
For your PCs:
- Update firmware: Before mid‑2026, install the latest BIOS/UEFI updates from your vendor. If fwupd supports your hardware, use it. It’s less painful than juggling Windows tools or bootable updaters.
- Confirm Secure Boot still works: Make sure your existing distro boots cleanly with Secure Boot enabled. Then try a current live image from the same distro. If both work, you’re in good shape.
- Keep Secure Boot on, if you can: Treat it as a normal part of your system’s security posture. If something fails, debug and temporarily disable it as needed, but don’t abandon it lightly.
For your servers:
- Inventory what you have: Note which machines have Secure Boot enabled and what firmware they’re running. You don’t need a fancy Configuration Management Database (CMDB); a spreadsheet is fine.
- Standardize on a firmware baseline: Pick current firmware versions that include the new Secure Boot keys (your vendor’s release notes may mention this) and roll them out across your lab.
- Test new images early: Before you upgrade everything to a new major distro release, test that release’s installer and boot chain on a representative system with Secure Boot on, catch surprises on a sacrificial node.
So, in short, while this Secure Boot is a headache, it’s not that bad. Just make sure your firmware is up to date, and your Linux distro is ready to handle the new certificates, and all will be well.
