No, your Secure Boot certificate is not expiring in June

If you manage Linux infrastructure with Secure Boot enabled, you have probably seen the headlines. The Microsoft UEFI CA certificate that underpins Secure Boot signing for Linux has a June 2026 expiry date, and compliance scanners and advisories are treating it like a deadline.

It is not. Here is what is actually happening.

What is really going on with the Microsoft UEFI CA certificate

Microsoft is performing a deliberate key rotation. They are issuing a new UEFI CA certificate and transitioning all future shim signing to that key. The June 2026 date marks when Microsoft will stop signing new shims with the old certificate.

Secure Boot firmware does not check certificate expiration dates. The firmware has no reliable way to verify the hardware clock at boot time, so expiration dates on signing certificates are not validated during the Secure Boot process. A shim signed with the old certificate will continue to pass Secure Boot validation indefinitely.

Nothing breaks on any existing system because of this transition. Do not attempt to manually update or replace Secure Boot certificates. Modifying the UEFI Signature Database or MOK without following a validated procedure can leave a system unable to boot.

That said, customers and compliance programs that flag expired or rotating certificates as a policy matter are not wrong to do so. Having a security posture that prohibits expired signing certificates is a reasonable position, even when the technical risk is zero. The distinction matters, though: this is a compliance and supply chain planning issue, not a systems failure event.

Cloud VMs provisioned before the rotation may need action

The impact is forward-looking. After the rotation date, any new shim signed by Microsoft will use the new certificate. That includes CIQ. If we build a new shim for a security fix, a new Rocky Linux release, or any other reason, it will be signed with the new key.

This becomes a problem when a system's UEFI Signature Database contains only the old certificate and cannot be updated. A new shim signed with the new key will not load on that system.

In practice, this is most likely with cloud VMs launched before the transition. Major cloud providers have indicated that the UEFI database is fixed at VM creation time. New VMs are expected to include both certificates, but existing ones will not.

On bare metal, the situation is more flexible. Firmware updates can change the set of trusted certificates, and most hardware vendors are expected to ship both the old and new certificates going forward.

This is an infrastructure planning issue, not an emergency. But it is one that every organization running Secure Boot with Linux needs to account for in their firmware lifecycle and deployment workflows.

There is one scenario that requires careful, immediate attention. If your environment uses TPM-backed disk encryption (LUKS with TPM unsealing, or FSCrypt), a shim change alters the boot measurements the TPM relies on. If those measurements change, the system cannot decrypt its own disk. If this applies to you, see the section below on what to do.

Learn more about RLC Pro | Download the RLC Pro solution brief

CIQ ships two shims so the right one loads automatically

The UEFI specification and the PE/COFF binary format both support embedding multiple Authenticode signatures in a single binary. A shim carrying both the old and new Microsoft certificates can boot on any system that trusts either key. Other Linux distributions have validated this approach across a wide range of modern firmware, and CIQ's primary plan is to ship a dual-signed shim for Rocky Linux and RLC that works the same way.

That said, CIQ's customer base spans a decade of server hardware, cloud VM firmware vintages, and on-premises deployments. Some older UEFI firmware implementations are known to inspect only the first signature in a binary rather than iterating through all of them.

If testing surfaces firmware compatibility issues, CIQ has a fallback ready: two separate shim binaries (one signed with each certificate) paired with a selection utility that queries the UEFI Signature Database at install time and places the correct shim in the EFI boot path. The utility runs automatically during install or upgrade and can be run manually after firmware changes, so the correct shim loads regardless of how the firmware handles multi-signature binaries.

What you need to do (for most customers, nothing)

If you are running an existing system and not changing firmware, no action is required. Your system will continue to boot normally.

When CIQ releases the updated shim packages, the transition will be handled automatically during install or upgrade.

If you are performing firmware updates on bare metal, CIQ recommends disabling Secure Boot before the update, applying the firmware update, and re-enabling Secure Boot afterward. Detailed guidance will be published alongside the updated shim packages.

If you are launching new cloud VMs after the rotation, and the provider's images include both certificates, the updated shim packages will handle certificate detection automatically. No manual steps are needed.

If you use TPM-backed disk encryption, contact CIQ support before making any changes. A shim change will alter the boot measurements the TPM uses to decide whether to release the disk encryption key. If those measurements change, the system will be unable to decrypt its own disk. This configuration is not common in typical deployments, but it is actively used by customers in cloud environments with advanced security requirements and in regulated and defense-sector industries. A specific migration procedure is required.