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

SMT 0 Reputation points

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!

  1. Manish Deshpande 7,010 Reputation points • Microsoft External Staff • Moderator

    Hello @SMT

    These are exactly the right questions to be asking ahead of the June deadline. Let me work through each area for you.

    • Responsibility & which update to apply

    For Azure VMs and AVD session hosts, the update needs to come from within the guest OS — Azure does not push this automatically to all VMs. The platform handles it only for a subset of "high-confidence" devices where telemetry confirms safe deployment. So yes, the customer holds responsibility for ensuring this is applied across their estate.

    The good news on the manual update failures you've been seeing (Event ID 1795 / KEK write-protected error) Microsoft addressed that in the March 2026 cumulative update (released March 10, 2026 for most OS versions). For Windows Server 2025, the fix landed in the April 14, 2026 update. If your customers are on hotpatching, they should target the April 2026 release specifically.

    There's no single standalone KB for just this fix; it's bundled in the monthly cumulative update for each OS. Once applied, verify success by checking for Event ID 1801/1808 in the System event log or the UEFICA2023Status registry key.

    https://support.microsoft.com/en-us/topic/known-issues-and-resolutions-for-secure-boot-certificates-updates-5813673d-2577-4718-ad28-2554a9178e40

    • AVD session hosts

    AVD session hosts follow the same path — no special service-level integration from the AVD platform side. Session hosts need to be Gen2 VMs with Secure Boot enabled, running a supported Windows OS, and updated through the standard Windows Update / Intune / GPO pipeline.
    https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-for-azure-virtual-desktop-06a8a1bc-2510-4ead-9bea-3698e1d6b1db

    • Deploying at scale

    For customers who are selective about updates (understandable in a production environment), the recommended approach is to use Microsoft Intune with the Secure Boot certificate update CSP under Settings Catalog — this lets you target specific device groups and control rollout timing. Alternatively, Group Policy works well for on-prem-joined VMs, and Windows Update for Business / WSUS can be scoped to ring-based deployment.

    For large Windows Server estates, Microsoft has published a dedicated playbook that covers the Secure-Boot-Update scheduled task approach.

    https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789

    • Monitoring & inventory

    For identifying which VMs still need the update, the most reliable approach today is querying the Windows System event log for Event IDs 1800, 1801, and 1808 across your fleet, or checking the UEFICA2023Status registry key remotely via PowerShell or Intune remediations. As of April 2026, the Windows Security app also surfaces update status under Device Security > Secure Boot, which is useful for spot-checking individual hosts.

    There's also a sample Intune remediations script published by Microsoft specifically for monitoring Secure Boot certificate status at scale.

    • What happens if you miss the deadline?

    VMs won't suddenly stop booting — existing workloads will continue to function normally. What you lose is the ability to receive future Secure Boot and Boot Manager security updates after the 2011 certificates expire. That's a meaningful security gap, especially given threats like the BlackLotus bootkit. The recommendation is to get this done before June, but it's not a cliff-edge outage event.

    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

    Hope this helps you build out your remediation plan. Feel free to follow up if you hit specific errors happy to dig into them.

  2. Manish Deshpande 7,010 Reputation points • Microsoft External Staff • Moderator

    Hello @SMT

    I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail.

  3. Manish Deshpande 7,010 Reputation points • Microsoft External Staff • Moderator

    Hello @SMT

    I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail.

  4. Kartheepan Ramakrishnamoorthy 0 Reputation points

    We have Azure Linux VMs with the following spec:

    •	OS: RHEL 8.10

•	VM Generation: V2

•	Security Type: Standard

•	Secure Boot: Disabled

•	Not using Trusted Launch”

    Questions:

    1.	Based on our VM specification above, are we required to perform the Secure Boot 2011 certificate update as per advisory SP41-GGG?

2.	Since our VMs are Standard security type with Secure Boot disabled, does the certificate expiry on June 27, 2026 have any impact on our VM availability or applications?
Sign in to comment

2 answers

  1. Nikhil Duserla 9,940 Reputation points • Microsoft External Staff • Moderator

    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.

    0 comments No comments
    Sign in to comment

  2. AI answer

    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.
Sign in to answer

Your answer