Good Morning team! 

We have largely deployed the new certs via Intune across our hybrid physical, Azure Cloud & Azure On Prem PC fleet. 

We have one significant hangup - nearly all of our AVD’s in our oldest pool are experiencing error 1795, with the upgrade being stuck ‘in progress’.  

Is there a difference in how AVD (both cloud and on-prem) handle the deployment? What would our next steps be? 

What would be the overall advice to consider/action regarding this topic in relation to clients running Bitlocker (or similar encryption system) in conjunction with SecureBoot?

May the team comment on reboot requirements? I've seen devices reach UEFICA2023Status=Updated, which is identified in KB5068202 as the authoritative "deployment status indicator". The observation is that devices seem to need a second reboot to actually be booting from the updated 2023 signed boot manager. So is the second reboot a hard requirement? Or is achieving UEFICA2023Status=Updated truly sufficient?

I have quite a few machines with UEFICA2023Error 2147952750 (even some in High Confidence buckets), from different manufacturers (Lenovo, HP, even Hyper-V virtual machines on a Windows Server). Others have a 2147946825, or 2147942405. What am I expected to do with that error code? UEFICA2023Status is blocked to "InProgress", AvailableUpdates does not make any progress. Is my only possible next step to try to contact each manufacturer independently?

I've administrative templates updated and we are unable to find Secure Boot setting in gpo's. Computer\Administrative Templates\Windows Components\Secure Boot doesn't appears. Could you explain why?

For environments where Secure Boot is currently disabled (Azure VMs, VMware, Nutanix, etc.), is the following approach considered valid and supported by Microsoft?

1. Keep Secure Boot disabled today
2. Install all required 2023 Secure Boot certificate and bootloader updates through normal OS patching before June 2026
3. After June 2026, enable Secure Boot during a controlled maintenance window
4. Reboot the VM so it boots using the updated 2023 certificate chain

In other words:

• Can organizations safely prepare the new Secure Boot trust chain in advance without enabling Secure Boot immediately?
• Is there any risk that systems with Secure Boot disabled today would fail to boot after June 2026 if the new certificates are already installed?
• Does Microsoft recommend this phased approach for enterprise server workloads where enabling Secure Boot immediately may introduce operational risk?

We would appreciate guidance specifically for Azure IaaS server workloads and enterprise Linux/Windows Server environments.

With the June 2026 Secure Boot certificate expiration/change, could Microsoft clarify how Azure IaaS VMs differ from other virtualized platforms such as VMware or Nutanix from an operational responsibility perspective?

Specifically for Windows Server and Linux Server guest OS workloads (not Windows 10/11 clients):

• Since the Azure hypervisor/host layer is fully managed by Microsoft, what actions are customers still expected to take inside the guest OS to prepare for June 2026?
• Are normal OS patching processes sufficient, or are there additional manual steps required for Azure Gen1/Gen2 VMs?
• Will Azure automatically handle any UEFI/firmware-level certificate updates on the platform side, or is all certificate preparation expected to occur within the guest OS boot chain?
• Are there differences in expectations between Trusted Launch / Secure Boot enabled VMs and VMs where Secure Boot is currently disabled?

We are particularly interested in best practices for enterprise server workloads such as SAP, infrastructure servers, and other long-lived Azure VMs.

Are machines no longer supported by the OEMs going to get the new cert? After running the registry key to set to 0x5944 it goes to in progress but checking the event viewer states the following: The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device. Check with your device vendor for a firmware update that addresses the issue. This device signature information is included here.
will these devices get updated by microsoft eventually?

Do you have any update regarding VMWARE's issue with PK not being able to allow the SecureBoot certificates to install?

The 0x4000 "Conditional CA 2023 application" guard bit

The AvailableUpdates registry value includes the bit 0x4000, which we understand acts as a guard bit: a given CA 2023 certificate is only injected into the Active db store if its 2011 equivalent is already present in the Default store.

Two questions on this:

1. Is the behavior of this guard bit documented publicly anywhere? We have only been able to infer it from field observation, not from official documentation.
2. Is this conditional mode permanent, or is it scheduled to transition to an unconditional mode at a specific date (for example, around or after the June 2026 PCA 2011 expiration)? If so, what is the timeline, and what should administrators expect in terms of behavior change on machines that have not completed the migration by then?