Update to Secure Boot 2023 certificates for Azure Virtual Desktop deployments by June 2026

Hey Vasil, it looks like your session hosts already see both the 2011 and 2023 certs, but the registry is stuck in “InProgress” and throwing 0x80070005 (access denied) and Event ID 1795. To get those UEFI variables fully updated to the 2023 Secure Boot certificates, here’s what you can do:

1. Confirm your Azure Virtual Desktop session hosts meet the basics • They must be Generation-2 VMs with Secure Boot enabled in the Azure portal (Session hosts > Boot diagnostics > UEFI settings). • They need the latest Windows cumulative updates so that the 2023 certificate update packages are present.

Trigger the UEFI variable update via supported deployment methods Microsoft ships the new 2023 CA certificates as a Windows Update package (for example, KBs in Windows 10 22H2 / Windows 11 cumulative updates). You can deploy and enforce that update by: • Windows Update for Business or WSUS – let the update flow normally. • Microsoft Intune – create a Settings Catalog profile using the “Windows Platform > Secure Boot certificate update” CSP to stage and apply the certificates. • Group Policy – if you’re on-prem, use the corresponding ADMX/ADML for Secure Boot variable updates. • Registry/CSP script – in isolated environments you can set the UEFIVariableUpdate CSP node or write the necessary registry values under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot and then reboot.

Reboot and validate After installation you must reboot the VM. On startup Windows will write the new CA chain into the UEFI DB, DBX and KEK. Once complete, check: • UEFICA2023Status = “Updated” • UEFICA2023Error = 0 • Event IDs 1801/1795 no longer appear And of course ensure WindowsUEFICA2023Capable = 1.

Pilot, then roll out Always start with one or two session hosts to confirm the process works (especially if you’re BitLocker-enabled). Once you see the registry values flip to “Updated” and no BitLocker prompts trigger, roll out to the rest of your pool.

If you run into permission/access-denied errors again (0x80070005), double-check that:

• You’re running the update as a local administrator (or under the SYSTEM context if using Intune/GPO).
• No third-party security software is blocking UEFI variable writes.

Let me know:

• The exact OS build (e.g. Windows 10 22H2 build 19045.xxx or Windows 11 build 22621.xxx)
• How you’re deploying updates today (Intune, WSUS, manual) and I’ll point you to the specific CSP or policy settings to push.

Thanks,
Manish.

Hi Manish,

This is Windows 11 Enterprise multi-session version 10.0.22631. I am deploying updates manually via Windows Update and the session host is up to date.

Vasil

Hi @Vasil Danchev ,

Thanks for the follow-up that OS build detail helps a lot.

A value of 2 means the 2023 certificate is not just present in the UEFI DB — the device is actively booting from it. The boot manager transition on the last reboot completed successfully. So the most critical piece of this update is already done on your session host.

Why you're still seeing InProgress + 0x80070005 + Event ID 1795

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 exactly why the registry-based method leaves UEFICA2023Status stuck at InProgress and logs Event ID 1795 with "Access is denied" from TPM-WMI on Hyper-V UEFI firmware.

In other words this isn't a Windows permissions problem or a missing update. It's a platform-level restriction in how Azure's Hyper-V UEFI firmware works. The guest OS simply cannot write to the KEK slot directly. This is expected behavior on Azure VMs and is a known pattern documented in the Microsoft Q&A community.

What you should actually do

Step 1 — Confirm your VM security type

In the Azure portal, go to Virtual machines → your session host → Configuration → Security type.

• If it's Trusted Launch with Secure Boot enabled → certificates must be updated (you're in this bucket).
• If it's Standard security or Gen 1, or Secure Boot is disabled → no action needed for the 2023 certificates.

Step 2 — Verify the DB certificate is applied (it likely is)

Run this in an elevated PowerShell session on the session host:

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

If this returns True, the 2023 certificate is in the Secure Boot DB and you are protected. Combined with WindowsUEFICA2023Capable = 2, this confirms the key part of the update is complete.

Step 3 — Run Microsoft's Inventory Script

Microsoft provides a Sample Secure Boot Inventory Data Collection script that checks Secure Boot certificate update status — it collects Secure Boot state, UEFI CA 2023 update status, firmware version, and event log activity. Run this across your host pool to get a clear picture. You can find it linked from the AVD-specific support article below.

Step 4 — For golden images / Azure Compute Gallery

For Azure Virtual Desktop environments using Azure Compute Gallery images, apply the Secure Boot 2023 certificate update to the golden image before capturing it, then verify certificates are updated before provisioning new session hosts.

Step 5 — For the KEK update specifically

The documentation does not describe 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. Microsoft is rolling this out at the platform level for Trusted Launch VMs. The InProgress state for KEK on Azure Gen 2 is something you can report via Azure Support if it remains stuck after June 2026, but the UEFICA2023Status being InProgress with WindowsUEFICA2023Capable = 2 is not a critical failure state for AVD.

TL - DR for your environment (Windows 11 Enterprise multi-session 22631, manual Windows Update):

Links for reference :

https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-for-azure-virtual-desktop-06a8a1bc-2510-4ead-9bea-3698e1d6b1db

https://support.microsoft.com/en-us/topic/secure-boot-update-from-2011-to-2023-certificates-trusted-launch-vms-tvm-and-confidential-vms-cvm-845ec199-03fa-4629-bdc3-822ae0bbe6ca

https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d

https://support.microsoft.com/en-us/topic/secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69

Thanks,
Manish