Secure Boot certificate changes in 2026: Guidance for RHEL environments

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.

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.

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.

You probably have lots of questions, though. This article provides comprehensive answers and resources to help.

What is UEFI Secure Boot and how does it work?

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.

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.

For more information, read What is UEFI Secure Boot and how does it work?

What does the 2026 certificate expiration mean for RHEL?

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.

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.

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.

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.

What are the recommended actions for Red Hat environments?

If you manage RHEL deployments, here's what you should do:

1. First, assess the Secure Boot settings on your systems:
   1. Review Secure Boot configuration on each system.
   2. Confirm the enrolled keys are valid, and verify the installed shim version.
   3. Ensure configurations align with your organization's security policies.
2. Handle UEFI DB updates carefully:
   1. 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.
   2. If fwupd does not offer an update for your hardware, contact your original equipment manufacturer (OEM).
3. Stay informed on security advisories:
   1. Regularly monitor Red Hat errata and security advisories for updates related to shim, Secure Boot, and UEFI.
   2. Plan updates and mitigations based on the advisories to avoid unplanned downtime.

How can I determine whether Secure Boot is enabled on my systems?

You can verify the status of Secure Boot using the mokutil command:

$ sudo mokutil --sb-state

The output states whether Secure Boot is enabled or disabled. For example, on a system with Secure Boot enabled:

$ sudo mokutil --sb-state
SecureBoot enabled

For more information, read the How to check if Secure Boot is enabled on your systems? article.

How can I determine which Secure Boot certificates are enrolled?

You can use mokutil to list enrolled keys:

$ sudo mokutil --db
62b51ed2e6 ASUSTeK Notebook SW Key Certificate
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
b5eeb4a670 Microsoft UEFI CA 2023
45a0fa3260 Windows UEFI CA 2023

How do I update my firmware using LVFS?

Enable and use Linux vendor firmware service (LVFS) to ensure that the latest vendor-provided firmware is installed:

$ sudo fwupdmgr update

Firmware is provided by hardware vendors, not by Red Hat. For more information, read How do I update my firmware using LVFS?.

Can I update the UEFI Secure Boot DB directly and without a full firmware update?

Not always. Certain platforms, including HP and Fujitsu, block standalone DB updates because of boot failures observed after an update. Hardware from these vendors requires a firmware update before you can safely deploy the DB and KEK updates. Contact your hardware vendor to determine if your firmware version supports KEK and DB updates.

Do not force install DB updates. Always follow vendor guidance.

Should I install the 2023 UEFI db update now?

Yes, if an update is available through the fwupd utility. Always test the update in a staging or non-production environment before deploying it to production.

How does this apply to virtual machines using OVMF?

Virtual environments rely on the edk2-ovmf package to provide both the UEFI firmware and the NVRAM template when a new VM is created. This means the certificate set inside edk2-ovmf becomes the baseline for Secure Boot in any new virtual machine (VM) deployment.

To ensure that a new VM starts with the updated Microsoft 2023 Secure Boot certificates, update the edk2-ovmf package on the hypervisor or host system.

If edk2-ovmf is outdated, then newly created VMs would inherit older certificate bundles. These VMs may later hit Secure Boot validation issues when newer shims are released.

The packages that include the new certificates are:

• RHEL 10: edk2-ovmf-20241117-2.el10.noarch and later
• RHEL 9: edk2-ovmf-20231122-6.el9.noarch and later
• RHEL 8: Not applicable

The newer edk2-ovmf builds include both the 2011 and 2023 Microsoft Secure Boot certificates. This ensures compatibility with shims signed by either key, so you can safely update to these versions immediately.

After the update, any new VM created with OVMF firmware will start with the correct certificate set.

How to check which certificate was used for signing shim

You can check the shim signature by using the pesign command. This tool is available in the pesign RHEL package. The following example shows how to do this on RHEL 9.7:

# dnf -y install pesign
[...]
# pesign -S -i /boot/efi/EFI/redhat/shimx64.efi
---------------------------------------------
certificate address is 0x7fbe099b27b8
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.
---------------------------------------------

Alternatively, you can check the signature of shim by using the sbverify command available in the sbsigntools Extra Packages for Enterprise Linux (EPEL) package (which is not supported by Red Hat), as shown in the following RHEL 9.7 example:

# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
[...]
# dnf install sbsigntools
[...]
# sbverify --list /boot/efi/EFI/redhat/shimx64.efi 
warning: data remaining[906736 vs 1035680]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

As of March 25, 2026, all Shim binaries are signed with a Microsoft 2011 certificate. However, on RHEL 9.7 for aarch64, the binary is signed with a Microsoft 2023 certificate. In the near future, all Shim binaries for RHEL 8, 9 and 10 will be signed with both Microsoft 2011 and 2023 certificates.

How to update the NVRAM of a VM that is already running on RHEL 9 and later

1. Update the edk2-ovmf package on the host to the latest version. That version must include the new certificates:

   # dnf install edk2-ovmf-YYYYMMDD-.noarch

2. Stop the VM:

   # virsh shutdown <vm>

3. Reset the NVRAM:

   # virsh start <vm> --reset-nvram

How to update the NVRAM of a VM that is already running on RHEL 8

1. Update the edk2-ovmf package on the host to the latest version:

   # dnf install edk2-ovmf-YYYYMMDD-.noarch

2. Stop the VM:

   # virsh shutdown <vm>

3. Check the NVRAM storage location for the target VM:

   # virsh dumpxml <vm> | grep nvram
   <nvram>/var/lib/libvirt/qemu/nvram/<vm>.fd</nvram>

4. Back up the NVRAM:

   # cp /var/lib/libvirt/qemu/nvram/<vm>.fd /path/to/...

5. Remove the NVRAM:

   # rm /var/lib/libvirt/qemu/nvram/<vm>.fd

6. Start the VM:

   # virsh start <vm>

Summary

Secure Boot certificate expiration in 2026 does not break existing systems. Red Hat provides shims signed with the 2023 certificate for supported RHEL releases. Secure Boot DB and firmware updates remain controlled by the vendor. For virtual environments, you must ensure that edk2-ovmf is current for new VM deployments.

For the latest updates, refer to the Red Hat Knowledgebase article Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments.

The best way to manage your UEFI updates is through awareness, vendor alignment, and avoiding unnecessary manual intervention. This article has provided you with a head start.