secure boot certificate update fails on vmware virtual machines

This might be more helpful for you if you are still fighting the issue.

https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html

Hello.

First, could you check whether any error code appears when the issue occurs? Having that information would be very helpful.

Based on your description, I'd guess the memory error is likely caused by the virtual NVRAM being too small to accommodate the updated, larger DBX revocation list provided by Microsoft. This situation commonly triggers error code 0x80070008, as UEFI variable storage on virtual hardware versions earlier than version 20 does not have sufficient capacity for these security updates.

To resolve this issue, you should upgrade your virtual machine compatibility to hardware version 20 or later, which is supported on ESXi 8.0 and newer. This upgrade increases the available storage for EFI variables.

You can verify whether the update was successful by checking the Microsoft-Windows-SecureBoot/Operational event log, specifically Event ID 103, to confirm that the variable was written successfully.

If you find my answer useful, please mark it as the "Accepted Answer" so other members can find the solution easily. Your help in supporting the community is much appreciated!

Best regards,

Scott

For Windows guests running on VMware, Secure Boot certificate updates work the same way as on physical hardware, but success depends on how the virtual firmware handles Secure Boot variables.

From the available guidance, there are two supported ways to get the new Secure Boot certificates into virtual machines:

1. Let the virtualization platform provide updated virtual firmware
   • The virtualization platform (such as VMware) can ship updated virtual UEFI firmware that already contains the new Secure Boot certificates.
   • This approach typically applies to newly created VMs that use the updated firmware image.
2. Apply the Secure Boot certificate updates from inside the guest OS
   • For long‑lived Windows VMs, the Secure Boot certificate updates can be applied through normal Windows updates and the Secure Boot update mechanism, if the virtual firmware supports updating Secure Boot variables (DB, KEK, etc.).
   • In IT‑managed environments, this can be orchestrated via Group Policy using the Secure Boot GPO method:
     • Use the policy under Computer Configuration → Administrative Templates → Windows Components → Secure Boot to control deployment of the Secure Boot certificate updates.
     • Validate on a representative VM of each type before broad rollout.
     • After validation, group devices by bucket hash and roll out in stages.

If failures are occurring on VMware VMs with errors that look like firmware or memory issues when updating Secure Boot variables, the relevant guidance is:

• When Windows hands the new certificates to firmware to write into the Secure Boot DB or KEK, some firmware implementations can return errors instead of accepting the update.
• In such cases, Secure Boot logs Event ID 1795 indicating a firmware error during DB/KEK update.
• The recommended next step is to check with the platform/OEM (in this case, VMware or the underlying host vendor) for updated firmware or platform updates that fix Secure Boot variable handling.

Actionable steps:

1. On an affected VM, open Event Viewer → Applications and Services Logs → Microsoft → Windows → TPM-WMI and Microsoft → Windows → Secure-Boot-Update (if present) and confirm whether Event ID 1795 is logged when the update runs.
2. If Event ID 1795 or similar firmware‑related errors appear:
   • Treat this as a virtual firmware limitation/bug rather than a GPO misconfiguration.
   • Check with VMware for:
     • Updated virtual hardware/firmware versions that improve Secure Boot variable support.
     • Any documented fixes or host patches related to Secure Boot certificate updates.
3. Keep the Secure Boot GPO in place for the VMs, but only after validating on a test VM that:
   • The certificates are successfully written to the UEFI DB and KEK.
   • No further Event ID 1795/1796 errors occur.

If the VMware virtual firmware cannot reliably update Secure Boot variables, the only durable fix will be a platform/firmware update from VMware (or the host OEM) so that the guest’s Secure Boot DB/KEK can be updated correctly.

References:

• Frequently asked questions about the Secure Boot update process
• Secure Boot certificate updates: Guidance for IT professionals and organizations
• Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates
• Initialize result object in preparation for checking Secure Boot state