Share via

Secure Boot certificate update requirements for Azure VMs and Azure Virtual Desktop (AVD) – responsibility and automation options

SMT 0 Reputation points
2026-05-18T21:12:58.56+00:00

Hi team,

We are currently reviewing the Secure Boot certificate expiration (June 2026) guidance and its impact on our Azure environment, particularly for:

  • Azure Virtual Machines (Gen2 / Trusted Launch/any)
  • Azure Virtual Desktop (AVD) session hosts

From the available documentation and AMA sessions, it appears that:

  • Secure Boot updates apply to both physical devices and virtual machines (including Azure VMs)
  • For existing VMs, updates may need to be applied from within the guest OS (e.g., via Windows Update, Intune, or other management tools)
  • Azure platform updates may only apply to newly created VMs, not existing ones

✅ Our questions:

  1. Responsibility clarification
    • For Azure VMs and AVD session hosts with Secure Boot enabled: 
           - Is the customer fully responsible for ensuring Secure Boot certificate updates are applied?
     
     
           - Does Azure automatically update Secure Boot certificates in any scenarios (e.g., Trusted Launch VMs)?
     ```- Many users in this forum are facing issues when trying to update the cert manually, so should this be done manually or through Windows Updates ? If Windows update can you please let me know which update KB resolves this as we have customers who are selective about the updates being installed on the VM.
  1. AVD-specific scenario
    • For Azure Virtual Desktop: 
           - Do AVD session hosts require the same manual/OS-level updates?
     
     
           - Is there any integration with the AVD service to help manage or monitor Secure Boot certificate compliance?
     ```---
  2. Automation / scale
    • What is the recommended approach to update Secure Boot certificates at scale for: 
           - Large VM estates
     
     
           - AVD environments with multiple session hosts
     
           
              - Are there any Azure-native solutions (Azure Update Manager, Defender for Cloud, etc.) that can help track or enforce this?
     ```---
  3. Detection / monitoring
    • How can we reliably inventory Azure VMs and AVD hosts that: 
           - Require Secure Boot certificate updates
     
     
           - Have not yet been updated
     
           
              - Is there any built-in reporting in Azure or Defender for Cloud?
     ```---
  4. Impact
    • If Secure Boot certificates are not updated before expiry: 
           - What is the expected impact on Azure VMs and AVD session hosts?
     
     
           - Will workloads continue functioning, or only lose future protection updates?
     ```---

We are trying to build a remediation strategy for our environment and would appreciate guidance specific to Azure VMs and AVD.

Thanks in advance!

Azure Virtual Machines
Azure Virtual Machines

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

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Nikhil Duserla 9,940 Reputation points Microsoft External Staff Moderator
    2026-06-01T09:10:07.59+00:00

    Hey there! It looks like you’re putting together a plan for the June 2026 Secure Boot certificate rollover—here’s a concise rundown based on our docs and community guidance:

    1. Responsibility & Update Mechanism • You (the customer) are fully responsible for applying the new 2023 Secure Boot certificates on both Azure Gen2/Trusted Launch VMs and AVD session hosts. Azure only auto-updates a small subset of “high-confidence” devices; all others need a guest-OS update. • The fix is bundled in the March 10, 2026 monthly cumulative update (April 14, 2026 CU for Windows Server 2025). There’s no standalone KB—just grab your normal CU. • After patching, verify success by checking for Event ID 1801/1808 in the System log or the UEFICA2023Status registry key.
    2. AVD Session Hosts • AVD hosts behave exactly like any Gen2 Azure VM with Secure Boot enabled: install the March/April CU inside the guest OS via Windows Update, Intune, WSUS or GPO. • There’s no built-in AVD service integration for rolling these certs—you’ll manage it through your existing patch pipeline.
    3. Automation & Scale • Microsoft Intune “Settings Catalog” has a Secure Boot certificate update CSP you can target to device groups and control rings. • For on-prem-joined or WSUS environments, use Windows Update for Business / WSUS deployment rings or Group Policy. • If you run large Windows Server estates, check out the “Secure-Boot-Update” scheduled-task playbook from Tech Community for scripted scale-out. • Azure native tools: Defender for Cloud can report on compliance, but there’s no turnkey Update Manager integration specifically for these certs today.
    4. Detection & Monitoring • Use PowerShell or Log Analytics to scan the System event log for Event IDs 1800, 1801, 1808, or query the UEFICA2023Status registry key remotely. • Windows Security app under Device Security > Secure Boot also indicates certificate state per host. • Consider an Intune remediation script or a custom Azure Policy/Defender for Cloud initiative to flag non-compliant machines.
    5. Impact if You Miss the Deadline • Your VMs will keep booting and running normally; you won’t be cut off immediately. • However, after June 2026 you’ll no longer receive Secure Boot or Boot Manager security updates—leaving you vulnerable to boot-level threats (e.g., BlackLotus).

    Reference Links

    1. Known issues & resolutions for Secure Boot cert updates: https://support.microsoft.com/topic/known-issues-and-resolutions-for-secure-boot-certificates-updates-5813673d-2577-4718-ad28-2554a9178e40
    2. Secure Boot Certificate Updates for Azure Virtual Desktop: https://support.microsoft.com/topic/secure-boot-certificate-updates-for-azure-virtual-desktop-06a8a1bc-2510-4ead-9bea-3698e1d6b1db
    3. Secure Boot playbook for certs expiring in 2026: https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789
    4. Secure Boot update from 2011→2023 for Trusted Launch VMs: https://support.microsoft.com/topic/secure-boot-update-from-2011-to-2023-certificates-trusted-launch-vms-tvm-and-confidential-vms-cvm-845ec199-03fa-4629-bdc3-822ae0bbe6ca

    Hope this helps you build out your remediation strategy—feel free to ping me if you need more details or run into any specific errors!

    Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-05-18T21:13:20.7233333+00:00
    1. Responsibility for Azure VMs and AVD session hosts

    For Secure Boot–enabled Azure VMs and Azure Virtual Desktop (AVD) session hosts, responsibility for applying the 2023 Secure Boot certificates lies with the organization managing the guest OS.

    For Azure Virtual Desktop specifically, the guidance states that:

    • All Secure Boot–enabled VMs registered in the Azure Virtual Desktop service, and custom images used to provision them, must be updated to the 2023 certificates before expiration to remain protected.
    • Action is required on:
      • Trusted Launch VMs with Secure Boot enabled (session hosts)
      • Azure Compute Gallery images with Secure Boot enabled (golden images)

    Azure does not automatically remediate all existing Secure Boot–enabled VMs. Automatic deployment is provided via Windows Update for “high-confidence devices,” but this is still a guest OS–level mechanism, not a platform-side Azure VM reconfiguration.

    For non–Secure Boot scenarios (Standard security type VMs, Generation 1 VMs, Trusted Launch with Secure Boot disabled), no action is needed.

    1. AVD-specific behavior and integration

    The same Secure Boot certificate requirements apply to AVD session hosts as to any other Secure Boot–enabled Windows VM:

    • Trusted Launch VM with Secure Boot enabled: update certificates on the session host.
    • Trusted Launch VM with Secure Boot disabled: no action needed.
    • Standard security type VM or Gen1 VM: no action needed.

    For golden images used by AVD:

    • Azure Compute Gallery image with Secure Boot enabled: update certificates in the source image before capturing.
    • Azure Compute Gallery image without Trusted Launch, or managed images (no Trusted Launch support): certificates cannot be updated through the image; updates must be applied in the guest OS after deployment.

    The provided guidance is AVD-aware (session hosts and golden images), but there is no additional AVD control plane feature described that automatically manages or monitors Secure Boot certificate compliance beyond what is done in the guest OS.

    1. Automation and scale options

    Two main deployment approaches are described:

    • Option 1: Automatic updates from Windows Update (high-confidence devices)
      • Enabled by default for devices that qualify.
      • No action required unless opting out.
      • Opt-out is controlled via:
        • Registry: HKEY_LOCAL_MACHINE:\SYSTEM\CurrentControlSet\Control\SecureBoot → HighConfidenceOptOut = 1 to opt out.
        • Group Policy: Computer Configuration > Administrative Templates > Windows Components > Secure Boot > Automatic Certificate Deployment via Updates → set to Disabled to opt out.
      • Recommendation: even with automatic updates, monitor session hosts to verify certificates are applied, because not all devices qualify.
    • Option 2: IT-initiated deployment (for immediate/controlled rollout)
      • Supported methods (all guest OS–level):
        • Microsoft Intune
        • Group Policy Objects (GPO)
        • Registry keys
        • WinCS CLI / APIs
      • Only one IT-initiated method should be used per device, because they control the same registry keys and may conflict.
      • Allow ~48 hours and one or more restarts for certificates to fully apply.

    For large VM estates and AVD farms, Intune, GPO, registry-based configuration, or WinCS automation are the recommended scale mechanisms. The context does not describe Azure-native services such as Azure Update Manager or Defender for Cloud as first-class orchestrators for this specific Secure Boot certificate rollout.

    1. Detection and monitoring

    The guidance emphasizes inventory and monitoring before and after deployment:

    • Inventory: determine which devices require updates by identifying Secure Boot–enabled VMs and images:
      • Trusted Launch VM with Secure Boot enabled (session hosts)
      • Azure Compute Gallery images with Secure Boot enabled (golden images)
    • Verification for golden images:
      • After applying the update to a Secure Boot–enabled Azure Compute Gallery image, verify before generalizing with: 
            Get-ItemProperty "HKEY_LOCAL_MACHINE:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" | Select-Object UEFICA2023Status
    • Monitoring: explicitly recommended to confirm certificates are applied before June 2026, even if relying on automatic deployment.

    The context does not describe any built-in Azure or Defender for Cloud reporting specifically for Secure Boot certificate status; monitoring is described in terms of registry state and guest OS–level deployment status.

    1. Impact if certificates are not updated

    The Secure Boot certificate expiration impact is described as follows:

    • Microsoft Secure Boot certificates issued in 2011 begin expiring in June 2026.
    • Without the updated 2023 certificates, devices will no longer receive new Secure Boot and Boot Manager protections or mitigations for newly discovered boot-level vulnerabilities.

    The focus is on loss of future protections and mitigations at the boot level. The context does not state that Azure VMs or AVD session hosts will stop booting or that workloads will immediately fail; the documented impact is that they will not receive new Secure Boot/Boot Manager protections after expiration.

    For Azure Stack Hub, the guidance clarifies that Secure Boot mitigation actions target the host boot chain and do not affect tenant VMs (which are Gen1 and do not support Secure Boot). For Azure Virtual Desktop and Secure Boot–enabled Azure VMs, the expectation is that workloads continue to run but become less protected against new boot-level threats if certificates are not updated.

    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.