Event details
113 Comments
Dell Laptop. Latest BIOS Update (including the 2023 certificates). DB, DBDefault, KEK, PK. All new. Registry Key "UEFI2023Status" = "Updated", but "ConfidenceLevel" = "No Data Observed - Action Required". And: in the new Intune Secure Boot status report this device's Certificate status = "Unknown". Rebooted many times. Why? What to do?
Can you discuss the process for remediating this on windows server vms running on vmware & aws ec2?
When should we expect to see the Boot manager start using the new Certs? also when should we see an ISO with this? Is this something Orgs should open up an ISO and manually make a change or wait for Microsoft?
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?
Hey Critter,
I know there is a known issue, if that's applicable for you.
https://support.microsoft.com/en-us/topic/known-issues-and-resolutions-for-secure-boot-certificates-updates-5813673d-2577-4718-ad28-2554a9178e40#bkmk_certificate_updates_fail_with_event_id_1795
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?
Thank you for responding during the AMA! The interest in the second reboot was indeed to achieve the 1808 event ID as end-to-end confirmation the update process (re: KB5016061) is complete, which Arden touched on re: 1801/1808. The 1808 would also be reflected in the Intune detect-only remediation, which is great from a reporting standpoint. So from the responses given in the AMA, it sounds like the second reboot can be left to be a natural reboot barring any specific attestation requirements as Scott indicated. Thank you!
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?
My suggestion would be to check event log for Secure Boot related events. The actual (translated) error message is usually more helpful than the error code.
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?
- Keep Secure Boot disabled today
- Install all required 2023 Secure Boot certificate and bootloader updates through normal OS patching before June 2026
- After June 2026, enable Secure Boot during a controlled maintenance window
- 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.
