Event details
397 Comments
Hello!
We are currently testing the cert update in our VMWare ESXi 8 environment for server OS. Testing 2016, 2019, 2022, and 2025. All VMs are fully patched and have latest VMWare tools installed.
After setting the GPO "Enable Secure Boot Certificate Deployment":
2016 updates all certs, EventID 1808 is written.
2019 and 2022, most certs are updated however the KEK is not, giving the Event error 1796.
2025 does not update any certs, nor does it start the update process at all.
- Anyone else having issues with VMWare guests and KEK update for 2019 and 2022?
- Any clue as to why 2025 is not even starting the update process?
Thanks!
- Arden_White
Microsoft
I found these two articles on the Broadcom site that might be helpful.
https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html
https://knowledge.broadcom.com/external/article/423919
Arden - Microsoft
I am not sure why on my Server 2022 testing, but you can just update the KEK the same way you did the PK via EFI and broadcom instructions. they had it on their KB before, then was removed.
you just select enroll PK, then enroll KEK and select the cert on your drive you added to the VM.
now the PK and KEK is updated, start the reg key and updating process, goes to Updated status. you can verify the certs are there after
Is there any risk in attempting to apply the Secure Boot certificate update (AvailableUpdates = 0x5944) before updating the BIOS/UEFI to the version recommended by the OEM? In other words, is having the latest BIOS strictly a prerequisite, or just a best‑practice recommendation?
In the troubleshooting documentation, Microsoft mentions that during the Secure Boot certificate update process a device may fail to boot or require a recovery key. Are these the main risks involved? How likely are these scenarios in real‑world deployments?
Finally, how can I detect if these no‑boot or recovery‑key events were actually caused by issues during the certificate update? What signals, logs, or telemetry can I use to monitor and correlate these occurrences?
As for the likeliness of the scenarios, I'd also like to hear feedback from Microsoft. But at least I can list a few scenarios I am aware of:
- Everything works flawlessly. Hopefully the most likely one
- One of the updates runs into a defined error, which is logged to event log and reflected in registry values. You are not off worse than not trying
- Bitlocker Recovery key required: This can only happen if Bitlocker is used and uses PCR7 in TPM in a key protector. In two possible scenarios:
- (1) Measured Boot cannot properly reseal the PCR after adding key to DB or KEK database.
- (2) One of the variables does not persist on boot, but the PCR has already been resealed to the new value
- In any case, this issue can be totally avoided by suspending Bitlocker before the attempted update for a few reboots. When resuming Bitlocker after the changes has happened and the system rebooted, the new PCR7 value can be obtained and used to re-seal PCR.
- The system freezes/hangs and requires a full power cycle to boot up again (with the old keys). Only a nuisance when deploying the changes remotely.
- The system reboots after apparently having applied the update but one of the values does not persist. As the bootloader is replaced after the first reboot, this will not cause any Secure Boot violations. It may (see above) result in Bitlocker Recovery key as PCR7 has been sealed to new keys but actually present keys are old keys.
- The system reboots, has applied the keys, but the boot fails with a Secure Boot violation due to a firmware bug. In that case, enter Setup, restore the values back to setup defaults, boot up again (again taking care of BitLocker as the PCR7 will not match or was cleared due to the UEFI reset) and best do not try applying the keys before getting the firmware updated (if available)
- The system reboots, but then is "bricked" (freezes on every reboot even before being able to enter the BIOS/UEFI setup). On some old systems, this has been a known, very rarely happening issue for any UEFI variable updates (not just DB/DBX/KEK), when the EFI variable store is almost full. There have been reports about this issue years ago, on very old firmware (think about the age of when Windows 8 came out), only happening very rarely, but if your machine is affected it could have as well happened during a normal DBX update. Probably less likely to encounter this in a corporate environment as machines are newer. And I would assume Microsoft would by now have applied safeguards not to apply any UEFI variables updates (neither DBX updates nor the new Secure Boot Certificate updates) on such devices if the UEFI variable store is almost full.
Hello, I'm looking for some clarity regarding BIOS updates. It is my understanding that if we choose to leverage the REG keys (https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d) to enable updating the Secure Boot Certs via Cumulative Updates, all the required certs will be updated in the Active DB without requiring any BIOS updates. However, this process will NOT update the certs in the Default DB, only a BIOS update can update the Default DB. Is this all correct?
If the above is correct, what would occur in a scenario where the Active DB was updated but BIOS was never flashed, and 6 months after the 2011 certs expire, a device with an old BIOS version (missing 2023 certs) is reset to defaults? I assume since the Default DB was never updated, the device would revert back to the old 2011 certs. If that occurs, would this device still be able to boot/PXE?From my searching this is the basic understanding I have; however, I'm not sure if it's accurate:
Update Mechanism Updates Active DB Updates Default DB Required for long‑term compliance Cumulative Updates (AvailableUpdates opt‑in) ✔ Yes ✘ No Partial – active DB only OEM BIOS Update ✔ Yes (after reset) ✔ Yes Full compliance & future‑proofing
Would it be fair to say ensuring the Active DB is updated before June 2026 is most important, and the Default DB is more of a secondary concern? Essentially I'm just trying to understand the best order of operations here regarding leveraging Cumulative Updates vs BIOS updates to handle this process.As the new bootloader on disk will be signed with 2023 certs, it will deny the boot with a Secure Boot violation. But you can boot external media from "C:\Windows\Boot\EFI\SecureBootRecovery.efi" which will add back (just) the 2023 Windows CA certificate to DB, so that the system can boot again and fix up the rest. In this process, PCR7 sealing of TPM will cause a mismatch (if not already the resetting of the UEFI did so), so if you use Bitlocker sealed against PCR7, you'd also need the Recovery Key. Afterwards, the booted system will restore the rest of the KEK/DB/DBX certificates.
Booting from PXE would also require to boot from a different image (signed with the old keys) and chainloading securebootrecovery.efi.
Microsoft please could you share your list of what computer make/model/firmware qualify as high-confidence devices and which ones do not? e.g. "all Surface Laptop 5s on XXX firmware version are high-confidence" etc.? Please 🙏
We've been told that devices that aren't updated by either June or October will fail to receive updates to the Secure Boot trust stores and Windows Boot Manager respectively during the installation of a cumulative update that contains these changes. What's the experience when the Cumulative Update runs on these devices? Will the CU still install "successfully", but just leave the machines without those changes? Or will the CU fail to install and rollback the entire CU as a result?
So you have delivered reporting in Intune. https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/secure-boot-status-report
Should we expect something similar for Microsoft Configuration Manager that could cover server resources managed by that product?its much needed the reports in SCCM as well.
OHHH NICE - thanks for pointing this out! Feature is present in our tenants, but showing nothing. Yet?
We're getting reports as expected for quality update status (all good), but not for secure boot.Will that populate over the next few days?
Hi community, Chris_Cramp ErnieCosta Dom_Cote
I have updated my earlier posting of questions with available answers / or solutions.-
What is the best way to update WinPE and SCCM OSD Boot medias(Standalone Media and Bootable Media USB and ISO with new cert 2023?
Unable to perform update on Hyper-V VM in test environment
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 2/2/2026 12:34:04 AM
Event ID: 1795
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: ABCDWin11.gpmn.test.com
Description:
The system firmware returned an error The media is write protected. when attempting to update a Secure Boot variable KEK 2023. This device signature information is included here.
DeviceAttributes: FirmwareManufacturer:Microsoft Corporation;FirmwareVersion:Hyper-V UEFI Release v4.1;OEMModelNumber:Virtual Machine;OEMManufacturerName:Microsoft Corporation;OSArchitecture:amd64;
BucketId: 4e22d051e8c143d2875b9d16ef2241c7ec548985a21e5073126d3c1f9bf53bb2
BucketConfidenceLevel: .
This Event ID (1795) is preventing a Hyper-V VM Generation 2 CV 10.0 running the Windows 11 version 25H2 O/S on a Hyper-V Host Server (Dell PowerEdge T140) System, that has successfully updated the BIOS Firmware, and Microsoft 2023 Secure Boot Certificates, and has UEFI and "Secure Boot" turned on within the server configuration settings.
This is a known issue (read the other comments here). Will probably be fixed with cumulative update in March, to be applied to the Hyper-V host. Workaround (if you care) is to suspend bitlocker (if used), and then move the virtual hard disk to a freshly created Gen 2 VM (after updating the host to have the cumulative January patches, if not already done). The freshly created VM will receive the new KEK in the Secure Boot template and the rest of the process can continue.
can we have update if March release CU has fix of Error event ID 1795, as i installed the March CU on Hyper-V host but still getting same event 1795.
