build 7bbbddf7 | content blog-content@c8490fa · 338 posts | profiles 20 · corpus 267 | 0 skipped | | format
apiVersion: soultec.ch/v1kind: Postmetadata: name: ms-secure-boot-cert-expiry-2026 locale: en labels: author: yannick-gerber capability/cloud: 1.94 capability/virtualization: 1.37 vendor/vmware: 0.88 annotations: source: blog-content/posts/en/ms-secure-boot-cert-expiry-2026.md route: /en/insights/ms-secure-boot-cert-expiry-2026/ schema: /nerd/schema/posts.json markdown: /en/insights/ms-secure-boot-cert-expiry-2026.mdspec: 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 sections: - body: | 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) - heading:

What has to happen before June 2026

body: | 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. - heading:

What we recommend

body: | ### **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.status: corpus: 267 alsoLike: - {ref: posts/vcf-full-stack-ab-oktober-2027-mythos-oder-wahrheit, score: 1.00} - {ref: posts/how-to-vlr-9-0-4-bugfix, score: 1.00} - {ref: solutions/vmware/vsphere-foundation, score: 1.00}
{ "apiVersion": "soultec.ch/v1", "kind": "Post", "metadata": { "name": "ms-secure-boot-cert-expiry-2026", "locale": "en", "labels": { "author": "yannick-gerber", "capability/cloud": "1.94", "capability/virtualization": "1.37", "vendor/vmware": "0.88" }, "annotations": { "source": "blog-content/posts/en/ms-secure-boot-cert-expiry-2026.md", "route": "/en/insights/ms-secure-boot-cert-expiry-2026/", "schema": "/nerd/schema/posts.json", "markdown": "/en/insights/ms-secure-boot-cert-expiry-2026.md" } }, "spec": { "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 }, "sections": [ { "body": "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.\n\n[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)" }, { "heading": "

What has to happen before June 2026

",
"body": "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.\n\nAffected: bare-metal and virtualised Windows and Linux installations with Secure Boot enabled." }, { "heading": "

What we recommend

",
"body": "### **HPE**\n\nAffected: bare-metal Windows and Linux installations with Secure Boot active.\n\n#### Do now\n\n1. **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.\n2. **Reset the platform keys** with \"Reset all Keys to Platform Defaults\" once the SPP is updated. This disables Secure Boot.\n3. **Restart the server** after running \"Reset all Keys to Platform Defaults\".\n4. **Enable Secure Boot again** once the reboot succeeds.\n\n📄 Further documentation: [HPE Support – Advisory a00156355en\\_us](https://support.hpe.com/hpesc/public/docDisplay?docId=a00156355en_us&docLocale=en_US)\n\n### VMware\n\nAffected: 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)\n\nSecure Boot arrived with virtual hardware version 13; the PK update needs version 14.\n\nThere is currently no automated way to replace the Secure Boot certificates for VMs. That is expected in an ESX patch.\n\nThe manual route: [https://knowledge.broadcom.com/external/article/423919](https://knowledge.broadcom.com/external/article/423919)\n\nESX hosts with Secure Boot enabled are not affected: [https://knowledge.broadcom.com/external/article/434297](https://knowledge.broadcom.com/external/article/434297)\n\n#### Do now\n\n- **Step 1:** silent PK update for VMs without a vTPM (hardware version 14 or higher)\n- **Step 2:** capsule PK update for vTPM-enabled Windows VMs (hardware version 14 or higher)\n- **Step 3:** manual PK update for vTPM-enabled legacy Windows and Linux VMs (hardware version 14 or higher)\n\nSee [https://knowledge.broadcom.com/external/article/423893](https://knowledge.broadcom.com/external/article/423893)\n\nUpdate 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)\n\nManual PK update through KB 423919 where needed.\n\n- vSphere 7 → plan the upgrade to vSphere 8\n- vSphere 8 → wait for the newest ESX 8 patch\n- vSphere 9 → wait for the 9.1.x patch\n\nAssessment:\n\n- How many VMs have Secure Boot active?\n- What is the virtual hardware version?\n- How many VMs have a vTPM?\n- How many VMs are encrypted with BitLocker or LUKS at guest operating system level?\n- Is any legacy guest OS, one with no updates left, running with Secure Boot?\n\nThe 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)\n\n#### Plan for\n\n- Apply the ESX patch as soon as it is available\n- Update VMware Tools to the newest version\n\n### Veeam\n\nNothing to do for:\n\n- Veeam Hardened Repository (VHR), JeOS\n- Veeam Software Appliance (VSA), JeOS\n- Veeam Proxy Appliances (VPX), JeOS\n\nFor physical Windows-based Veeam servers on HPE, see the HPE recommendations above.\n\nFor Windows installations, follow Microsoft.\n\n### Microsoft\n\n- [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)\n- [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)\n- [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)\n\n# General recommendations\n\nIf 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." } ], "status": { "corpus": 267, "alsoLike": [ { "ref": "posts/vcf-full-stack-ab-oktober-2027-mythos-oder-wahrheit", "score": "1.00" }, { "ref": "posts/how-to-vlr-9-0-4-bugfix", "score": "1.00" }, { "ref": "solutions/vmware/vsphere-foundation", "score": "1.00" } ] }}
apiVersion = "soultec.ch/v1"kind = "Post"[metadata]name = "ms-secure-boot-cert-expiry-2026"locale = "en"[metadata.labels]author = "yannick-gerber""capability/cloud" = "1.94""capability/virtualization" = "1.37""vendor/vmware" = "0.88"[metadata.annotations]source = "blog-content/posts/en/ms-secure-boot-cert-expiry-2026.md"route = "/en/insights/ms-secure-boot-cert-expiry-2026/"schema = "/nerd/schema/posts.json"markdown = "/en/insights/ms-secure-boot-cert-expiry-2026.md"[spec]title = "Microsoft Secure Boot certificates expire in June 2026"date = 2026-05-07author = "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-24translationReviewed = falsedraft = false[[sections]]body = '''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)'''[[sections]]heading = "

What has to happen before June 2026

"
body = '''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.'''[[sections]]heading = "

What we recommend

"
body = '''### **HPE**Affected: bare-metal Windows and Linux installations with Secure Boot active.#### Do now1. **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)### VMwareAffected: 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 patchAssessment:- 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### VeeamNothing to do for:- Veeam Hardened Repository (VHR), JeOS- Veeam Software Appliance (VSA), JeOS- Veeam Proxy Appliances (VPX), JeOSFor 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 recommendationsIf 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.'''[status]corpus = 267[[status.alsoLike]]ref = "posts/vcf-full-stack-ab-oktober-2027-mythos-oder-wahrheit"score = "1.00"[[status.alsoLike]]ref = "posts/how-to-vlr-9-0-4-bugfix"score = "1.00"[[status.alsoLike]]ref = "solutions/vmware/vsphere-foundation"score = "1.00"
<?xml version="1.0" encoding="UTF-8"?><manifest kind="Post"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>ms-secure-boot-cert-expiry-2026</name> <locale>en</locale> <labels> <author>yannick-gerber</author> <entry key="capability/cloud">1.94</entry> <entry key="capability/virtualization">1.37</entry> <entry key="vendor/vmware">0.88</entry> </labels> <annotations> <source>blog-content/posts/en/ms-secure-boot-cert-expiry-2026.md</source> <route>/en/insights/ms-secure-boot-cert-expiry-2026/</route> <schema>/nerd/schema/posts.json</schema> <markdown>/en/insights/ms-secure-boot-cert-expiry-2026.md</markdown> </annotations> </metadata> <spec> <title>Microsoft Secure Boot certificates expire in June 2026</title> <date>2026-05-07</date> <author>yannick-gerber</author> <locale>en</locale> <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.</summary> <capabilities> <item>cloud</item> <item>virtualization</item> </capabilities> <vendors> <item>vmware</item> </vendors> <hero>/blog-assets/ms-secure-boot-cert-expiry-2026/hero.webp</hero> <migrated>2026-08-24</migrated> <translationReviewed>false</translationReviewed> <draft>false</draft> </spec> <sections> <section> <body>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) </body> </section> <section> <heading>

What has to happen before June 2026

</heading>
<body>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. </body> </section> <section> <heading>

What we recommend

</heading>
<body>### **HPE**Affected: bare-metal Windows and Linux installations with Secure Boot active.#### Do now1. **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&amp;docLocale=en_US)### VMwareAffected: 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 patchAssessment:- 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### VeeamNothing to do for:- Veeam Hardened Repository (VHR), JeOS- Veeam Software Appliance (VSA), JeOS- Veeam Proxy Appliances (VPX), JeOSFor 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 recommendationsIf 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. </body> </section> </sections> <status> <corpus>267</corpus> <alsoLike> <item> <ref>posts/vcf-full-stack-ab-oktober-2027-mythos-oder-wahrheit</ref> <score>1.00</score> </item> <item> <ref>posts/how-to-vlr-9-0-4-bugfix</ref> <score>1.00</score> </item> <item> <ref>solutions/vmware/vsphere-foundation</ref> <score>1.00</score> </item> </alsoLike> </status></manifest>
Post · 2026-05-07

Microsoft Secure Boot certificates expire in June 2026

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.

2026-05-07Date
Yannick GerberAuthor
3Min read
Topics Cloud 1.94 Virtualization 1.37
Vendors VMware 0.88

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

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.

You might also like