Linux Secure Boot 2026: Microsoft certificate expiry

Linux Secure Boot relies on a fragile chain of trust. In 2026, one link in that chain is changing, and sysadmins should understand what’s happening before it becomes a real problem.

Linux Secure Boot and the 2011 Microsoft Certificate Expiry

The certificate in question is called “Microsoft Windows UEFI Driver Publisher”. Issued in 2011, Microsoft has used it ever since to sign the component known as shim, which is the entry point for Secure Boot on the vast majority of Linux distributions.

This certificate expires on June 27, 2026. After that date, Microsoft will no longer use it to sign new components. The new reference key is called UEFI CA 2023.

How the Transition Works

Since October 2025, Microsoft has been signing the shim with both keys simultaneously: the old one (2011) and the new one (UEFI CA 2023). This dual-signing period gives distributions a transition window to ship updates.

After June 2026, only the 2023 key will be used for new signatures. Shims already signed with the 2011 key remain technically valid on systems where they are already installed. A Linux machine that boots today will continue booting after that date, with no immediate action required.

So the risk is not a hard cutoff on the morning of June 27. It’s a deferred, conditional risk that applies to specific scenarios.

Who Is Actually at Risk

For well-maintained environments, the situation is under control. It becomes problematic in clearly identified cases:

Cloud instances created before a certain date (Google Cloud documents November 7, 2025 as the threshold for Compute Engine)
Embedded or OEM systems with Secure Boot enabled but no straightforward update process
Machine fleets that haven’t applied shim updates in several months
Intentionally frozen environments, such as some industrial or legacy infrastructure

In these cases, not having the new shim signed with the 2023 key can cause issues if the UEFI firmware is updated or the machine is reinstalled.

Red Hat’s Response: Fast and Operational

Red Hat is the clearest source on this topic. On June 10, 2026, the company published an updated shim for RHEL 8, 9, and 10 on x86_64, signed with both certificates.

A dedicated article on the customer portal and an explanatory blog post accompany this update. For an administrator managing a RHEL or CentOS Stream fleet, the steps are documented and the fix is available.

Other major distributions such as Ubuntu, Debian, Fedora, and SUSE don’t have equivalent public documentation in the available sources. Their update timelines should be verified directly through their official channels.

What This Means for Other Clouds

Google Cloud has documented the impact precisely and factually. Compute Engine instances created before November 7, 2025 are potentially affected, as Google updated its default certificates on that date.

For AWS and Azure, available sources don’t provide equivalent information. If you manage instances on those platforms with Secure Boot enabled, your best bet is to contact support or monitor their security bulletins.

What to Do Right Now

For an infrastructure lead, the work on this topic comes down to three concrete steps.

First, identify the affected systems: which ones have Secure Boot enabled, which shim is installed, and which key was used to sign it. On RHEL, running mokutil --sb-state combined with a check on the installed shim package already gives you initial visibility.

Next, prioritize at-risk environments: older cloud instances, systems without automatic updates, machines that have been in production for several years without any intervention.

Finally, plan the shim update before the end of June 2026. For RHEL, the fix is available. For other distributions, the priority action is to monitor official bulletins.

Key Takeaways

The Microsoft certificate used to sign the Linux shim expires on June 27, 2026. Systems already running will not break on that date.
The transition to the UEFI CA 2023 key is being managed through a dual-signing period that started in October 2025.
Red Hat has shipped the fix for RHEL 8, 9, and 10. Other distributions don’t yet have equivalent public documentation on record.
The real risk targets frozen environments: older cloud instances, embedded systems, and unmaintained fleets.
The priority action is to inventory your Secure Boot systems and plan their update before the exclusive switch to the 2023 key.

If you manage Linux environments with Secure Boot and want to talk through it, feel free to reach out or follow the blog for upcoming coverage.

Linux Secure Boot 2026: What the Microsoft Certificate Expiry Means for You