With the original release of Windows 8, Microsoft also enforced Secure Boot. It’s been 15 years since that release, and that means the original 2011 Secure Boot certificates are about to expire. If these certificates are not replaced with new ones, Secure Boot will cease to function – your machine will still boot and operate, but the benefits of Secure Boot are mostly gone, and as newer vulnerabilities are discovered, systems without updated Secure Boot certificates will be increasingly exposed.
Microsoft has already been rolling out new certificates through Windows updates, but only for users of supported versions of Windows, which means Windows 11. If you’re using Windows 10, without the Extended Security Updates, you won’t be getting the new certificates through Windows Update. Even if you use Windows 11, you may need a UEFI update from your laptop or motherboard OEM, assuming they still support your device.
For Linux users using Secure Boot, you’re probably covered by fwupd, which will update the certificates as part of your system’s update program, like KDE’s Discover. Of course, you can also use fwupd manually in the terminal, if you’d like. For everyone else not using Secure Boot, none of this will matter and you’re going to be just fine. I honestly doubt there will be much fallout from this updating process, but there’s always bound to be a few people who fall between the cracks.
All we can do is hope whomever is responsible for Secure Boot at Microsoft hasn’t started slopcoding yet.
The benefits of Secure Boot only exist when you control the keys, and then Microslop certs are irrelevant.
Most motherboard do allow control of keys, though.
And many large companies will install their own to the fleet. It is just a bit cumbersome for everyday users.
The problem isn’t that secure boot will stop booting existing installs, but that it will stop booting new installs/updates.
As long as the previous secure boot chain is untouched, then it will keep functioning, but updating to a bootloader that isn’t signed by the expired secure boot key would cause the boot sequences to break. Obviously that would be a problem.
Microsoft can technically sign whatever they want using the old key they control, even though it’s expired. However third parties signing under microsoft’s keys don’t have the same luxury.
If the secure boot keys aren’t updated first (for any reason), then newer operating systems and/or OS updates could end up failing to boot on older computers. Of course, the most practical fix for a user who encounters this is to disable secure boot, as the article states.
Alfman,
This is a chicken and egg problem, usually solved by having two signatures on “transitionary” updates.
And most BIOS vendors have options to install your own keys, disable secureboot altogether, or update them via their own floppy (USB) mechanism.
So those users would be okay… in theory.
The problem would be with embedded devices like old Surface tablets that have been sitting on a shelf for years. When they come back online those transitionary updates might no longer be available, nor the firmware which is controlled by the final OEM, not motherboard BIOS vendor.
sukru,
The solution suggested by the article (barring any unexpected issues) is to have a distro signed by the current/old keys that does nothing but update the keys…
So hypothetically it should always be an option. But the problem is that when secure boot fails, the UEFI BIOS can be completely useless at informing the user what’s wrong. On one of my machines it just fails to boot and the user just has to know what to do. I’ve always been critical of secure boot’s design, not because I’m against secure booting, but because it was designed to put microsoft in control of it. This still bothers me, alternative operating systems shouldn’t be dependent on microsoft and the irony is that attackers have a much better likelihood of being able to boot vulnerable operating systems signed by microsoft than if secure boot actually enforced the owner’s choice of an OS.
Some machines let owners change the keys, but that’s not even part of the secure boot standard. It just wasn’t developed for owner control although it should have been. This is what we got because owners lacked representation at the UEFI round table. You might remember that public outrage forced microsoft to add OEM terms to windows 8 requiring owners to be able to disable secure boot, but the standard itself was never fixed and microsoft OEM terms have since been silently dropped.
I don’t know how common it is, especially since I mostly build my own computers from components that come unlocked, but did have one fujitsu laptop with a locked secure boot. I could only run the linux distros that had been signed by microsoft. It frustrated me greatly.
Alfman,
Yes, but…
As someone interested in computer preservation, that is not very re-assuring. We have to assume those updates will be available 10, 20, 30 years from now.
Though by that time we might have quantum computers, and break all SecureBoot keys, that is another possibility.
I agree. But someone had to be there and assign the keys as a portable standard. The other alternative would be ASUS, Megabyte, MSI, SuperMicro and so on offering their own keys with mismatched compatibility and quality of security practices.
Microsoft just had the “first mover advantage”
(And I’m pretty sure “embedded” devices like Chromebooks have their own separate chain of trust, possibly with Google keys and so on)
Yes, that would be frustrating.
In addition to “is the RAM soldered”, “is the SSD soldered now, WTF?“, “can I replace the battery?” questions, there is now “can I use the UEFI to install my choice of operating system, or is this locked to a single vendor”
Not great at all.
(You of course would be intimately familiar with the ARM situation… which is even greater!)
sukru,
That’s true, but as far as things needing to be preserved, I don’t think this one is particularly onerous. The bigger problem that I’ve already been running into are distros becoming unservicable once repos go offline (at least without great difficulty).
Things that were trivial to do during the support window become extremely tedious even if you can still build/install the software manually. I had a job where I had to support an unsupported centos distro in a network appliance and even though I was able find/build compatible software, the process was not comparable to the original experience at all.
Barring innovation in the preservation of upstream resources, I suspect this will be the future of preservation for modern operating systems (and gaming consoles, etc). These have become increasingly dependent on remote infrastructure to operate normally.
Unfortunately microsoft’s had undo influence over secure boot’s designs, but cryptographically it could have worked different. A notable counterexample is decentralized HTTPS. Secureboot could have empowered the owner/organization of a device to make these choices instead of microsoft. Perhaps used a more neutral authentication party that doesn’t share microsoft’s inherent conflict of interest.
If FOSS & alternative OS advocates had been at the table, I bet we would have gotten a better standard.
Yes, my criticism isn’t limited to microsoft, it’s that owner control of their own hardware takes a back seat. Alas, as is often the case, it’s the 800 pound gorillas that are pushing their own agendas that determine who holds the keys to the products we all buy. The saving grace for secure boot is that most hardware lets you turn it off, but just imagine if that weren’t the case and it became increasingly mandatory. It’s a serious threat to FOSS.
Indeed, which is why we need to stay on our toes whether it be booting restrictions, walled garden restrictions, or hardware that can’t be serviced. The issue for us of course is that if manufacturers convince average consumers to fall in line with these restrictions, unrestricted products become marginalized and eventually niche.
Alfman,
I think that is called TIVO-ism.
Even though that company is long defunct, their legacy lives on.
By hiding their GPL2 Linux behind “locked boot keys”, they managed to divide the community (AGPL/GPL3 and other incompatible licenses). I think this might have even added to CDDL saga at Sun Solaris, but I am not sure they needed more excuses to hate Linux.
Anyway… The genie is already out of the bottle.
And unless we have large manufacturers becoming “benevolent” it is unlikely this will be solved.
(Goverment? Haha… they love this stuff)
sukru,
Plenty of hardware categories are already a lost cause. My hope at this point is that legacy categories like desktop computing don’t become worse. It’s not yet at the point where we’re stuck with no good options. But I don’t trust any of the big three apple & microsoft & google to stand up for long term user empowerment. All three show interest in restricting platforms, but fortunately change has been hard. However might be less willing to fight for openness, especially if they grow up with closed devices.
Electronic despotism it is!
For the benefit of everyone…
My W530 dual boots Win11 (everything works perfectly) and FreeBSD and Lenovo/MSFT do not upgrade the certs or offer updated BIOS with the certs.
I put my W530 in UEFI Setup mode in the BIOS setup, disabled secure boot then followed what is here:
https://wenchy.net/2026/02/how-to-manually-install-the-latest-uefi-secure-boot-certificate-keys-for-windows/
But I changed the script to not apply DBX (not to remove Lenovo’s certs) and modified the UEFI update commands with -Append to keep the original certs in place. All good.
If you fail to do that, Lenovo certs are gone and the system halts with SECURE BOOT ACCESS DENIED. Then just restore the original certs in the BIOS and make sure everything was done correctly.
Less ewaste yay!
(need Win11 for work)
Shiunbird,
Sticking with the original certs will work for existing software. But somewhere down the line you may need to update them for new software. In particular an EFI bootloader that has not been signed by the old certificates will not work. Does anyone know how often MS updates their EFI bootloaders? I don’t really know but I’m guessing it may be win12.