On June 21, 2026, a digital certificate buried deep inside millions of PCs expires, abruptly rendering Linux and other non-Windows operating systems unbootable on affected machines. That certificate—the Microsoft Corporation UEFI CA 2011—has been the root of trust for Secure Boot since Windows 8, and its looming expiration demands immediate action from Linux administrators, hardware vendors, and distribution maintainers.
The Backbone of Secure Boot
Secure Boot is a UEFI firmware feature that ensures only cryptographically signed software runs during the boot process. When enabled, the firmware checks each component—firmware drivers, bootloaders, OS kernels—against a database of allowed signatures. The Microsoft Corporation UEFI CA 2011 certificate is pre-loaded into most PCs as a third-party Certificate Authority (CA). It vouches for the authenticity of bootloaders that Microsoft has signed, including the Linux shim bootloader, which then hands off to GRUB and the kernel.
Without this CA, a Secure Boot–enabled machine refuses to load any bootloader not signed by a key already in its firmware. For the vast majority of dual-boot and Linux-only systems shipped in the last decade, that means the shim—and therefore the entire Linux boot chain—would be rejected.
Why the Certificate Expiration Matters
The 2011 CA was issued with a 15-year lifespan, a common practice for root certificates. Microsoft has already introduced a replacement: the Microsoft UEFI CA 2023, signed by the same root and valid until 2038. New hardware and firmware updates have been shipping with the 2023 CA since around 2022. However, countless older devices—laptops, desktops, servers—still rely solely on the 2011 CA. When it expires, those machines will see Linux bootloaders as untrusted, even if they were previously working.
The expiration does not affect Windows itself because Windows boot components are signed directly by Microsoft’s production CA, not the third-party CA. The impact is squarely on alternative operating systems, including Linux, FreeBSD, and derivative systems that use shim or PreLoader.
Who Is Affected
Linux Distributions: Any distribution that relies on a shim signed by the 2011 CA must ensure their shim is also signed by the 2023 CA—or provide a migration path. Major distributions like Ubuntu, Fedora, openSUSE, and Debian have already begun dual-signing their shims or backporting support. However, older releases and less-maintained spins may lag behind.
Hardware Vendors: Manufacturers must issue firmware updates that include the 2023 CA in the default Secure Boot database. Many have already done so for new models, but the update track record for firmware is notoriously spotty, especially for consumer-grade and legacy enterprise hardware.
System Administrators: IT departments managing fleets of Linux desktops, servers, or embedded devices must audit their hardware inventory, identify machines that lack the 2023 CA, and apply firmware updates before the deadline. This is particularly critical for air-gapped or industrial systems where updates are infrequent.
End Users: Home users running Linux on older hardware may wake up one day to a “Boot Device Not Found” error unless they act. The fix could be as simple as a firmware update—or as complex as manually enrolling a new key.
The Technical Chain of Failure
To understand the risk, let’s walk through the boot process:
- Firmware loads the Secure Boot policy from non-volatile RAM.
- It checks the first-stage bootloader (shim) against the allowed signature database (db).
- If shim is signed by a certificate whose chain roots to a CA in the db, execution proceeds.
- Shim then validates the next stage (GRUB) using its own built-in certificate or the Machine Owner Key (MOK).
- GRUB loads the Linux kernel, which may also be verified if lockdown mode is active.
The 2011 CA resides in the db. Once it expires, any signature created by that CA is invalid, even if the CA’s public key is still physically present in firmware. UEFI specifications mandate that signatures outside the certificate validity period must be rejected. So, even if the shim itself hasn’t changed, the firmware will block it post-June 2026.
Preparing for the Transition
1. Audit Your Hardware
Administrators must determine which machines boot Linux with Secure Boot enabled and which CAs their firmware trusts. On a Linux system, you can check the current EFI signature list:
mokutil --db
Or dump the whole signature database:
efi-readvar -v db
Look for entries labeled “Microsoft Corporation UEFI CA 2011” and “Microsoft UEFI CA 2023”. If the 2023 CA is present, the system is already prepared—provided the running shim has been dual-signed. If only the 2011 CA appears, firmware updates or manual enrollment are required.
2. Update Firmware
Check the OEM support site for BIOS/UEFI updates. Many vendors have released updates that include the 2023 CA. Apply these updates carefully, following the vendor’s instructions. For large deployments, tools like fwupd and LVFS (Linux Vendor Firmware Service) streamline the process.
3. Verify Shim and Bootloader Updates
Ensure the installed shim package is from a distribution that has adopted the dual-signing strategy. Most current shim binaries are now signed by both the 2011 and 2023 CAs. You can verify the signature on a shim binary using:
sbverify --list /boot/efi/EFI/<distro>/shimx64.efi
Or on Debian/Ubuntu:
pesign -S -i /boot/efi/EFI/ubuntu/shimx64.efi
If the output does not list the 2023 CA, update the shim package. Some distributions also provide a standalone “shim-signed” package.
4. Test the Boot Chain Offline
Once updated, reboot and deliberately enter a maintenance mode or use a test machine. Temporarily disable Secure Boot, boot normally to confirm the update hasn’t broken anything, then re-enable Secure Boot and verify the system still starts. For servers, a remote management interface (iDRAC, iLO, BMC) is invaluable to avoid physical visits.
5. Consider MOK as a Fallback
If hardware cannot be updated—for example, a vendor has ceased support—manual enrollment of a Machine Owner Key offers a last resort. Generate a key pair, sign the boot chain with it, and enroll the public key into the MOK list. This bypasses the need for the Microsoft CA but requires disabling Secure Boot temporarily and is feasible only for machines under your physical control.
Distribution-Specific Advice
Ubuntu: Starting with 22.04 LTS, shim-signed has been dual-signed. Older releases (18.04, 20.04) may receive backports—monitor USN notices. Ubuntu’s fwupd integration simplifies firmware updates on many Dell, Lenovo, and HP models.
Fedora: Fedora 36 and later ship shim signed with both CAs. Fedora’s documentation covers the Secure Boot enrollment process and firmware update guidelines.
openSUSE: Tumbleweed and Leap 15.4+ include the updated shim. Use YaST or zypper to keep packages current.
Debian: Debian 11 (Bullseye) and 12 (Bookworm) have backported dual-signed shims. Note that Debian’s default “Secure Boot” support still requires manual intervention on some hardware.
RHEL / CentOS / Rocky: Red Hat began dual-signing shim in RHEL 8.5 and 9.0. Ensure your system is updated to a supported point release and that the shim-x64 package is from a recent errata.
Arch Linux: Arch relies on community-maintained shim-signed packages; verify them against the Arch Secure Boot wiki. Manual key enrollment is common in Arch-based setups.
Potential Pitfalls
- Rolling Back Firmware: Some users may have downgraded firmware or disabled Secure Boot in the past. Re-enabling might expose missing CAs.
- Custom Kernels: If you compile your own kernel, you must sign it yourself and ensure your signing infrastructure uses certificates trusted by the new CA or a MOK.
- Dual-Boot with Windows: Windows may still boot fine after the expiration, but if GRUB is launched from Windows Boot Manager, the path through shim could fail. Test thoroughly.
- Virtual Machines: Hypervisors like VMware and VirtualBox emulate UEFI; their virtual firmware might also need updating to include the 2023 CA. Check vendor documentation.
What If You Do Nothing?
For systems that rely solely on the 2011 CA and cannot boot anything else, the expiration will be a “hard-stop” event. The machine will either drop to a UEFI shell, display a “Security Violation” message, or automatically attempt network boot (PXE). Recovery typically requires disabling Secure Boot from the firmware setup—something many corporate IT policies forbid—or booting from alternate media to enroll a new key. Either scenario means unplanned downtime and emergency desk-side visits.
A Coordinated Industry Effort
Microsoft has published guidance on the third-party CA replacement and is working with OEMs to push the 2023 CA via Windows Update when possible. However, Windows Update cannot directly modify the UEFI secure boot database; it relies on firmware capsule updates from manufacturers. The Linux community has rallied around the shim project, which provides a standardized path for distributions. The UEFI Forum has also clarified the expiration behavior in its specification errata.
Nevertheless, the onus falls on system administrators and end users to verify their own machines are ready. The 2026 deadline may seem distant, but IT planning cycles move slowly, and hardware qualification can take months.
Looking Ahead
Beyond the immediate certificate change, this episode highlights the fragility of certificate-based trust anchors in long-lived embedded systems. Future UEFI secure boot implementations may incorporate multiple overlapping CAs or automatic certificate renewal mechanisms to avoid a repeat. For now, the message is clear: check your UEFI CA database today, update your shim and firmware, and mark June 21, 2026 on your calendar. The countdown has begun.