Event details
219 Comments
I've done all of the same procedures on my Hyper-V guest Windows 2022 servers I did to my workstations but the certificates are not updating fully. I get a 1799 but no 1808.
Are we still awaiting patches for this from Microsoft?
EDIT: March cumulative on the host and working on guests now. All of them are getting certs now.
I can confirm the March 2026 cumulative updates installed on the Hyper V Host, and on the guest VMs (in my case it was Server 2019 that was not getting the updated Secure Boot Certificates. Once the march patches were installed and I restarted the servers it took a short time, but they both now show the Updated status as desired.
I have both Server 2022 and Server 2019 VM's in Hyper V on Windows 11 24H2, I have updated the certificates on the host, and the Server 2022 VM's with the registry update, forced them to update successfully after a reboot or two. The same host's Server 2019 VM's are getting the Event ID 1795 with the error that the media is write protected. Error code in the registry is showing in progress with this code 0x80070013, which is media is write protected. Not sure what else to try, I am going to upgrade the host to 25H2 and see if that changes anything, but I don't see why it would.
- Arden_White
Microsoft
My guess as to what's going on is that everything is complete except for the KEK. There's a fix in Hyper-V coming out today (applied to the server) that allows guest VMs to update the KEK. If you look back in the events (SYSTEM log, TPM-WIM source) you might see an event 1795 where it says it cannot apply the KEK.
If this is the case, applying the March updates to the Hyper-V server(s) should allow the KEK updates to apply.Going to try that, my Server 2022 VM's updated, but Server 2019 VM's did not stating that the TPM was write protected in the 1795 system event.
If we're doing baremetal OS deployment using ConfigMgr or other solutions, what needs to be done so newly imaged workstations immediately contain the new secure boot certificates? I'm using the Windows 11 25H2 Enterprise image from the Microsoft VLSC updated with the 2026-02 updates (KB5077181) and no other modifications. I'm imaging a Dell system running the latest BIOS version. After imaging, I still get event ID 1801 indicating "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware."
- Arden_White
This is a scenario that I have not thought through before. I believe, for bare‑metal deployments, this behavior is expected.
Key points:
- OS imaging does not modify Secure Boot firmware variables (DB, KEK, DBX). Those live in UEFI firmware and persist across reimaging.
- Windows 11 25H2 will automatically install the 2023‑signed boot manager if the 2023 Secure Boot certificates are already present in firmware.
- If the certificates are not present, Windows will detect that updates are available and log Event ID 1801 until Secure Boot servicing is triggered.
For ConfigMgr or other deployment solutions, the recommended approach is to trigger Secure Boot servicing after imaging by setting:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot AvailableUpdates = 0x5944
This causes the SecureBootUpdate scheduled task to run and determine what work is required. It will apply missing certificates to firmware and update the boot manager as needed. Once complete, the device will converge to the correct Secure Boot state without requiring image customization.
This is the simplest and supported way to ensure newly imaged devices are fully updated.
The certs are updated the same way, you can either force it with the registry, or GPO, or a scripted solution from Intune or ConfigMgr etc and reboot the computer. The certs need to be installed into the TPM/Firmware, not in the OS. See the guide here for more info Secure Boot playbook for certificates expiring in 2026.
Hello,
I'm looking for some additional clarity regarding the HighConfidenceOptOut registry key. Specifically, if I want to fully manage the Secure Boot certificate rollout in my environment, do I need to ensure that both the AvailableUpdates and HighConfidenceOptOut registry keys are configured (0 and 1, respectively) to prevent automatic certificate deployment?
Note: Our environment leverages SCCM/WSUS for device management and patching, we do not leverage Windows Update/Autopatch for patch deployments
My understanding is based on the documentation:
AvailableUpdates
0 or not set - No Secure Boot key update are performed.We already have AvailableUpdates configured with a value of 0. However, we currently do not have the HighConfidenceOptOut key configured.
HighConfidenceOptOut
An opt-out option for enterprises that want to prevent automatic application of high-confidence buckets delivered as part of the LCU.
0 or key does not exist – Opt in 1 – Opt outAfter installing the February Cumulative Update (KB5075941), a subset of devices in my environment automatically installed the updated certificates, even though AvailableUpdates is set to 0. My assumption was that this key alone would prevent any automatic certificate updates, regardless of the HighConfidenceOptOut setting. Given what I'm seeing, I may be mistaken.
I also saw in the KB5075941 release notes that new Secure Boot changes were introduced, but again, my expectation was that configuring AvailableUpdates = 0 would block any automatic updates.
Could you clarify whether both keys are required to fully prevent automatic certificate deployment?
Thank you.
- Arden_White
Hi Matt,
AvailableUpdates is the mechanism that actually causes Secure Boot certificate updates to be applied. The key always exists, and when it remains at its default value of 0, Windows is not being instructed to apply updates. There is no need to explicitly configure it to 0 in this scenario.
However, some delivery paths can set AvailableUpdates on your behalf.
High Confidence updates are one of those paths. When a device is identified as eligible for a High Confidence update delivered via the LCU, Windows can automatically set AvailableUpdates unless you explicitly opt out.
Setting HighConfidenceOptOut=1 prevents the High Confidence feature from setting AvailableUpdates automatically. Without this opt-out, High Confidence processing can still trigger certificate deployment even though you have not intentionally enabled deployment.
For managed deployments:
- Enabling the Enable Secure Boot Certificate Deployment GPO sets AvailableUpdatesPolicy, which in turn sets AvailableUpdates.
- Microsoft Intune behaves the same way by setting AvailableUpdatesPolicy, which then drives AvailableUpdates.
So, if your goal is to fully prevent any automatic Secure Boot certificate deployment and manage rollout entirely yourself, you should:
- Leave AvailableUpdates at its default value
- Set HighConfidenceOptOut=1
This ensures that High Confidence processing does not implicitly trigger certificate deployment.
Hope this helps clarify what you are seeing.
Arden
Great, thank you Arden_White​ for the detailed explanation!
Let's say I have a 2024 HP ProBook Laptop with 2026 latest BIOS update, AD DS joined, with Windows Update activated with basic GPO settings (drivers and quality included).
No telemetry , no diagnostics sent to MS, no Intune.
If I let things go without interfering, when does this laptop will get certificates update from Windows Update ?
Will the update sent from Windows Update will create the scheduled task and run it every 12h ?
Thanks
It will get the certificate with a monthly cumulative update, assuming the device type reaches the high confidence list. Probably it already has.
The scheduled task is already there for a long time (it has been also used to apply DBX updates, for example) and it will run every 12 hours, but just do nothing as long as there is nothing to do.
​ ​ Arden_White​
Can you please let us know when the Intune Error Code 65000 issue is expected to be fixed? I've seen this still across multiple tenants but there's been no update to guidance around resolution date. If there's been a delay, can you please let us know? The official doc says "this issue will be resolved for all devices by February 27, 2026." Thanks!
- Arden_White
Hi mikemagarelli,
we discovered a new issue where the 65000 error occurs, and it seems to only occur on Windows 11 23H2. A fix for this is coming in the April release. Is that the version of Windows where you are seeing the error or have you been seeing it elsewhere?Arden
Arden_White​ We are seeing it in an environment with only Win 11 25H2 & 24H2, we not have 23H2.
Will Microsoft and/or Broadcom provide a solution to automatically update ESXi VMs with missing KEK/PK?
The solution from the article https://knowledge.broadcom.com/external/article/421593/missing-microsoft-corporation-kek-ca-202.html is unfortunately no longer available (upgrading the hardware version and deleting/renaming the .nvram file).
This article https://knowledge.broadcom.com/external/article?articleNumber=423893 states:
"There is no automated resolution available at this time. In coordination with Microsoft, Broadcom Engineering Team is actively working towards implementing an automated solution in a future release to update the Platform Key (PK) on the affected VMs, which will facilitate the certificate rollout as outlined in the Microsoft Guideline."
Prabhakar_MSFTHello IT_SystemEngineer​ , As you mentioned, we are coordinating with Broadcom to bring support in Windows to update KEK on the ESXI VMs. If new VMs are created on latest versions on ESXI, VMs get created with new certificates. For pre-existing VMs, Microsoft is coordinating with Broadcom and will be enabled in the future update.
What happens if you set the registry settings on a device that is still using Legacy BIOS? Is the update process smart enough to ignore those devices?
- Pearl-Angeles
Community Manager
Thanks for your question! It was answered at around 0:46 during the live AMA.
The device is not updated (since there is no Secure Boot to update) and the scheduled task Secure-Boot-Update will write a 1801 error event.
My company has around 2000 servers on VMWare that we need to make sure that get updated. We don't want to rely on Microsoft to eventually roll out these updates. I know the February AMA discussed that there might be some tools coming out in March that might help with automating some of this.
I just spent about 2 hours or so with our server team just going through this process to update these machines manually. I mean this is asking a lot to have us touch each server, coordinate with folks on their production servers so that we can shut them off, update the NVRAM file, then reboot them about 2 additional times before we get the 1808 event ID that tells us all is well and good.
I also have a script that supposedly audits our servers and tells us if the certs are active. I just looked at a few machines where it says the certs are active and it gives it a "pass" on the report, but when I go to the registry under secure boot, the status is set to "not started", there are also no event IDs present for TPM/WMI. I mean maybe things updated a while ago, but shouldn't I see "updated" in the registry and not "not started". Can someone verify what we should see in the registry w/ regards to this just for verification purposes?
There is so much confusion over what we need to do. We've spent probably too much time looking at Microsoft documentation on this trying to figure out what to do. My boss doesn't want to wait things out and risk critical servers to have issues with booting at some point. Also, going through 2000 servers with a team of about 5 of us is also a lot to ask to make sure certificates are installed and active. There has to be an easier way to do this.
- Prabhakar_MSFT
Hello gmartin_3434​ , We have published detection script that helps with collecting data on certificate deployment status in the system. The link to the script is published at Sample Secure Boot Inventory Data Collection script - Microsoft Support . Copy the script and save it and execute on server where you want to verify status. The script exits with code 0 if certs are updated else it exits with 1 indicating one or more certs are not updated. Script also prints data points which provides data points about overall secureboot status, any errors with applying the updates.
rparmar50The status registry will show "updated" only when all required certs + bootmgr is updated. If it is showing "not started" that means that device is not fully updated (either some certs or bootmgr is old) and there is no in-progress update.
Our company does not allow us to use Intune.
Are there any helpful tools or scripts to Inventory?- Pearl-Angeles
In addition to Ashis's response below, the panelists covered your question during the live AMA at 1:59.
- Ashis_Chatterjee
Yes, the Inventory Powershell script in: aka.ms/getsecureboot->IT Managed guide on left Nav has a section on Inventory which can be used as a sample.
Sample Secure Boot Inventory Data Collection script
Copy and paste this sample script and modify as needed for your environment: The Sample Secure Boot Inventory Data Collection script.
During the February AMA, you en-phased that enterprises should leverage intune and build their own dashboard to monitor secure boot states. The guide require Enterprises licences. As an MSP that manage thousand of devices with Business Premium Plan for multiple customer with Intune and Lighthouse it doesn't make sense.
Is there a plan to monitor those states via a compliance policy instead?
And also.. regarding the secured boot compliance policy that will happen to devices that will still have an old certificate, will they continue to show as compliant with the 2011 certificate?- Pearl-Angeles
Thanks for participating in today's AMA! Your question was answered at around 3:24.
