Secure Boot is a UEFI firmware feature that enforces trust for early‑boot code. Microsoft is replacing the 2011 Secure Boot certificate authorities with 2023‑dated CAs, so devices can continue to accept DB (allow) and DBX (revoke) updates and boot‑time mitigations. If you have Azure Virtual Desktop (short AVD) session hosts, AVD golden images, or Windows 365 (short W365) Cloud PCs you need to ensure the 2023 certificates are applied before the 30th of June 2026. And you may have already received that notification email from Microsoft, the one that looks like the screenshot shown.
Below I’ll summarize who needs to act, how to detect impacted machines, deployment options, golden image guidance, and common troubleshooting steps.
Does this affect your environment
As an AVD or W365 admin now you’ll ask yourself, does this certificate expiration affect my environment? It mostly comes down to whether your VMs are running Trusted Launch with Secure Boot enabled, and whether you use Secure Boot golden images. Below is a compact decision guide so you can quickly see when action is required.
Azure Virtual Desktop scenarios
| Scenario | Secure Boot active? | Action required | Notes |
|---|---|---|---|
| Trusted Launch VM with Secure Boot enabled | Yes | Update certificates on the session host | Apply updates to the running VM or update the golden image before provisioning. |
| Trusted Launch VM with Secure Boot disabled | No | No action required | No certificate change required. |
| Standard security type VM (no Trusted Launch) | No | No action required | Standard VMs without Trusted Launch are out of scope for image-level Secure Boot updates. |
| Generation 1 VM | Not supported | No action required | Generation 1 VMs do not support these Secure Boot updates. |
| Azure Compute Gallery image with Trusted Launch & Secure Boot enabled | Yes | Update certificates in the source image before generalizing | Install the 2023 CAs on the image and verify UEFICA2023Status before capture and generalizing the VM. |
| Azure Compute Gallery image without Trusted Launch | No | Apply updates in the session host after deployment | Image-level updates not supported. Update guest OS post-provisioning. |
| Managed image (customer-managed image that does not support Trusted Launch) | No | Apply updates in the session host after deployment | Managed images commonly cannot accept image-level Secure Boot updates. Update after provisioning. |
| Azure Marketplace images | Depends | Usually no image-level action for images published on/after 2024; otherwise apply updates in guest after provisioning | Marketplace images published on or after the 1st of January 2024 are generally shipped with the 2023 CAs, but exceptions exist. Always verify the image’s Trusted Launch/Secure Boot capability and confirm the presence of the 2023 CAs. |
Windows 365 scenarios
| Scenario | Secure Boot active? | Action required | Notes |
|---|---|---|---|
| Cloud PC with Secure Boot enabled | Yes | Update certificates on the Cloud PC | Apply updates to the running Cloud PC or update the source image if it supports Trusted Launch. |
| Cloud PC with Secure Boot disabled | No | No action required | No certificate update required. |
| Azure Compute Gallery image with Secure Boot enabled | Yes | Update certificates in the source image before generalizing | Apply the 2023 CAs to the image and verify before generalizing. |
| Azure Compute Gallery image without Trusted Launch | No | Apply updates in Cloud PC after provisioning | Image-level updates not supported. Update the Cloud PC guest OS post-provisioning. |
| Managed image (does not support Trusted Launch) | No | Apply updates in Cloud PC after provisioning | Managed images cannot accept image-level Secure Boot updates. Update after provisioning. |
How to prepare your environment
After understanding which session hosts or CloudPCs are affected, follow the playbooks below. Both follow the same sequence: inventory and scope → choose delivery method → update images/devices → validate post‑update state → troubleshoot.
How to prepare and update session hosts and golden images
Start by prioritizing session hosts with Trusted Launch and Secure Boot enabled, and any Azure Compute Gallery images that support Trusted Launch. These must have the 2023 CAs applied before the deadline.
Inventory and scope
The first step of this playbook is inventory and scope your affected session hosts. The easiest way to do so, is via the Intune.
If you use Windows Autopatch for your organizational end‑user devices and for personal persistent session hosts, check the Secure Boot status report in the Intune admin center (Reports → Windows Autopatch → Windows quality updates → Reports → Secure Boot status). Note that Windows Autopatch supports only personal persistent VMs. Multi‑session hosts, pooled non‑persistent VMs, and remote app streaming are not covered, so don’t rely on Autopatch for those workloads. Still the report can gather information about the certificate status of the “not supported” types of devices. In the screenshot you can see a multi-session host. Not patched via Autopatch and no Autopatch Broker deployed. Yet still in the report. So maybe this is a glitch in the Matrix…
If don’t use Autopatch and your session hosts are still enrolled in Intune, deploy the sample detection script from Microsoft via Intune Remediations (Proactive Remediations). The remediation runs silently on each device, collects Secure Boot certificate status, update progress and device details, reports to the Intune portal and can be exported to CSV for fleet‑wide analysis. If you don’t meet the licence requirements for remediation scripts and your environment is small, run the sample script manually on each session host. More information about the deployment of that remediation script you can find here.
If you don’t manage your AVD session hosts with Intune, query the Secure Boot certificate registry keys directly. Use your existing device‑management tooling (SCCM/ConfigMgr, PowerShell Remoting, or remote registry queries) to collect these keys at scale and export to CSV so you can sort and filter by status. The relevant values live under:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing: UEFICA2023Status (deployment status), UEFICA2023Error and UEFICA2023ErrorEvent (error indicators)
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot: AvailableUpdates (pending bits)
Once you’ve identified affected hosts, scope them into a targeted group or assignment filter for pilots and phased rollout.
Decide delivery method
After you’ve inventoried impacted devices, choose the deployment path that matches your environment and risk tolerance. Microsoft offers two delivery methods: IT-initiated deployments or automatic updates. If you use golden images, refer to the next sub‑chapter for guidance.
The IT-initiated deployment method manually lets you trigger and control certificate rollout using your existing management tools. This is required for devices not in high-confidence buckets, or if you need immediate or phased deployment. This method is also recommended by me and I personally use that. The available methods to initiate the delivery of the new certificates are:NOTE: Under those attached links, you’ll find a detailed deployment guide of each available method.
Microsoft also offers automatic updates for qualifying devices. For devices that fall into high‑confidence hardware buckets (grouped by manufacturer, motherboard, firmware version and other attributes), Microsoft will push the 2023 Secure Boot certificates automatically via monthly cumulative updates. This behaviour is enabled by default for qualifying devices and requires no action unless you want to opt out. Controlled Feature Rollout (short CFR) is a separate opt‑in assist that lets Microsoft manage certificate deployment for devices that send the required diagnostic data and explicitly opt in. CFR can speed remediation where telemetry exists, but it’s an assist, not a guarantee, and won’t cover devices without usable telemetry or unsupported OS builds.If you need to opt out of the automatic high‑confidence path and control the rollout of the certificates by yourself:
- Registry: set HighConfidenceOptOut = 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
- Group Policy: Computer Configuration → Administrative Templates → Windows Components → Secure Boot → Automatic Certificate Deployment via Updates → Disabled
Update golden images
If you use Windows Autopatch for your organizational end‑user devices and for personal persistent Cloud PCs, check the Secure Boot status report in the Intune admin center (Reports → Windows Autopatch → Windows quality updates → Reports → Secure Boot status). Note that Windows 365 Cloud PCs must be registered with the Windows Autopatch service, to be seen in the report.
If you don’t use Autopatch and your Cloud PCs, deploy the sample detection script from Microsoft via Intune Remediations (Proactive Remediations). The remediation runs silently on each device, collects Secure Boot certificate status, update progress and device details, reports to the Intune portal and can be exported to CSV for fleet‑wide analysis. If you don’t meet the licence requirements for remediation scripts and your environment is small, run the sample script manually on each CloudPC. More information about the deployment of that remediation script you can find here.
There is also a third option to inventory your impacted Cloud PCs, by querying the Secure Boot certificate registry keys directly. The relevant values live under:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing:
UEFICA2023Status (deployment status), UEFICA2023Error and UEFICA2023ErrorEvent (error indicators) - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot:
AvailableUpdates (pending bits)
Once you’ve identified affected Cloud PCs, scope them into a targeted group or assignment filter for pilots and phased rollout.
Decide delivery method
After you’ve inventoried impacted devices, choose the deployment path that matches your environment and risk tolerance. Microsoft offers two delivery methods: IT‑initiated deployments or automatic updates. If you use custom images, refer to the next sub‑chapter for guidance.The IT‑initiated deployment method manually lets you trigger and control certificate rollout using your existing management tools. This is required for devices not in high‑confidence buckets, or if you need immediate or phased deployment. This method is also recommended by me and I personally use that. The available methods to initiate the delivery of the new certificates are:NOTE: Under those attached links, you’ll find a detailed deployment guide of each available method.
Microsoft also offers automatic updates for qualifying devices. For Cloud PCs that fall into high‑confidence hardware buckets (grouped by manufacturer, motherboard, firmware version and other attributes), Microsoft will push the 2023 Secure Boot certificates automatically via monthly cumulative updates. This behaviour is enabled by default for qualifying devices and requires no action unless you want to opt out. Controlled Feature Rollout (short CFR) is a separate opt‑in assist that lets Microsoft manage certificate deployment for devices that send the required diagnostic data and explicitly opt in. CFR can speed remediation where telemetry exists, but it’s an assist, not a guarantee, and won’t cover devices without usable telemetry or unsupported OS builds.If you need to opt out of the automatic high‑confidence path and control the rollout of the certificates yourself:
- Registry: set HighConfidenceOptOut = 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
- Group Policy: Computer Configuration → Administrative Templates → Windows Components → Secure Boot → Automatic Certificate Deployment via Updates → Disabled
Update custom images
You can only install the new Secure Boot certificates into the source image for Azure Compute Gallery images (preview) that support Trusted Launch and Secure Boot. Managed images do not support Trusted Launch, so you cannot apply the certificates at image level. For Cloud PCs built from managed images you must apply the update inside the Cloud PC after provisioning.Before you generalize a new custom image, verify the servicing key shows “Completed”:
Get-ItemProperty "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" | Select-Object UEFICA2023Status
Validate post‑update state
Apply the certificate update to each Cloud PC that was identified as not up‑to‑date in the inventory phase. Reboot as required and allow up to 48 hours for the updated certificates to fully apply. Do not mark a Cloud PC or image as validated until all the following are true: the servicing registry value reads “Completed”, UEFICA2023Error and UEFICA2023ErrorEvent are absent, System event ID 1808 appears in the System log (review any 1801 entries for detail), and Secure Boot remains enabled (Confirm‑SecureBootUEFI or msinfo32).
For IT‑initiated rollouts choose one deployment method per CloudPC or CloudPC group, pilot on a small representative set first, then roll out in controlled waves. Continuously monitor UEFICA2023Status, UEFICA2023Error and the System event log (Event IDs 1808 for success and 1801 for status/errors).
Troubleshoot common issues
Here are some basic troubleshooting tips to common issues when updating Secure Boot certificates on CloudPCs:
- Servicing key missing: the update has not started. Check your IT-initiated deployment scope.
- Status remains “InProgress”: restart the CloudPC, wait ~15 minutes, and recheck; allow the full 48‑hour window before further analysis.
- “UEFICA2023Error” present: check the System event log for DB/DBX failure details. If the issue persists, check out this Microsoft guide Secure Boot DB and DBX variable update events.