Share via

Secure Boot KEK 2023 on AVD multi-session hosts

Mian 0 Reputation points
2026-04-03T05:34:57.9633333+00:00

This is with regard to microsoft announcement to Update to Secure Boot 2023 certificates for Azure Virtual Desktop deployments by June 2026

Issue: Secure Boot KEK 2023 certificate update failing on Azure virtual desktop

trying to update the certificate following the registry method mentioned here: https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Environment: - OS: Windows 11 Enterprise multi-session, Version 25H2, Build 26200.8037 -

Hosted on: Azure Virtual Desktop (Gen 2) - windows 11 Enterprise multi-session host pool

Symptoms: - Event ID 1795, Source: TPM-WMI logged repeatedly in System Event Log - Error: "Access is denied when attempting to update a Secure Boot variable KEK 2023" - FirmwareManufacturer: Microsoft Corporation (Hyper-V UEFI Release v4.1) Message : The system firmware returned an error Access is denied. when attempting to update a Secure Boot variable KEK 2023. This device signature information is included here. -

Registry: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing UEFICA2023Status = InProgress (never completes) - PowerShell check for KEK 2023 cert returns False Looks like this behavior is expected and has been observed on Azure-hosted Gen 2 virtual machines, including Azure Virtual Desktop multi-session hosts as Azure Gen 2 VMs do not allow guest OS–initiated updates to Secure Boot variables (KEK/DB/DBX). Do we have a backend handling plan for this or is Microsoft will be doing the rollout automatically at the backend for us for AVD machines?

Azure Virtual Desktop
Azure Virtual Desktop

A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Himanshu Shekhar 6,335 Reputation points Microsoft External Staff Moderator
    2026-04-03T06:05:46.1133333+00:00

    Mian - This behavior is expected on Azure‑hosted Gen 2 virtual machines, including Azure Virtual Desktop (AVD) Windows 11 Enterprise multi‑session hosts.

    Although the Secure Boot 2023 (KEK/DB) certificate updates can be triggered via registry keys on supported Windows versions, guest OS initiated updates to Secure Boot variables are not permitted on Azure Gen 2 VMs. Secure Boot variables such as KEK, DB, and DBX are owned and enforced by the Hyper‑V UEFI firmware, not the guest OS.

    As a result:

    • Event ID 1795 (TPM‑WMI – Access is denied) is expected
    • UEFICA2023 Status remains In-Progress
    • PowerShell checks for the KEK 2023 certificate return False
    • Manual registry‑based or GPO‑based Secure Boot updates cannot complete on AVD Gen 2 machines

    Microsoft Rollout Plan - For Azure Virtual Desktop, Azure VMs, and Windows 365, Microsoft manages Secure Boot certificate updates at the platform (backend) level.

    The Secure Boot 2023 certificates will be rolled out automatically by Microsoft as part of the Azure virtualization stack before the June 2026 deadline, without requiring customer intervention - https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-04-03T05:35:18.1+00:00

    Azure Gen 2 virtual machines, including Azure Virtual Desktop multi-session hosts, do not support guest OS–initiated updates of Secure Boot variables such as KEK/DB/DBX. This is why the registry-based method leaves UEFICA2023Status stuck at InProgress and logs Event ID 1795 with “Access is denied when attempting to update a Secure Boot variable KEK 2023” from TPM-WMI on Hyper‑V UEFI firmware.

    For Azure Virtual Desktop, the required actions are:

    1. Determine whether Secure Boot is actually active for the affected hosts:
      • Trusted Launch VM with Secure Boot enabled → Secure Boot is active and certificates must be updated.
      • Trusted Launch VM with Secure Boot disabled, Standard security type VM, or Generation 1 VM → Secure Boot is not active or not supported; no action is needed for the Secure Boot 2023 certificates.
    2. For Secure Boot–enabled AVD session hosts and golden images:
      • The guidance is to update the Secure Boot 2023 certificates on the session host or, for Azure Compute Gallery images with Secure Boot enabled, in the source image before capture.
      • Supported IT‑initiated methods are Microsoft Intune, Group Policy, registry keys, or WinCS CLI, but these methods ultimately rely on the underlying firmware allowing Secure Boot variable updates.
    3. For images and hosts where Trusted Launch/Secure Boot is not enabled:
      • Secure Boot certificate updates cannot be applied through the image. Managed images and Azure Compute Gallery images without Trusted Launch fall into this category. For devices provisioned from these images, the update must be applied in the guest OS using one of the IT‑initiated methods.

    The provided documentation does not describe or commit to a separate Azure‑side “backend handling plan” for KEK 2023 on Gen 2 AVD VMs beyond the general statement that most devices will receive the new 2023 Secure Boot certificates automatically and that some systems may require additional firmware updates. It also does not document a special exception or alternative path for KEK updates on Azure Gen 2 VMs where guest‑initiated KEK/DB/DBX updates are blocked.

    From the available guidance, the supported approach for AVD is:

    • Ensure Secure Boot is actually required and enabled (Trusted Launch with Secure Boot). If not, no action is needed.
    • Where Secure Boot is enabled, use one of the documented IT‑initiated deployment methods (Intune, GPO, registry, WinCS CLI) and allow sufficient time and reboots for the update to apply.
    • For Azure Compute Gallery golden images with Secure Boot enabled, apply and verify the Secure Boot 2023 certificate update in the image before capture using the documented registry/WinCS methods and UEFICA2023Status check.

    The documentation does not provide further detail on how KEK 2023 will be applied specifically on Azure Gen 2 AVD multi‑session hosts when firmware blocks guest‑initiated KEK updates, nor does it describe a separate automatic backend rollout specific to that scenario.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    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.