Microsoft’s 2011 Secure Boot Certificates Are Expiring — What Linux Users Actually Need to Know
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Microsoft’s 2011 Secure Boot Certificates Are Expiring — What Linux Users Actually Need to Know
The headlines have been alarming. The reality is calmer — but there are still steps worth taking, depending on your setup.
What Is Expiring, and When?
Microsoft issued a family of Secure Boot signing certificates back in 2011. These certificates sit inside your PC’s UEFI firmware and form part of the chain of trust that verifies boot software before the operating system loads. Three of those certificates are now reaching their end-of-life dates:
| Certificate | Expiry Date |
|---|---|
| Microsoft Corporation KEK CA 2011 | June 24, 2026 |
| Microsoft Corporation UEFI CA 2011 | June 27, 2026 |
| Microsoft Windows Production PCA 2011 | October 19, 2026 |
Expiry means Microsoft can no longer sign new boot components using these keys. It does not mean the keys are deleted from your firmware or that previously signed software stops working.
Why Linux Is More Affected Than Windows
On Windows, PC manufacturers pre-install Microsoft’s signing keys and the migration to 2023 certificates is delivered silently through Windows Update. Linux distributions face a structurally different situation.
Because PC firmware does not trust Linux bootloaders directly, most distributions use a small intermediary called Shim — a bootloader that is signed by Microsoft, giving it firmware-level trust before it hands control to GRUB and the Linux kernel. That Shim has historically been signed with the 2011 UEFI CA key. Going forward, new Shim binaries need to be signed with the replacement 2023 key.
The good news: major distributions including Fedora, Ubuntu, and all supported Red Hat Enterprise Linux releases have already released new versions of Shim signed simultaneously with both the 2011 and 2023 keys, maximising compatibility across old and new firmware alike.
What You Actually Lose Without Updating
Leaving things as-is is not consequence-free. Without migrating to the 2023 certificates, systems gradually lose their ability to receive future Secure Boot protections:
- Newer bootloaders signed only with the 2023 key will not be trusted.
- Fresh Linux installations using updated ISO images may fail to boot on firmware that only knows the 2011 certificate.
- Remediation for boot-level vulnerabilities such as the BlackLotus bootkit (CVE-2023-24932) remains permanently incomplete.
- Future revocation list (DBX) updates cannot be applied, leaving known-bad bootloaders trusted indefinitely.
What Linux-Only PC Users Should Do
The steps below are ordered by priority. For most people running an up-to-date distribution, steps 1 and 2 are all that is needed.
Step 1 — Update your system packages
This is the single most important action. Your distribution’s normal update mechanism will pull in the new dual-signed Shim automatically.
sudo apt update && sudo apt upgrade
# Fedora
sudo dnf upgrade
# RHEL / CentOS Stream / AlmaLinux / Rocky
sudo dnf update
# Arch Linux
sudo pacman -Syu
Step 2 — Check what’s already in your firmware
Before doing anything with BIOS or firmware, check whether the 2023 certificate is already enrolled:
# Look for “Microsoft UEFI CA 2023” in the output.
# If it is present, no firmware update is needed.
Step 3 — Try fwupd before touching BIOS
If the 2023 certificate is absent, fwupd can enroll it without a full firmware flash on many machines:
sudo fwupdmgr update
Step 4 — Check for a BIOS/UEFI update (older hardware only)
On older PCs where fwupd cannot push the 2023 certificate, a manufacturer firmware update may be the only path. Visit your PC or motherboard maker’s support page and install any available UEFI/BIOS update. This step is not required for the machine to keep booting — it is only necessary to enroll the 2023 certificate for future-proofing.
Do You Need a BIOS Update?
| Your Situation | Action Needed |
|---|---|
| Existing install, using Linux daily, no reinstall planned | Run distro updates only |
2023 cert already shows in mokutil --list-enrolled |
Nothing extra needed |
| 2023 cert absent, fwupd can deliver it | Run fwupdmgr update |
| Planning a fresh Linux reinstall soon | Enroll 2023 cert first via fwupd or BIOS update |
| Older PC, fwupd unsupported, reinstall planned | Check manufacturer site for BIOS/UEFI update |
What to Avoid
Do not manually delete or modify Secure Boot keys in your UEFI settings unless you have a specific reason and understand the consequences. Removing the 2011 certificate before the 2023 certificate is enrolled will prevent your current system from booting. Incorrect key management is the primary source of real-world boot failures related to this transition.
For Linux-only systems on maintained distributions, this transition is largely handled by routine package updates. The urgency is real only for users planning fresh installs or those running unmaintained older distributions that will not receive a new dual-signed Shim.
