The Microsoft KEK CA 2011 and UEFI CA 2011 certificates expired in June 2026, and Windows Production PCA 2011 expires in October 2026. vSphere VMs with UEFI Secure Boot keep booting, but VMs without the Microsoft 2023 certificates can’t take future Secure Boot database updates. The fix is two steps: update the VM’s Platform Key (PK) first, using SilentPK on ESXi 8.0 U3j (P09) and later or Capsule PK on ESX 9.1.1.0 for Windows VMs with vTPM, then update KEK and DB through the guest OS vendor. Broadcom KB 423893 is the source of truth and was last updated on 2 September 2026.
Which Microsoft certificates expire, and when
| Certificate | Expires |
|---|---|
| Microsoft Corporation KEK CA 2011 | June 2026 |
| Microsoft Corporation UEFI CA 2011 | June 2026 |
| Microsoft Windows Production PCA 2011 | October 2026 |
What happens to VMs after the certificates expire
The VMs continue to boot. The impact is that a VM whose KEK and DB don’t contain the Microsoft 2023 certificates can’t apply future Secure Boot database updates, which can block Secure Boot-related security updates in the guest. Guest OS updates that don’t depend on these databases keep working.
Which VMs are affected
- VM hardware version 13 or newer (Secure Boot starts at version 13)
- UEFI Secure Boot enabled
- KEK and DB without the Microsoft 2023 certificates: typically VMs on hardware version 13, VMs created on ESXi hosts earlier than 8.0 U2, or VMs deployed from templates that carry an old NVRAM
VMs on hardware version 13 need an upgrade to version 14 or later before their PK can be updated.
How to find affected VMs
- Fleet-wide: KB 423893 attaches PowerCLI scripts (
SecureBootExportVMList.ps1,SecureBootExportVMListv2.ps1) that export Secure Boot and vTPM status for all VMs. - Inside a Windows guest:
Get-SecureBootUEFI -Name PK - Inside a Linux guest:
mokutil --pk - vCenter and ESX 9.1.1.0: the alarm “Virtual Machine UEFI Secure Boot Platform Key is out of date. Refer KB 423893” flags affected VMs.
KB 423893 remediation by ESXi version: 8.0 U3j (P09), 9.0 and 9.1.1
| Secure Boot | vTPM | ESX 7.x, ESXi 8.0 U3i (P08) and earlier | ESXi 8.0 U3j (P09) | ESX 9.0.x / 9.1.0 | ESX 9.1.1.0 and later |
|---|---|---|---|---|---|
| Disabled | Disabled | No action | SilentPK update (optional) | SilentPK update (optional) | SilentPK update (optional) |
| Enabled | Disabled | Manual update from the vUEFI interface | SilentPK update | SilentPK update | SilentPK update |
| Enabled | Enabled | Manual update from the vUEFI interface | Manual update from VMX configuration (preferred for non-Windows VMs) | Manual update from VMX configuration (non-Windows VMs) | Capsule PK update (Windows) / manual VMX update (non-Windows) |
| Disabled | Enabled | No action | No action | No action | No action |
Source: KB 423893, as of its 2 September 2026 update. ESX 7.x gets only the manual vUEFI method; no automated fix is planned for it.
SilentPK vs Capsule PK
- SilentPK update (ESXi 8.0 U3j and later): the hypervisor adds the missing Windows OEM Devices PK certificate automatically during a guest reboot or VM power cycle. No guest OS action is needed. It is used for VMs without vTPM.
- Capsule PK update (ESX 9.1.1.0 and later, Windows): an OS-coordinated firmware update that changes the PK during a guest reboot while preserving vTPM measurements, so BitLocker and other vTPM-dependent features don’t lock you out. It requires VMware Tools 13.1.5 or later and the July 2026 Windows cumulative update (earlier for Windows Server 2025 and Windows 11 24H2/25H2).
The order that matters
- Patch hosts to ESXi 8.0 U3j (P09), or to ESX 9.1.1.0 if you have Windows VMs with vTPM.
- Update the Platform Key first, with SilentPK, Capsule PK or the manual method from the table.
- Then update KEK and DB following the guest OS vendor’s guidance.
Related: this article is about guest (VM) Secure Boot. For host-level Secure Boot on Cisco UCS, see how to run the Secure Boot validation script on an ESXi host.
