Secure Boot in 2026: Why the Certificates Baked Into Millions of PCs Expire This Year, What a Bootkit Actually Does, and How to Update Firmware Before Trust Runs Out
- Equipo de Internet Pros
- September 19, 2026
- Redes y Seguridad
Este artículo está disponible solo en inglés.
Almost every business PC bought since 2012 contains a handful of digital certificates nobody in the building has ever looked at. They sit in firmware, below the operating system, deciding which code the machine will run before Windows exists. They were issued in 2011 with a fifteen year life, so they run out in 2026. Nothing dramatic happens on the day they expire, which is exactly why the deadline is easy to miss until a fleet of healthy machines has quietly lost the ability to accept new boot security updates.
What Secure Boot Actually Checks
Secure Boot is a feature of UEFI, the firmware that replaced the old BIOS. Its job is narrow: before handing control to a bootloader, the firmware checks that the bootloader carries a valid signature from a key the machine already trusts. Missing or unknown signature, no boot.
The Four Key Stores in Your Firmware
- PK, the Platform Key. The root of trust, owned by the hardware manufacturer. It controls who may change everything below it.
- KEK, the Key Exchange Key. The key permitted to update the allow and deny lists. On most business hardware that includes a Microsoft certificate.
- DB, the allow list. The certificates whose signed bootloaders may run. It is what lets the Windows boot manager, and on many machines a signed Linux shim, start at all.
- DBX, the deny list. Known-bad bootloaders. When a boot component turns out to be exploitable its hash lands here, and the firmware refuses it from then on.
The DBX matters most for ongoing security, and it is the part that stops receiving updates once the key authorised to sign them is no longer valid.
The Deadline Nobody Put on a Calendar
The certificates shipped on the first generation of Secure Boot machines carry expiry dates in 2026. Microsoft published replacements dated 2023, and the industry has spent two years pushing them out through Windows Update and OEM firmware packages. Manufacturers understand the transition well. The businesses who own the hardware mostly do not.
| Certificate in firmware | What it authorises | Replacement |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | Signing updates to the allow list and, critically, the DBX revocation list | Microsoft Corporation KEK CA 2023 |
| Microsoft Corporation UEFI CA 2011 | Third party boot code: Linux shims, hardware option ROMs, many recovery and imaging tools | Microsoft UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | The Windows boot manager itself | Windows UEFI CA 2023 |
Machines that already hold the 2023 certificates carry on unchanged. Machines that do not are more common than most inventories suggest, because a device can be fully patched at the operating system level while its firmware key store has not been touched since the factory.
What Actually Breaks, and What Does Not
It is worth being precise, because the topic attracts unnecessary alarm. An expired certificate does not brick a computer. A machine that boots today will still boot in 2027.
- No new revocations. Once the KEK can no longer sign, the firmware stops accepting DBX updates. The deny list freezes, and every bootkit discovered after that date stays bootable on that machine.
- Newly signed boot code may be refused. Bootloaders and recovery media signed with the 2023 certificates will not validate against a store holding only the 2011 set. That shows up as a recovery USB that will not start, not as a dead installed system.
- Third party boot code gets awkward. Dual boot Linux, storage controller option ROMs and imaging appliances all depend on the third party UEFI CA, and each vendor re-signs on its own schedule.
The failure mode is not an outage. It is a machine that keeps working perfectly while losing the ability to learn about new threats, which is far harder to notice on a dashboard.
Why a Frozen Deny List Is Worth Caring About
Secure Boot exists because of a specific class of malware. A bootkit installs itself into the boot chain so it loads before the operating system, and therefore before any security software. From there it can disable protections, hide processes and survive the remedies most businesses reach for first.
Why Bootkits Are Different From Ordinary Malware
- They survive a full operating system reinstall, because they do not live in the operating system.
- They load before endpoint detection software, so the tool meant to find them is started by the thing it is looking for. Remediation means a firmware re-flash, not a rebuild.
Two examples explain why the DBX keeps growing. BootHole, disclosed in 2020, was a buffer overflow in the widely used GRUB bootloader that let arbitrary code run before the kernel. BlackLotus, sold on criminal forums from 2022, bypassed Secure Boot on fully patched Windows 11 by exploiting an older signed bootloader that was still trusted, tracked as CVE-2023-24932. In both cases the fix had the same shape: revoke the vulnerable component by adding it to every machine deny list. That mechanism is what the 2026 expiry quietly switches off.
How to Check Your Own Fleet
This is a short investigation, not a project. On Windows, an administrator confirms Secure Boot is on with Confirm-SecureBootUEFI in PowerShell, then reads the key stores with Get-SecureBootUEFI db and Get-SecureBootUEFI KEK. A 2023 certificate in those outputs is the answer you want. On Linux, mokutil --sb-state reports the state and mokutil --db lists trusted certificates.
Results usually sort a fleet into three groups: machines that already carry the 2023 certificates, machines from roughly 2012 to 2020 that need a firmware or servicing update to receive them, and a tail of hardware nobody publishes firmware for any more. That third group turns a security task into a budget conversation.
A Sensible Rollout Order
Key store updates touch the lowest layer of a computer, so the usual advice about testing applies with more force.
- Escrow recovery keys first. Boot configuration changes can trigger a BitLocker recovery prompt. Confirm every encrypted device has its key stored centrally before anything starts.
- Pilot one model at a time. Firmware behaviour varies by manufacturer and model, not by operating system version. A clean test on one laptop line proves little about another.
- Apply OEM firmware updates before operating system updates. Many vendors ship the new certificates inside a firmware package, and that order avoids a half-updated key store.
- Keep working recovery media. Rebuild bootable recovery images afterwards and verify they still start on a treated machine.
- Record the exceptions. Machines that cannot be updated are the output of the project, not a failure of it. They belong on a replacement list with a date.
What This Means for a Small Business
A company with thirty computers does not need a firmware governance programme. It needs three things: an inventory recording the age and model of every machine, a habit of applying manufacturer firmware updates and not only Windows updates, and a plan for hardware past vendor support. The 2026 expiry is a useful prompt to check all three.
There is a broader lesson in the timing. Every trust anchor expires, whether it is a Secure Boot certificate with a fifteen year life or a TLS certificate now measured in weeks. Security that rests on a certificate rests equally on somebody noticing when it ends. In 2026 the firmware layer is taking its turn.
If you are unsure what state your firmware is in, or you want the audit done properly across a mixed fleet, talk to Internet Pros. We handle endpoint security, patch management and hardware lifecycle planning for businesses that would rather learn this on a Tuesday than during an incident.
