--- # source: blog-content: posts/en/ms-secure-boot-cert-expiry-2026.md # route: /en/insights/ms-secure-boot-cert-expiry-2026/ title: Microsoft Secure Boot certificates expire in June 2026 date: 2026-05-07 author: yannick-gerber locale: en summary: Microsoft is refreshing the Secure Boot certificates originally issued in 2011, so Windows systems keep verifying trusted boot software. The old ones expire in June 2026. capabilities: [cloud, virtualization] vendors: [vmware] hero: /blog-assets/ms-secure-boot-cert-expiry-2026/hero.webp migrated: 2026-08-24 translationReviewed: false draft: false --- 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](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](https://support.hpe.com/hpesc/public/docDisplay?docId=a00156355en_us&docLocale=en_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](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](https://knowledge.broadcom.com/external/article/423919) ESX hosts with Secure Boot enabled are not affected: [https://knowledge.broadcom.com/external/article/434297](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](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](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](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://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-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](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.