Microsoft is refreshing the Secure Boot certificates originally issued in 2011, so that Windows systems keep verifying trusted boot software. Those older certificates expire in June 2026.

https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789

What has to happen before June 2026

The Microsoft Secure Boot certificates (KEK CA 2011, UEFI CA 2011, Windows Production PCA 2011) expire between June and October 2026. Existing systems keep booting, but future security updates for boot components can no longer be applied.

Affected: bare-metal and virtualised Windows and Linux installations with Secure Boot enabled.

What we recommend

HPE

Affected: bare-metal Windows and Linux installations with Secure Boot active.

Do now

1. Update the SPP to at least version 2026.01.00.00, ideally straight to the newest available SPP. The BIOS ROM should not be older than six months.
2. Reset the platform keys with “Reset all Keys to Platform Defaults” once the SPP is updated. This disables Secure Boot.
3. Restart the server after running “Reset all Keys to Platform Defaults”.
4. Enable Secure Boot again once the reboot succeeds.

📄 Further documentation: HPE Support – Advisory a00156355en_us

VMware

Affected: VMs with Secure Boot active, Windows and Linux. It also depends on which virtual hardware version (vmx) the VM was created with. See the table: https://knowledge.broadcom.com/external/article/423893

Secure Boot arrived with virtual hardware version 13; the PK update needs version 14.

There is currently no automated way to replace the Secure Boot certificates for VMs. That is expected in an ESX patch.

The manual route: https://knowledge.broadcom.com/external/article/423919

ESX hosts with Secure Boot enabled are not affected: https://knowledge.broadcom.com/external/article/434297

Do now

• Step 1: silent PK update for VMs without a vTPM (hardware version 14 or higher)
• Step 2: capsule PK update for vTPM-enabled Windows VMs (hardware version 14 or higher)
• Step 3: manual PK update for vTPM-enabled legacy Windows and Linux VMs (hardware version 14 or higher)

See https://knowledge.broadcom.com/external/article/423893

Update VMware Tools and the hardware version (vHW 14 or higher recommended), see https://knowledge.broadcom.com/external/article/315390/upgrading-a-virtual-machine-to-the-lates.html

Manual PK update through KB 423919 where needed.

• vSphere 7 → plan the upgrade to vSphere 8
• vSphere 8 → wait for the newest ESX 8 patch
• vSphere 9 → wait for the 9.1.x patch

Assessment:

• How many VMs have Secure Boot active?
• What is the virtual hardware version?
• How many VMs have a vTPM?
• How many VMs are encrypted with BitLocker or LUKS at guest operating system level?
• Is any legacy guest OS, one with no updates left, running with Secure Boot?

The assessment is straightforward with VCF/Aria Operations: https://www.brockpeterson.com/post/esxi-host-and-vm-secure-boot-visibility-with-vcf-operations

Plan for

• Apply the ESX patch as soon as it is available
• Update VMware Tools to the newest version

Veeam

Nothing to do for:

• Veeam Hardened Repository (VHR), JeOS
• Veeam Software Appliance (VSA), JeOS
• Veeam Proxy Appliances (VPX), JeOS

For physical Windows-based Veeam servers on HPE, see the HPE recommendations above.

For Windows installations, follow Microsoft.

Microsoft

• https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789#community-4495789-_step3
• https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f
• https://support.microsoft.com/en-gb/topic/original-equipment-manufacturer-oem-pages-for-secure-boot-9ecc3ba4-fb50-4bd3-9e9b-f16b35b8fb68

General recommendations

If VCF Operations for Logs (Log Insight) is in place, the agents can be rolled out to the Windows servers to look for event ID 1801.