Event details
364 Comments
Thank you for the update, Arden. As a new user, this clarification is very helpful.
We use Intune + WUfB only and haven’t enabled any Secure Boot policies. ~40% of devices have already updated or are in progress, ~60% aren’t ready yet.
My understanding is:
- We can do nothing and let Windows Update handle this, which is probably the lowest risk option, but gives us the least certainty that everything will be done well before the 2026 deadline.
- Or we can enable Intune Secure Boot policies to try and push things along, but there’s no guarantee it actually speeds things up, and it could introduce risk on devices that aren’t fully ready (firmware/BIOS, etc).
Is that understanding correct?
I would say it is likely that it speeds things up, but it is not certain. And you are right about the risks.
I have noticed something on thousands of my devices that the WindowsUEFICA2023Capable value is set to 2 however, there is no mention of the UEFICA2023Status value. The device shows that it's booting on the 2023 cert. What does this mean?
Make sure to install the latest Windows LCU before updating the certs. For my understanding the UEFICA2023Status value changes only to the "updated" state, if your hardware type (BuckedID) has been approved as "problem-free" by Microsoft (and that definition comes with the LCU).
Hi Arden_White
What are the methods available for Server OS to renew secure boot certificates? we are using SCCM to manage the patching of server OS.
Is any Estimated timeline for Secure Boot Certificate renewal to be delivered through monthly cumulative updates for Windows Server OS, any additional steps required to complete the certificate renewal when using cumulative updates?
My ask is about the windows Server OS (2019, 2016, 2012R2, 2012).
- Arden_White
Microsoft
For Windows Server, the supported approaches today are OS‑side deployment using Group Policy or registry keys, which can be deployed and managed through tools like SCCM.
It’s important not to rely on Microsoft‑managed controlled rollout or high‑confidence servicing for servers. Those mechanisms primarily apply to client Windows and are driven by telemetry that is typically limited or unavailable on Windows Server.
Secure Boot certificate updates for Server are delivered through normal Windows servicing, but they only apply after the device is explicitly opted in using Group Policy or registry configuration. In practice, most server environments should plan for a customer‑managed rollout rather than expecting certificates to be applied automatically.
- RoySasabe
Hi!
I hope this server playbook helps answer your question:
https://aka.ms/SecureBootForServer
The modules necessary for the Secure boot updates are already delivered through monthly cumulative updates for Windows Server OS. Unlike PC clients, the Secure boot cert update needs to be manually triggered by IT Administrators, and the server playbook shares the best practices on how to plan and manage this transition safely.
Thanks RoySasabe its clear now that for server OS, we need to manually initiate the secure boot certificate Renewal process via reg key or by GPO. looking for some more details:
- Request for Linux VM Certificate Renewal Process
Could you please provide the detailed certificate renewal process for Linux virtual machines where Secure Boot is enabled and the underlying virtualization platform is Microsoft Hyper‑V, Azure? - Secure Boot Certificate Renewal for Citrix Non‑Persistent VDI/Image‑Based Servers
We have Citrix VDI and image‑based non‑persistent servers, and we require clarification on the correct Secure Boot certificate renewal procedure for these environments. Since updates are deployed through the master image, if we renew the certificate within the master image, will the non‑persistent servers inherit the updated certificate seamlessly when the image is applied? Additionally, are there any further steps required for each non‑persistent VM to ensure proper certificate update? - Secure Boot Requirements for Physical Hyper‑V Hosts
We have several physical Hyper‑V host servers where Secure Boot is disabled at the hypervisor level, while the guest virtual machines are configured with Secure Boot enabled. Please confirm whether a Secure Boot–compatible firmware update is still required on the physical Hyper‑V hosts under these conditions. - Downtime and Reboot Requirements for Secure Boot Certificate Renewal
articles say it may take 12 Hrs to 24,48 Hrs to complete the renew process , being a server os we also seek guidance on managing this within a controlled patch window. Specifically, if we perform one reboot during the current monthly patch cycle and defer the second reboot to the next month’s patch schedule, would this pose any performance degradation, stability issues, or operational risk for the affected servers? - Is there any potential impact on installed applications following the renewal of Secure Boot certificates? Is there any rollback plan in case of any issues?
Event ID 1795 Error on Multiple VMs – Clarification on Required Fix
We are observing Event ID 1795 across multiple virtual machines. Based on several articles and known-issue references, it appears that Microsoft has acknowledged this issue and is expected to release a fix as part of the March Patch Tuesday updates.
Could you please confirm whether the upcoming fix (KB) will need to be applied on:
- the individual virtual machines only,
- the Hyper‑V host servers only, or
- both the VM guests and the Hyper‑V hosts
in order to fully resolve the Event ID 1795 occurrences?
- Request for Linux VM Certificate Renewal Process
I would like to verify something that we are seeing. We elected to set MicrosoftUpdateManagedOptIn to 1 in the registry however, we are not seeing any movement on the certificates installing. If I run reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f, I see movement. Am I correct in thinking that when we set the initial setting, Microsoft will eventually start the process automatically for these devices?
- Arden_White
Hi jeddunn, all roads lead to the AvailableUpdates registry key.
- If you opt in to MicrosoftUpdateManagedOptIn and Microsoft is receiving diagnostic data, the Controlled Feature Rollout (CFR) should get to those devices - when it does, it will set AvailableUpdates and the certificates should begin to deploy.
- If you set AvailableUpdates on a device, the certificates will begin to deploy.
- For High Confidence devices in the monthly updates, this will also set AvailableUpdates. As does Group Policy and Intune.
The Microsoft Managed updates through CFR are cautiously deploying to more and more devices each day.
Arden - MicrosoftHi Arden_White I had a similar question so thought I'd jump on here. :)
In Intune, if we set...Configure Microsoft Update Managed Opt In to Enabled
Configure High Confidence Opt-Out to Disabled
and ignore Enable SecureBoot Certificate Updates for common devices ie Dell, Lenovo, Surface etc, then the secure boot certs will only be rolled out when Microsoft deem it safe? We can leave the Enable SecureBoot Certificate Updates policy and not deploy it?
I think that will be safest for us if I understand it right, we are still working to get our bios versions updated, but want to get started on those which are ready to go with modern bios versions.
Thank you! :)
Arden_White RoySasabe Specifically for Server 2025, we're consistently seeing systems show the new certs installed, the registry value shows that servicing succeeded, no errors in the event logs, but also there’s no 1808 event (see screenshot). This is consistent across every 2025 system I’ve seen the new certs on, so I would assume that this is expected behavior and that the server has successfully updated, but I can find no documentation anywhere that says this would be expected behavior on Server 2025. Can the MS team please clarify whether or not we should always expect the 1808 event?
Completely same experience here. Can add that the GPO setting Enable Secure Boot Certificate Deployment also doesn't work on Windows Server 2025. Works on earlier Windows Servers.
Hopefully Arden_White or someone else on the Microsoft team can shed some light on this.
Updated my Secure Boot analyzer script because the script provided in Microsoft documentation appears unclear to me about its usage.
The tool to assess current state of the machine and the certificates was mentioned during the event. Where will it be released?
There was a Secure Boot report in Intune, but Microsoft have since (hopefully only temporarily) revoked it due to issues.
I would like clarification on the process on machines that have no internet access. We have 8 domains that have nothing but Windows 10 and 11 LTSC.
- Arden_White
There are several approaches that can work for offline environments. If the devices are typical client machines such as desktops or laptops, they will usually receive the Secure Boot certificates automatically through the monthly cumulative updates if they are identified as high confidence devices. Another option is to manage the deployment directly by instructing the devices to install the certificates through Intune, Group Policy, or registry-based configuration.
It is important to monitor each device in your fleet to understand its current status. Several registry keys and event log entries report the state of the Secure Boot update process. These documents are being updated this week, so check the Change log on each page for the latest information.
Building a dashboard that tracks these signals will help you understand how the deployment is progressing. In particular, watch the BucketConfidenceLevel in Event 1801, since it indicates whether the device qualifies as a high confidence system for automatic updates.
According to CMPivot in ConfigMgr, we're detecting over 1500 Windows 11 devices without the "UEFICA2023Status" registry key. Why would this be? We had planned on using this in a detection scenario where we could flip the AvailableUpdates key on devices where the "UEFICA2023Status" key was "NotStarted"
