For vSphere 7 there shall be no fix.
To get it working, you must copy the MS PK & KEK Cert to a small fat32 Disk.vmdk and use this disk later in EFI - Setup for each VM.
The fix with deleting the .nvram file resulted in my cluster in non-bootable VMs, so i figured out other ways to resolve this...
The procedure here (in german, translation by yourself):
Update der Microsoft UEFI 2023 Zertifikate in VMware 7.0.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Snapshot der VM erstellen
*2. erweiterte Optionen -> uefi.allowAuthBypass = "TRUE"
und Force EFI Setup aktivieren
*3. die Disk (.vmdk) mit dem PK an die VM hängen und ins Setup Booten
Disk liegt in vorlagen -> 1ueficert -> admin-2413-02.scc.uni-weimar.de_2.vmdk
4. UEFI Setup -> Secure Boot Optionen ->
Enroll PK -> das PK Cert von der Disk auswählen
Enroll KEK -> das KEK Cert von der Disk auswählen
5. Windows Booten und Registry Key setzen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot -> HEX 0x5944
oder(!): ausführen winCsFlags.exe /apply --key "F33E0C8E002"
6. nach circa 10 Minuten prüfen (PS als Admin):
Get-UEFISecureBootCerts db | select SignatureSubject
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing |
>> select WindowsUEFICA2023Capable, UEFICA2023Status, `
>> @{n="UEFICA2023Error";e={'0x' + '{0:x}' -f $_.UEFICA2023Error}}
Get-WinEvent -ProviderName Microsoft-Windows-TPM-WMI -MaxEvents 10 |
where Level -eq 2 | Format-List TimeCreated, LevelDisplayName, Id, Message
*7. aufräumen:
die Disk wieder abhängen und die Advanced Option entfernen / false setzen
Wenn alles OK ist, sollte es so aussehen:
PS C:\WINDOWS\system32> Get-UEFISecureBootCerts db | select SignatureSubject
SignatureSubject
----------------
O="VMware, Inc.", L=Palo Alto, S=California, C=US
CN=VMware Secure Boot Signing, O="VMware, Inc.", L=Palo Alto, S=California, C=US
CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
True
PS C:\WINDOWS\system32> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing |
>> select WindowsUEFICA2023Capable, UEFICA2023Status, `
>> @{n="UEFICA2023Error";e={'0x' + '{0:x}' -f $_.UEFICA2023Error}}
WindowsUEFICA2023Capable UEFICA2023Status UEFICA2023Error
------------------------ ---------------- ---------------
2 Updated 0x
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
https://www.windowspro.de/wolfgang-sommergut/update-secure-boot-zertifikate-fuer-windows-server-virtuelle-maschinenhttps://knowledge.broadcom.com/external/article/423919https://support.microsoft.com/de-de/topic/registrierungsschl%C3%BCsselupdates-f%C3%BCr-den-sicheren-start-windows-ger%C3%A4te-mit-it-verwalteten-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards Steffen Ille
Original Message:
Sent: 3/9/2026 7:03:00 AM
From: azuser
Subject: RE: UEFI and Secure boot cert update
I am testing the Secure Boot certificate transition steps. According to the KB article, we should load WindowsOEMDevicesPK.der as part of the process.
However, on a test VM I have not loaded WindowsOEMDevicesPK.der, but when I run the following command inside Windows:
I can still see UEFI CA 2023 certificate details.
This VM is running Windows Server with Secure Boot enabled on VMware ESXi 7.
I am curious why the 2023 certificate is already present even though I did not manually load the file described in the KB article.
Has anyone seen this behavior or knows if the certificate may already be included by default in the firmware or Windows Secure Boot updates?
-------------------------------------------
Original Message:
Sent: Mar 09, 2026 01:00 AM
From: snapfriend
Subject: UEFI and Secure boot cert update
I tested on my test machine where VMware hardware version is on older version & below command shows value as "True"
Type, in PowerShell -> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
My value is "True" on Older VMware hardware version (vmx-19 -> ESXi 7.0 U2 (7.0.2)) & then Microsoft steps performed as mentioned below
- reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
- Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
- Manually reboot the system when the AvailableUpdates becomes 0x4100
- Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
It makes Secure Boot Certificate as updated with event code "1799" & message as "Boot Manager signed with Windows UEFI CA 2023 was installed successfully" in Windows SYSTEM events.
You can test it in your environment & test the scenario.
Original Message:
Sent: Mar 08, 2026 11:03 PM
From: snapfriend
Subject: UEFI and Secure boot cert update
If you have VMs with older Hardware version & Secure boot enabled then test it on your devices or virtual machines.
It is found that older VMware Hardware version also having below command as output as "True"
Command -> :
Type, in PowerShell -> ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
So, VMware Hardware version to the latest is not required in above scenarios. Below is the new article or in Microsoft community page with AI assisted Answers
https://learn.microsoft.com/en-my/answers/questions/5804878/how-to-manually-force-apply-updated-secure-boot-ce
But it is good to test in with your environment on test servers where you can play with that machines. Make sure that you have full backup & Snapshot taken in advance.
I will suggest to have above steps mentioned by you is still relevant & to make your environment with stable & latest VMware Hardware Version as the priority. You have a chance to make this upgrade during this crucial time as well.
One more thing, Windows Secure Boot Certificate expiry is only applied to Secure Boot enabled machines. So, if you have disabled machines the read about it as well.
Many things are going on internet but having latest update or action item is necessity. So, it needs to be explored & tested in your environment & make the solution worked as expected.