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 BootCheck whether Secure Boot is enabled:[root@localhost ~]$ mokutil --sb-state