Secure Boot certificate changes in 2026: Guidance for RHEL environments | Red Hat Developer

Skip to main content

Search

Search

All Red Hat

Secure Boot certificate changes in 2026: Guidance for RHEL environments

February 4, 2026

Pradeep Jagtap

Related topics:<br>LinuxSecurity

Related products:<br>Red Hat Enterprise Linux

Table of contents:

Microsoft's 2011 Secure Boot signing certificate is scheduled to expire on June 27, 2026. This has raised questions across enterprise Linux environments about system bootability, shim updates, and required actions. First and foremost, the key message is simple: Existing Red Hat Enterprise Linux (RHEL) systems that boot successfully today will continue to boot after June 27, 2026. The certificate expiration affects the ability to sign new boot components, not the ability to boot with already trusted ones.<br>Red Hat will release a new version of shim, signed with multiple signing certificates, for all supported RHEL 8, RHEL 9, and RHEL 10 releases. RHEL 9 and RHEL 10 will receive this new shim in May 2026, and RHEL 8 will receive it in June 2026. Because the new shim is signed with Microsoft's 2011 and 2023 Secure Boot signing certificates, it will boot on all machines that have either or both of those certificates enrolled.<br>Microsoft has started signing Secure Boot components using the 2023 UEFI CA certificate. Following this change, Red Hat is releasing updated shims signed with the 2023 key for supported Red Hat Enterprise Linux releases, beginning with RHEL 9.7, after completing full validation and testing.<br>You probably have lots of questions, though. This article provides comprehensive answers and resources to help.<br>What is UEFI Secure Boot and how does it work?<br>Secure Boot is a UEFI firmware security feature developed by the UEFI Consortium to ensure that only immutable and signed software are loaded during boot time. Secure Boot leverages digital signatures to validate the authenticity, source, and integrity of the code that's loaded. These validation steps are taken to prevent malicious code from being loaded and to prevent attacks, such as the installation of certain types of rootkits.<br>Microsoft acts as a certificate authority, and signs the first stage bootloader (called the "shim") with their private key, and the associated public certificate is enrolled in firmware by hardware vendors. Signing with the 2011 key will no longer be possible after June 2026, so the public certificate needs to be updated in order for shim updates, signed with the new key, to boot.<br>For more information, read What is UEFI Secure Boot and how does it work?<br>What does the 2026 certificate expiration mean for RHEL?<br>Systems with the 2011 Microsoft UEFI CA certificate already enrolled will continue to boot after June 27, 2026. The expiration affects only the ability to sign new binaries, not booting from existing ones. To ensure compatibility, Red Hat will release new shim versions for all supported RHEL 8, RHEL 9, and RHEL 10 releases before the end of June 2026.<br>However, older systems might face issues when a bootloader or shim update is required after the expiration date. This challenge applies to traditional physical servers, older laptops or desktops, systems without vendor firmware updates, and appliances that never receive basic input/output system (BIOS) updates. These machines face risk because they cannot update their Secure Boot db variable.<br>Updates to the UEFI db variable will change Trusted Platform Module (TPM) Platform Configuration Register (PCR) values, particularly PCR7. If you rely on specific PCR values for TPM-based automatic unlocking of LUKS-encrypted volumes, Measured Boot with local or remote attestation, Trusted Boot, or sealing other secrets against this value, note that this value will change.<br>After updating the db variable, do not reboot the system yet. You must first reseal against a PCR value that did not change, such as PCR0. After completing that step, reboot the system, and then reseal against the new PCR7 value. Systems running stable configurations with Secure Boot disabled are not affected by these updates.<br>What are the recommended actions for Red Hat environments?<br>If you manage RHEL deployments, here's what you should do:<br>First, assess the Secure Boot settings on your systems:Review Secure Boot configuration on each system.<br>Confirm the enrolled keys are valid, and verify the installed shim version.<br>Ensure configurations align with your organization's security policies.

Handle UEFI DB updates carefully:Carefully test any updates to the UEFI db variable by using fwupd before you configure automated updates for all machines sharing the same model and firmware version.<br>If fwupd does not offer an update for your hardware, contact your original equipment manufacturer (OEM).

Stay informed on security advisories:Regularly monitor Red Hat errata and security advisories for updates related to shim, Secure Boot, and UEFI.<br>Plan updates and mitigations based on...