Applies To
Virtual Machine running Linux

Original publish date: June 12, 2026

KB ID: 5103014

Applies to:

Azure Trusted Launch virtual machines and Confidential Virtual Machines running Linux with Secure Boot enabled 

For full list of supported OS for Trusted Launch please see this link: Trusted Launch for Azure VMs - Azure Virtual Machines | Microsoft Learn 

For full list of supported OS for Confidential VMs please see this link: About Azure confidential VMs | Microsoft Learn 

In this article

Introduction

Secure Boot is a UEFI firmware security feature that helps ensure that only trusted, digitally signed software runs during the VM boot sequence. Microsoft Secure Boot certificates issued in 2011 begin expiring in June 2026. 

To maintain Secure Boot protection and continued servicing of the early boot process, Azure Trusted Launch running Linux must be updated with Secure Boot 2023 DB and KEK certificates in virtual UEFI firmware. Confidential Virtual Machines for Linux on Azure with old certificates must be recreated. 

If a VM continues to rely on the 2011 certificates after expiration, it will continue to boot. However, it will no longer receive new security protections in the form of shim updates and future certificates and revocations. Customers with VMs that do not have updated certificates should continue to work with their distro vendors to update their certificates even after the expiry date.

Identify scenarios that require action 

Review the following scenarios to determine whether action is required: 

  • Linux Trusted Launch VMs (TVM) or Confidential VMs (CVM) created prior to April 2024

  • Azure Compute Gallery images captured from older (pre-April 2024) Linux Trusted Launch or Confidential VMs

  • Snapshots or backups of Linux Trusted Launch or Confidential VMs created prior to April 2024

  • Confidential VMs created pre-April 2024 from blobs, imported as secure disk.

Trusted Launch and Confidential Virtual Machines created after April 2024 typically already include Secure Boot 2023 certificates in virtual UEFI firmware.

Note: Linux Confidential VMs created prior to April 2024 should not be manually updated since the Confidential Disk Encryption relies on PCR7 value of the vTPM which is calculated based on the secure boot variables. Updating the secure boot certificates without ensuring FDE key re-sealing will cause the confidential VM to go in recovery mode. It is recommended to recreate such old confidential VMs to get the new certificates.

Azure guest VM considerations 

Secure Boot updates for Linux on Azure VMs involve two components: 

  • Secure Boot certificates in virtual firmware (installed manually via OS provided tooling or automatically via Security updates)

  • Linux shim and bootloader updates (distro vendor managed)

Update operations are initiated from within the guest operating system and rely on platform support to apply authenticated updates to Secure Boot variables. 

After identifying applicable scenarios, inventory your environment to determine which VMs require updates. 

Actions required 

For all Azure guest VMs:

  • Verify whether Secure Boot 2023 certificates are present in virtual UEFI firmware

Verification methods 

Run these commands after the update and reboot. On a successfully updated VM, each command returns a matching line. If a command returns no output, the corresponding 2023 certificate is not present, and the update has not been applied—re-check the update steps before applying. 

Both the DB and the KEK checks must return a line. A successfully updated machine shows the 2023 DB certificate and the 2023 KEK certificate. 

Using mokutil 

  • mokutil --db | grep "UEFI CA 2023"

  • CN = Microsoft UEFI CA 2023

  • mokutil --kek | grep "KEK 2K CA 2023"

  • CN = Microsoft Corporation KEK 2K CA 2023

Using efitools 

  • efi-readvar -v db | grep "UEFI CA 2023"

  • Microsoft UEFI CA 2023

  • efi-readvar -v KEK | grep "KEK 2K CA 2023"

  • Microsoft Corporation KEK 2K CA 2023​​​​​​​​​​​​

Notes: 

  • If `mokutil` is not installed, install it from your distribution's standard repositories, or use `efi-readvar -v db` / `efi-readvar -v KEK` instead.

  • For Confidential VMs, do not run a manual update based on this output—recreate the VM as described in Recommendations by Azure for Confidential VMs.

Linux boot chain update 

After the successful firmware update, it is safe to apply shim updates from the Linux distribution vendors. 

Other Azure resources considerations

Azure resource

Created before April 2024

Action required for TVM

Action required for CVM

Backup/snapshot

Yes

Boot VM, apply updates, recapture

Recreate the CVM, recapture

Backup/snapshot

No

No action needed

No action needed

Compute Gallery image

Yes

Deploy, update, recapture

Recreate the CVM, recapture

Compute Gallery image

No

No action needed

No action needed

Monitor update status 

Verify updates through the guest OS: 

  • Validate successful boot after updates

  • Confirm Secure Boot certificates are present in firmware

Monitoring and validation approaches may vary by Linux distribution, and you should check with your distribution vendor. 

For Trusted Launch VMs:

  • All updates must be applied in the correct order.

    Important: Always update Secure Boot firmware (UEFI variables) before updating shim or bootloader. 

  • It's recommended to restart your VM first to make sure it is running the latest firmware and verify a successful boot.

  • Initiate updates from within the Linux guest VM operating system where required according to your distro vendor’s recommended guidance and tools.

  • If you run into KEK or DB update failures and you did not reboot first, reboot your VM to make sure it is running the latest firmware and try updating the KEK and DB again.

  • Updating the shim before updating the firmware first may result in a boot failure.

For Confidential VMs:

  • Most Confidential VMs have the new certificates already. For Confidential VMs without Secure Boot 2023 certificates present, follow the guidance below in the section, ​​​​​​​Recommendations by Azure for Confidential VMs.

Deploy updates 

Secure Boot certificate updates for Linux on Azure VMs are initiated from within the guest operating system. These updates differ by distro vendors, and customers should check with their distro vendor first on the recommended method.  

Notes: 

  • Only the Linux OS vendors that have published Secure Boot certificate update guidance are listed here. This list is updated as additional vendors publish their guidance.

  • If your distribution's vendor is not listed, it does not mean your VM is unaffected—it means the vendor has not yet published secure boot 2023 KEK and DB update guidance. In that case, contact your distribution vendor for their recommended method, or use one of the manual Alternative firmware update methods described below.

Recommendations from Endorsed Linux OS vendors: 

​​​​​​​​​​Recommendations by Azure for Confidential VMs:

  • The number of CVMs created pre-April 2024 is very low. If your Confidential VM is one of the few that does not have the new certificates, follow steps to recreate the CVM.

Alternative firmware update methods 

Note: Before trying the UEFI variable updates directly on production VMs, customers can utilize the Azure quick start template to simulate the Linux Trusted Launch VM with older 2011 UEFI CA certificates.

Important: The manual firmware update methods in this section are an alternative to, and mutually exclusive with, your distribution vendor's recommended methodology. Use your OS vendor's method whenever one is available first (see Recommendations from Linux OS vendors). Use the manual methods below only when your vendor has not published guidance, or when your vendor explicitly directs you to. Do not apply both the vendor method and a manual method to the same VM.  You only need to use one alternative method for updates (fwupd, efitools, or sbsigntools)—it is not necessary to run all three.  Each Linux distro packages different tools and versions and via different repositories, so it is important to follow the directions provided by your Linux OS.

Note: Tool availability and versions differ by distribution and by tooling source.

Alternative 1: Using fwupd 

Ensure that the VM has fwupd version 2.0.8 or later installed. 

To update both KEK and DB, run these commands with fwupdmgr:

sudo fwupdmgr refresh

sudo fwupdmgr update

Alternative 2: Using efitools 

  • Download DB and KEK update packages for Azure.

    wget https://github.com/microsoft/secureboot_objects/raw/refs/heads/main/\

    PostSignedObjects/Optional/DB/amd64/DBUpdate3P2023.bin

    wget https://github.com/microsoft/secureboot_objects/raw/refs/heads/main/\

    PostSignedObjects/KEK/Microsoft/KEKUpdate_Microsoft_PK1.bin

  • Verify the MD5 or SHA1 of the downloaded binaries—they should match the following exactly:

    sha1sum *.bin

    87cc5bb2efe9b59c6ad9f717a78e190bf1a191e8 DBUpdate3P2023.bin

    d9a2fa28017653c26afc3d1b5c001adae9dc16a6 KEKUpdate_Microsoft_PK1.bin

    md5sum *.bin

    ef9fd1874610c2077f4c2476661ea4cd DBUpdate3P2023.bin

    5e67b7beafac7801fd920e40e3592611 KEKUpdate_Microsoft_PK1.bin

  • ​​​​​​​Use efi-updatevar to install the update packages

    sudo efi-updatevar -a -f DBUpdate3P2023.bin db

    sudo efi-updatevar -a -f KEKUpdate_Microsoft_PK1.bin KEK

    sudo reboot

Alternative 3: Using sbsigntools 

  • Download and verify DBUpdate3P2023.bin and KEKUpdate_Microsoft_PK1.bin as described in “Alternative 2: Using efitools” above.

  • ​​​​​​​Use sbkeysync utility of sbsigntools to install the update packages:

    sudo mkdir -p /etc/secureboot/keys/db

    sudo cp DBUpdate3P2023.bin /etc/secureboot/keys/db

    sudo mkdir -p /etc/secureboot/keys/KEK

    sudo cp KEKUpdate_Microsoft_PK1.bin /etc/secureboot/keys/KEK

    sudo chattr -i /sys/firmware/efi/efivars/db-*

    sudo chattr -i /sys/firmware/efi/efivars/KEK-*

    sudo sbkeysync --verbose

    sudo chattr +i /sys/firmware/efi/efivars/db-*

    sudo chattr +i /sys/firmware/efi/efivars/KEK-*

    sudo reboot

Mitigation steps in case of boot failures 

In case of a failure scenario such as boot failure after UEFI variable update, you can reset the UEFI settings using one of the below methods: 

  1. Restore the backup taken before starting the manual update process.

  2. Convert Trusted Launch VM to Standard VM and re-apply Trusted Launch security type on the VM. (More details here: Enable Trusted launch on existing Gen2 VMs - Azure Virtual Machines | Microsoft Learn)

  3. Export the OS vhd to a storage account, create a gallery image from the vhd and deploy the VM using gallery image version.

​​​​​​​​​​​​​​Third-party information disclaimer

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. We make no warranty, implied or otherwise, about the performance or reliability of these products.

We provide third-party contact information to help you find technical support. This contact information may change without notice. We do not guarantee the accuracy of this third-party contact information.

Change log

Change date

Change description

July 29, 2026

Major revisions to add clarity to required actions, and alternative firmware update methods.

June 18, 2026

Reference links were added to the section, "Recommendations from Linux OS vendors".

Facebook LinkedIn Email
SUBSCRIBE RSS FEEDS

Need more help?

Want more options?

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Microsoft 365 subscription benefits

Microsoft 365 training

Microsoft security

Accessibility center