Microsoft aktualisiert die Zertifikate für Secure Boot die ursprünglich im Jahr 2011 ausgestellt wurden, um sicherzustellen, dass Windows-Systeme weiterhin vertrauenswürdige Startsoftware überprüfen. Diese älteren Zertifikate laufen im Juni 2026 ab.

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

Handlungsbedarf bis Juni 2026

Die Microsoft Secure Boot Zertifikate (KEK CA 2011, UEFI CA 2011, Windows Production PCA 2011) laufen zwischen Juni und Oktober 2026 ab. Bestehende Systeme booten weiterhin, aber zukünftige Sicherheitsupdates für Boot-Komponenten können nicht mehr angewendet werden

Betroffen sind Bare-Metal und virtualisierte Windows und Linux Installationen mit aktiviertem Secure-Boot.

Handlungsempfehlungen

HPE

Betroffen sind Bare-Metal Windows und Linux Installationen mit aktivem Secure Boot:

Sofortige Massnahmen

• 1. SPP aktualisieren auf mindestens Version 2026.01.00.00 – idealerweise direkt auf das aktuellste verfügbare SPP. Das BIOS ROM sollte nicht älter als sechs Monate sein.
  2. Platform Keys zurücksetzen «Reset all Keys to Platform Defaults», sobald das SPP aktualisiert ist. Dadurch wird Secure Boot deaktiviert.
  3. Server neu starten nach Ausführung von «Reset all Keys to Platform Defaults».
  4. Secure Boot wieder aktivieren nach erfolgreichem Reboot.

  📄 Weiterführende Dokumentation: HPE Support – Advisory a00156355en_us

VMware

Betroffen sind VMs, welche SecureBoot aktiv haben. Windows und Linux. Weiter kommt es darauf an, mit welcher virtual HW Version (vmx) die VM erstellt wurde. Siehe Tabelle: https://knowledge.broadcom.com/external/article/423893 

Aktuell gibt es keinen automatisierten Ansatz, die Secure Boot Zertifikate für VMs auszutauschen. Dieser weg wird in einem ESX Patch erwartet.

Manueller Weg: https://knowledge.broadcom.com/external/article/423919 

Weiterführende Infos und VMware FAQ: https://knowledge.broadcom.com/external/article/423893 

Sofortige Massnahmen

VMware Tools und HW-Version updaten (vHW 14+ empfohlen)

Manuelles PK-Update via KB 423919 bei Bedarf

• vSphere 7 → Upgrade auf vSphere 8 planen
• vSphere 8 – warten neusten ESX 8 Patch
• vSphere 9 – warten auf 9.1.x Patch

Assessment:

• Wie viele VMs haben SecureBoot aktiv?
• Wie viele VMs haben einen vTPM?
• Wie viele VMs sind mit Bitlocker oder LUKS verschlüsselt auf GOS (Guest Operating System) Ebene?
• Legacy GOS (wo keine Updates mehr verfügbar sind) mit SecureBoot im Einsatz?

Das Assessment kann einfach via VCF/Aria Operations erfolgen: https://www.brockpeterson.com/post/esxi-host-and-vm-secure-boot-visibility-with-vcf-operations 

Geplante Massnahmen

• ESX Patch sobald verfügbar einspielen
• VMware Tools auf neuste Version aktualisieren

Veeam

Kein Handlungsbedarf bei:

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

Physische Veeam Server auf Basis von Windows mit HPE, siehe die obigen Handlungsempfehlungen von HPE.

Handlungsbedarf bei Windows Installation gemäss 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

Generelle Empfehlungen

Sofern VCF Operations for Logs (loginsight) vorhanden, können auf den Windows Server die Agents ausgerollt werden um nach Event-ID 1801 zu suchen.