Expiration of Secure Boot signing certificates in 2026

The keys that Microsoft uses to sign for Secure Boot are expiring at the end of June 2026. Here is what you need to know:

• Secure Boot-enabled systems will continue to boot after June 2026 whether they are immediately updated or not.
• Red Hat has released new shims, signed by multiple certificates, for all supported RHEL 9 and RHEL 10 streams; RHEL 8 will receive the new shim in June 2026.
• To prepare your systems for the future, it’s best to update your firmware database, if an update is available, and update your shim.

What is Secure Boot?

UEFI Secure Boot is a security feature that permits only signed, trusted components to boot on your system. This means the bootloader(s) that start the machine and load the kernel—the kernel itself—which is the heart of the operating system (OS), and the kernel modules are signed. Allowing only trusted components to load prevents malicious bootkits or rootkits from getting installed.

UEFI Secure Boot is only available on x86_64 machines running UEFI firmware and aarch64 machines. Importantly, the information in this article is relevant only to x86_64. Red Hat-enabled Secure Boot on aarch64 quite recently, and the aarch64 shim is signed with the 2023 key only.

How does Secure Boot work?

Key pairs are generated using cryptographic algorithms. One half of the key pair is the private key, which is kept secret and used to sign applications. The other half of the pair is the public certificate, which is used to verify a signed application. Because the private key and public certificate have different values and purposes, the public certificate can be made available to anyone wishing to run the signed application without compromising its security. The private key, on the other hand, is stored securely and only used by authorized persons. This is the essence of asymmetric cryptography.

The Secure Boot root of trust starts in a device’s firmware. Device manufacturers enroll known public certificates in their firmware Secure Boot database (db). When customers install Red Hat Enterprise Linux (RHEL), a small first-stage bootloader, called the shim, launches because it is signed by a corresponding private key. The shim verifies the next applications and only allows them to run if they are also properly signed.

Embedded in our shim are one or more public certificates specific to RHEL, which allow the next stages to boot: the GRUB bootloader, the kernel, a Unified Kernel Image (UKI), etc. If any component in the chain is not signed correctly, the boot process will not continue.

Thus Secure Boot is a chain of trust in which the presence of public certificates allows the loading of programs signed by the corresponding private keys. As long as the public certificate is available, a program signed by its private key will be loaded.

How is Microsoft involved in this?

Microsoft acts as a signing authority, and signs the shim for each eligible and trusted company or entity, once it has gone through a public security review. This allows installation of any OS on any given device, and for dual-booting. It also ensures a common security standard across the Linux ecosystem.

What is happening in June 2026?

Every certificate has a period during which it can be used for signing, which is set when the key pair is created. Microsoft’s original certificate (Microsoft Windows UEFI Driver Publisher) from 2011 will expire in June 2026, which means they will no longer be able to sign with it. Very importantly, a shim signed by this key will continue to boot as long as the public certificate is not removed from or revoked by the system. Likewise, new installations using this shim will continue to be possible as long as the public certificate is enrolled in the firmware on the system being installed. 

Starting in October 2025, Microsoft began signing shim with 2 different keys: the Microsoft Windows UEFI Driver Publisher (2011) and the Microsoft UEFI CA 2023 signer (2023). After June, they will only be able to sign with the 2023 key.

Aside from Linux shim bootloaders, Microsoft also signed option ROMs with the 2011 key. As a result, there are no plans by hardware manufacturers to remove or revoke the 2011 certificate in the near future.

What is Red Hat doing in response to the situation?

Red Hat has released new versions of shim, signed by both the 2011 and 2023 keys, starting with RHEL 9.8 and RHEL 10.2. All supported RHEL 9 and RHEL 10 z-streams have also received the dual-signed shim. Supported RHEL 8 z-streams will receive the dual-signed shim update in June 2026. Based on our testing, this is the safest path forward for bare metal as well as virtual machines (VMs). As long as either of the Microsoft certificates is present in the firmware db, the machine will boot.

For bare-metal machines, fwupd can be used to safely update your Secure Boot firmware db. Please see How to update device firmware using fwupd on RHEL system? for information on how to do this.

For VMs, virtual firmware has been updated to include both the 2011 and 2023 certificates. Please see Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments.

What about RHEL 7.9?

RHEL 7.9, the first to support Secure Boot, will not receive a dual-signed shim. If a new shim will be needed in the future due to critical or important CVE fixes, the fixes will also be backported to RHEL 7.9, if it’s still supported at that time. That shim will only be signed by the 2023 key, and thus will only be bootable if that certificate is enrolled in the firmware db.

What will happen when a new version of shim is needed?

After June 2026, new versions of shim will only be signed by the 2023 key. Any important or critical CVEs discovered in shim will be fixed and backported to all supported streams, as expected, but the shim will only be installed if the system’s firmware db has been updated to include the 2023 certificate. A new utility, sbchooser, a part of the efivar package, will ensure that an incompatible shim is not installed.

At that time, systems that do not or cannot update their db to include the 2023 certificate, will either have to continue using the vulnerable shim or disable Secure Boot. Red Hat will advise which scenario is preferable for different use cases.

Should I update my firmware db?

Yes. If you do not update your db now, the current and new dual-signed shims will continue to boot on your machine. A future shim, however, signed only by the 2023 key, will not boot because the 2023 certificate will not be present. Since we cannot know when new vulnerabilities will be found in shim (or any other software), it’s best to be prepared for whatever is coming.

Importantly, do not remove or revoke the 2011 certificate even after updating to the 2023 certificate. The dual-signed shim will not boot if one of the keys used to sign it has been revoked (put into the dbx, please see below). Likewise, option ROMs signed by the 2011 key will not execute, and thus associated hardware will not function properly.

How do I update my firmware db?

Please take a look at Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments for more information, including how to perform db updates using fwupd and how to update virtual firmware.

Are there any risks associated with updating the firmware db?

If you are relying on values of particular Trusted Platform Module (TPM) Platform Configuration Registers (PCRs) for TPM-based automatic unlocking of LUKS-encrypted volumes or Measured Boot with local or remote attestation, please be aware that PCR values will change. In particular, PCR7 will change after the db update. You’ll need to update your settings after updating the db and before rebooting: seal to a PCR that you know will not change or disable sealing against PCRs prior to rebooting, and then reseal or re-enable post reboot.

Additionally, certain HP and Fujitsu hardware cannot currently receive db updates. If there is no db update available for your hardware, please contact the hardware vendor. db updates originate from hardware vendors and not from Red Hat.

Helpful commands related to Secure Boot

Check whether Secure Boot is enabled:

[root@localhost ~]$ mokutil --sb-state
SecureBoot enabled

Check which keys are in the firmware db (you can replace db with dbx, kek, pk):

[root@localhost ~]$ mokutil --db --short
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

Check which keys the shim is signed with (you can replace shimx64.efi with grubx64.efi or the path to the kernel):

[root@localhost ~]$ sudo pesign -S -i /boot/efi/EFI/redhat/shimx64.efi 
---------------------------------------------
certificate address is 0x7f77cabde410 ← Microsoft 2011 certificate
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
certificate address is 0x7f77cabe0a08 ← Microsoft 2023 certificate
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft UEFI CA 2023 signer   
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
certificate address is 0x7f77cabe2f28 ← Red Hat 2024 certificate
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Red Hat UEFI Publisher 2024
The signer's email address is secalert@redhat.com
Signing time: Mon Feb 09, 2026
There were certs or crls included.
---------------------------------------------

More information about Secure Boot

There are 2 other important Secure Boot key / certificate pairs, as well as another database, that enable Secure Boot to function. As already mentioned, the Secure Boot firmware database or db contains trusted public certificates and applications signed by the corresponding keys are allowed to boot. Additionally, there is a forbidden database, the dbx, that contains untrusted and revoked certificates and hashes of particular programs (binaries) that are not allowed to boot. If an application is signed with one key that is allowed (in db) and another key that is forbidden (in dbx), the application will not be allowed to boot.

Additionally, there is the Key Exchange Key (KEK) and the Platform Key (PK). The KEK is used to sign db and dbx updates; this ensures that only trusted updates occur. A machine may have more than one KEK. Finally, the PK is like the master controller for Secure Boot. The PK is used to sign KEK updates, and if it is removed from a machine, Secure Boot will be disabled automatically. There can only be one PK on a given machine.

UEFI hardware ships with all of these keys already on the machine. Likewise, virtual firmware on VMs contains all of these keys in nvram (non-volatile RAM), making it possible to install and launch machines with Secure Boot enabled from the beginning.