Share via

Secure boot expiring certificates on Azure Trusted Launch VMs

Bas van Hoof 0 Reputation points
2026-05-01T07:52:29.57+00:00

We have several Gen2 Azure VMs(Windows Server 2022) with secure boor/trusted launch enabled and we did a check on certificates for:
Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023, Microsoft UEFI CA 2023 Microsoft Option ROM UEFI CA 2023. On 2 servers it gives false on everything, on the rest only on the last 2.
Do we need to take action or should it be resolved using the regular updates? On all servers we get EventID 1801, is it OK to ignore this(cannot find a clear answer for Azure VMs). Do we need to set the registry key for Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot?

Azure Virtual Machines
Azure Virtual Machines

An Azure service that is used to provision Windows and Linux virtual machines.

0 comments No comments

3 answers

Sort by: Most helpful
  1. Bas van Hoof 0 Reputation points
    2026-05-04T07:20:04.44+00:00

    I did find that 'Microsoft UEFI CA 2023' and 'Microsoft Option ROM UEFI CA 2023' are for thirt-party bootloaders.

    So as I read it we do not have to take action for these ones and can ignore these events, right?

    It is a bit frustrating because we also have a bunch of on-premises Windows servers and we checked the Azure VMs after colleagues mentioned to examine this on Azure.
    Then we are going to monitor the 2 servers that lack the KEK 2023 and Windows EUFI CA 2023 certificates.


  2. Jilakara Hemalatha 12,915 Reputation points Microsoft External Staff Moderator
    2026-05-01T14:21:01.4+00:00

    Hello Bas,

    Thank you for reaching out regarding the Secure Boot certificate status on your Azure Trusted Launch VMs.

    Based on your observations, the behavior you’re seeing (certificate checks returning “false” and Event ID 1801) is generally associated with the Secure Boot certificate update lifecycle. Microsoft has been rolling out updates to Secure Boot components (such as KEK, DB, and UEFI CA certificates), and these updates are delivered through standard Windows Update mechanisms.

    For Azure Gen2 VMs with Trusted Launch enabled, these updates are handled automatically as part of regular OS patching. In most cases, no manual action is required, and I recommend ensuring that all latest Windows updates are applied across your VMs.

    Regarding Event ID 1801, this is typically informational and may appear during certificate evaluation or transition phases. If Secure Boot remains enabled and there are no functional issues with the VM, this event can generally be considered benign.

    At this time, manual changes—such as modifying Secure Boot-related registry keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot—are not required unless specifically directed by Microsoft for a known issue.

    References:

    https://support.microsoft.com/en-us/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15

    https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch

    Hope this helps! Please let me know if you have any queries in comments.

    0 comments No comments

  3. Marcin Policht 88,075 Reputation points MVP Volunteer Moderator
    2026-05-01T11:23:07.3566667+00:00

    AFAIK, the presence of EventID 1801 on Azure Gen2 VMs indicates that the guest operating system lacks the permissions to directly modify the UEFI variables that are managed by the Azure platform infrastructure. Since Azure controls the virtual firmware and the Trusted Launch environment, it is expected for the OS to report a failure when trying to write to these protected keys. You can generally ignore this event as long as the VM continues to boot correctly and the Azure portal confirms that Trusted Launch and Secure Boot are enabled and healthy.

    The discrepancy in certificate status across your servers indicates that the underlying Azure host nodes are at different stages of the rolling update for the 2023 UEFI certificates. The fact that some servers report false for the newer certificates simply means the virtual firmware for those specific instances has not yet been updated with the 2023 KEK or CA. Microsoft is managing this transition globally for Azure infrastructure, so you do not need to take manual action to push these certificates into the UEFI.

    You should not manually set the registry keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot to force an update. In an Azure environment, forcing these updates through the registry can cause conflicts with the platform-managed secure boot process or lead to persistent error logging without actually updating the underlying firmware. Your primary responsibility is to ensure that regular Windows Updates are applied, specifically those related to the Secure Boot DBX (Forbidden Signature List), which allows the OS to recognize and trust the new certificate chain once Azure updates the virtual hardware.

    If you want to verify the current status of Secure Boot on a specific VM via PowerShell, you can use the Confirm-SecureBootUEFI cmdlet to check if it is active regardless of the specific certificate versions.


    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.