After applying Microsoft’s Secure Boot certificate updates on Windows Server 2025 virtual machines, the update may appear to succeed but the new certificates never activate. This issue is commonly seen on VMware VMs using older compatibility versions or affected by a known KEK firmware limitation.
This post walks through:
- How the Secure Boot update process is supposed to work
- Symptoms when it fails
- Why VMware blocks the update
- The exact steps required to fix it
How the Secure Boot Certificate Update Should Work
Microsoft distributes the updated Secure Boot certificates to the OS through Windows Update. On Windows Server systems, however, the certificates are not automatically installed. You must manually trigger the update process.
Step 1 – Stage the Secure Boot Update by adding the following reg key:
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot” /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Step 2 – Run the Scheduled Task to apply the update:
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
Step 3 – Reboot the Server
Step 4 – Verify the certificates are updated.
You can do this in the registry – UEFICA2023Status should be Updated and WindowsUEFICA2023Capable should be 2 as shown below:
The Problem
After performing the update steps and rebooting the Windows Server 2025 VM the registry showed:
UEFICA2023Status = NotStartedWindowsUEFICA2023Capable = 0
This indicates the Secure Boot certificate is missing. In this particular case there were 2 issues preventing the certificate update.
Issue #1 – The VM hardware compatibility version was too old.
According to Broadcom documentation, the VM must be running:
- VMware compatibility version 21
- ESXi 8.0 Update 2 or later
Older VM compatibility versions prevent the Secure Boot certificate update from completing correctly.
If your VMWare environment is at ESXi 8.0 Update 2 or later you can easily fix this by shutting down the VM, right click and select Compatibility, Upgrade VM Compatibility, and select the latest version. Power up your VM and you should be all set.
In my case after rerunning the Secure-Boot-Update scheduled task and rebooting the registry showed:
UEFICA2023Status = InProgressWindowsUEFICA2023Capable =1
This means that the 2023 certificate is present in the UEFI DB but the active boot manager is not using it.
Additional investigation lead to an Event Log error: “PK signed Key Exchange Key (KEK) cannot be found for this device”
Issue #2 – VMWare Known Virtual Firmware Limitation
Broadcom published an article outlining the steps to bypass this limitation by manually updating the KEK certificate.
- Shutdown the VM
- Edit the VM Settings and add an Advanced Parameter: uefi.allowAuthBypass = “TRUE”
- Add a 128mb disk to the VM
- Boot into Windows and format the new disk as FAT32 and give it a name so you know which one it is later.
- Download the Microsoft KEK Certificate from https://go.microsoft.com/fwlink/?linkid=2239775
- Change the extension on the certificate to .der
- Copy the certificate to the FAT32 disk
- Power down the VM
- Edit the VM Settings, VM Options and check the Force EFI Setup box
- Power on the VM
- The uefi.allowAuthBypass parameter will expose the Secure Boot Configuration menu option – selec that.
- Go to KEK Options
- Go to Enroll KEK
- Select the disk that you formatted as FAT32
- The KEK certificate will automatically be selected.
- Commit Changes and Exit
- Exit
- Boot back into Windows
Now when you check the registry again it should look like this:
UEFICA2023Status = UpdatedNotStartedWindowsUEFICA2023Capable =2
You can also issue the following command to check the certificate – you should see the 2023 KEK cert listed:
Get-SecureBootUEFI -Name KEK -Decoded
Don’t Forget to Cleanup
- Shutdown the VM
- Remove the VMWare advanced parameter you added
- Remove the FAT32 disk and data
- Power it back up
- Get the Shirt:
https://shop.it-adventures.com/products/its-always-something-funny-computer-humor-shirt