Event details
274 Comments
Questions for Tomorrow’s Live Event / Or Anytime:
We’re testing the certificate updates on our servers within our vSphere environment. We seem to have a functioning certificate update process? However, we are not clear on some things and have some questions – especially when it comes to Broadcom/VMware.
For reference, we’re on vSphere 8 U3 with virtual hardware level at 21 (the current release). Our VMTools versions are also fully up to date (if that matters). We’re running Server 2019, Server 2022, and Server 2025. Here is the process we are testing right now:
1 - We rename the VM’s NVRAM file in vSphere. (Note that we have some important vSphere questions about this below).
2 - After that, we configure the AvailableUpdates = 0x5944 key, per the various forms of Microsoft documentation.
3 -We then manually run the Secure Boot Update scheduled task to start the update process using this command:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
We then wait about 30 seconds and reboot.
4 - After the reboot, we manually run the above-mentioned scheduled task again.
5 - We wait a few minutes, and then when looking in the Secure Boot registry keys, we most often see the UEFICA2023Status return as “Updated” and WindowsUEFICA2023Capable returns 2.
HOWEVER - on the Server 2019 OS, while UEFICA2023Status shows “Updated”, the WindowsUEFICA2023Capable value comes back as 0. Despite that, when we run the verification command - ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)) -match "Windows UEFI CA 2023" - it still returns “True”.
Should we be concerned about the WindowsUEFICA2023Capable = 0 result on server 2019 if the above-mentioned database check command allegedly confirms that the device is currently using the 2023 Secure Boot certificate?
Also, VMware has not yet released an updated virtual hardware/BIOS package for this issue (only manual steps). We are not sure it matters. Do we need to worry about the virtual hardware/Bios update offered by VMware if we’re already seeing the “Updated”/WindowsUEFICA2023Capable =2 results we’re getting now within the registry? From a compliance perspective, does this mean we’re covered? For that matter, do we even need to rename the NVRAM File?
Finally, we’ve noticed that on some of our Server 2025 systems, even when the certificates updates itself successfully, the Secure Boot scheduled task fails with a “file not found” error. Is there a way to correct this? It appears to be a built‑in, “solid‑state” task. We are not sure how to address this.
Thanks
Prabhakar_MSFTMicrosoft
Hello CTKMN , If devices are showing UEFICA2023Status as “Updated”, it means device have all required certificates and also booting with updated new windows boot manager. We are investigating the issue related to WindowsUEFICA2023Capable not being updated to 2.
Thanks! Do you have any thoughts on my other questions?
I am seeing similar behavior with some of my HyperV Virtual Machines. Updated Capable =2 for some, both Server 2022 and Server 2019 though, and another Server 2019 patched with the same March 10th updates, it shows capable=0 instead of 2. So not sure what the difference is, but that capable=0 is on one of my Server 2019 VMs. I have only tested so far on one server 2022 VM.
Hi Arden_White
today i updated an tested Hyper-V VM (Version 9) Server 2022 DC. 0x5944->0x4004
i checked "C:\Windows\System32\SecureBootUpdates\BucketConfidenceData.cab" and then the Microsoft.json which lists my VMs BucketHash in the Section:
"Under Observation - More Data Needed": [
Any Info Regarding Servers, would like to hear more about it (tomorrow) last month it was said it should be fixed in March.- Arden_White
Hi PeDe83 the March updates need to be applied to both the host and the guest.
- Host changes are to allow KEK updates to the NVRAM
- Guest changes are to include a Hyper-V PK signed KEK that the guest can apply to the firmware.
If I'm remembering correctly, if you look at the SYSTEM log at the TPM-WMI source, you'll see a 1795 event if the host is not updated and the guest is. Otherwise, you'll see an 1803 event if the host is updated and the guest is not.
Arden_White are there details available in a KB on these changes available in this month's updates, or more information about applying the updates for Hyper-V hosts/guests?
Microsoft has provided very little information with regarding the Secure Boot cert expirations on Hyper-V. Some really useful information would be version numbers of installed QFEs with the necessary certs/fixes, and details like you just provided (the fact that both the host OS and the guest OS have to be patched, and the 1795/1803 event IDs).
Also, information what order the patches should be applied (host, then guest?), and how I can streamline patching, cert updates, and reboots this across dozens of hosts would be really useful... especially since Microsoft has only given us 3 months until the CA expiration and enterprises have limited change windows available.
Just updated my HyperV host, only seeing preview updates available for Windows 11 24H2, I updated to 25H2, and do not see any updates from March showing up yet, checking in my SCCM Lab environment and still only see February updates so far... forcing a synch to see what else shows up.
- In a situation where the KEK certificate does expire can we get a clearer idea as to the actual impact? It’s stated that new binaries will not be accepted into the authorized signature database however older previously signed binaries will still be trusted. This confuses me, because the wording of the boot process in regards to secure boot certificates implies that the signatures of trusted binaries is checked every single time.
- Products that use kernel level drivers rely on WHQL microsoft signed drivers that appear to be reliant on the secure boot certificate chain. What is the impact to these tools if the primary KEK certificate is expired?
- What is the status from Microsofts perspective on ongoing efforts with OEMs (i.e. VMWare) to figure out automation of PK certificate rollouts?
- Arden_White
- The KEK certificate/keys signs updates to the DB and DBX. The DB updates to apply the new certificates are signed with the Microsoft Corporation KEK CA 2011 which the device trusts. Moving to the new certificates, even after the 2011 KEK expires should still work. New security updates to the DBX will be signed with the Microsoft Corporation KEK 2K CA 2023. If the firmware does not trust the 2023 KEK, the new DBX updates will fail to apply. During boot, the KEK is not used for validating binaries - only the contents of the DBX and DB are used.
- The KEK is not used to validate WHQL signed drivers. It is only used to validate updates to the DB and DBX. The firmware does not care that the certificates have expired. The issue is the need for key rotation as a good security practice and because Microsoft cannot sign with expired keys.
- I am aware of Microsoft and Broadcom-VMware working together, but I don't know the details.
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
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_MSFT
Hello 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.
