Share via

Secure boot expiring certificates on Azure Trusted Launch VMs

Bas van Hoof 20 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

Answer accepted by question author

  1. Marcin Policht 89,000 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

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jilakara Hemalatha 13,250 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.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Bas van Hoof 20 Reputation points
    2026-05-08T13:45:07.54+00:00

    Latest in is that only the 2 virtual machines are not updated at all, only EventID1801. So we are going to be waiting for these.
    All other servers do have EventID 1808, so my question is answered sofar.

    Was this answer helpful?

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.