Secure-Boot-Zertifikat abgelaufen: Was 2026 zu tun ist

Am 19. Oktober 2026 ist mit der „Microsoft Windows Production PCA 2011“ das letzte der drei Secure-Boot-Zertifikate aus dem Jahr 2011 abgelaufen. Die beiden anderen waren schon im Juni fällig. Die meisten Rechner starten weiterhin ganz normal, und genau deshalb fällt das Thema leicht unter den Tisch. Dieser Beitrag fasst den Stand der Secure-Boot-Zertifikate 2026 für IT-Verantwortliche zusammen: was tatsächlich passiert ist, welche Geräte betroffen sind und wie Sie prüfen, ob Ihre PCs, Server und virtuellen Maschinen die neuen Zertifikate von 2023 haben.

Was ein Secure-Boot-Zertifikat ist

Secure Boot ist eine Funktion der UEFI-Firmware, also der modernen Nachfolgerin des BIOS. Sie stellt sicher, dass beim Start nur signierte, vertrauenswürdige Software geladen wird, bevor Windows überhaupt läuft. Dazu speichert die Firmware mehrere Zertifikatslisten: die KEK (Key Exchange Key), mit der Änderungen an den Listen autorisiert werden, die DB mit erlaubten Signaturen und die DBX mit gesperrten Signaturen. Ganz oben steht der Plattformschlüssel (Platform Key, PK) des Geräteherstellers, der Änderungen an der KEK autorisiert.

Microsoft hat 2011 die Zertifikate ausgestellt, mit denen Windows-Bootloader und Bootkomponenten von Drittanbietern signiert werden. Diese Zertifikate hatten ein festes Ablaufdatum. Laut Microsoft gelten folgende Termine:

Options-ROMs sind kleine Firmware-Programme auf Erweiterungskarten, etwa auf Grafikkarten, Netzwerk- oder RAID-Controllern.

Was nach dem Ablauf passiert und was nicht

Microsoft stellt klar: Geräte ohne die neuen Zertifikate starten weiter und erhalten weiterhin die normalen Windows-Updates. Es gibt also keinen Stichtag, an dem Rechner plötzlich nicht mehr hochfahren.

Die Folge ist subtiler. Geräte ohne die 2023er-Zertifikate können keine neuen Schutzmaßnahmen für den frühen Startvorgang mehr erhalten. Dazu gehören Updates des Windows-Bootmanagers, neue Einträge in der Sperrliste DBX und Korrekturen für künftig entdeckte Schwachstellen im Bootprozess. Microsoft weist darauf hin, dass dies mit der Zeit auch Funktionen betreffen kann, die auf Secure Boot aufbauen, etwa die Härtung von BitLocker oder Bootloader von Drittanbietern.

Betroffen ist vor allem der Schutz gegen Angriffe auf den Startvorgang, die sogenannten Bootkits.

Welche Geräte betroffen sind

Betroffen sind grundsätzlich alle Geräte mit aktiviertem Secure Boot, die noch die 2011er-Zertifikate verwenden. Microsoft nennt Windows 10 und Windows 11 in den unterstützten Versionen sowie Windows Server 2016, 2019, 2022 und 2025, außerdem Windows Server 2012 und 2012 R2 im Rahmen erweiterter Sicherheitsupdates.

Nach Angaben von Microsoft erhalten die meisten Windows-Geräte die neuen Zertifikate automatisch über Windows Update. Bei manchen Geräten verhindert jedoch die Firmware das Einspielen, oder Microsoft stuft die Gerätegruppe noch nicht als sicher genug für die automatische Verteilung ein. Genau diese Geräte müssen Sie finden.

So prüfen Sie, ob das Secure-Boot-Zertifikat aktualisiert ist

Windows-Sicherheit-App

Auf Windows 11, Windows 10 und Windows Server 2019 bis 2025 zeigt die App „Windows-Sicherheit“ unter „Gerätesicherheit“ und „Sicherer Start“ den Zertifikatsstatus an. Grün bedeutet vollständig aktualisiert. Auf verwalteten Unternehmensgeräten und Servern sind die zugehörigen Hinweise und Benachrichtigungen standardmäßig ausgeblendet. Für Stichproben genügt die App, für viele Geräte brauchen Sie die folgenden Methoden.

Registrierung

Der zuverlässigste Einzelwert steht unter `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing` im Wert `UEFICA2023Status`. Er durchläuft die Zustände „NotStarted“, „InProgress“ und „Updated“. Der Wert `UEFICA2023Error` sollte 0 sein. Diese Werte lassen sich per Skript, über Ihr Inventarisierungswerkzeug oder per Intune-Bericht flächendeckend auslesen.

Ereignisprotokoll

Im Systemprotokoll meldet die Quelle „TPM-WMI“ den Fortschritt:

Vorher Secure Boot selbst prüfen

Mit dem PowerShell-Befehl `Confirm-SecureBootUEFI` oder in den Systeminformationen (msinfo32) unter „Sicherer Startzustand“ sehen Sie, ob Secure Boot überhaupt aktiv ist. Geräte, die im alten BIOS-Modus starten oder Secure Boot deaktiviert haben, nutzen die Zertifikate nicht. Erfassen Sie solche Geräte bei dieser Gelegenheit gleich mit.

Secure-Boot-Zertifikat erneuern: die Verteilung selbst steuern

Wer Updates zentral verwaltet, kann die Aktualisierung gezielt anstoßen, über Gruppenrichtlinie, Intune oder einen Registrierungswert. Microsoft dokumentiert für Unternehmensbereitstellungen den Wert `AvailableUpdates` mit 0x5944 unter `HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot`. Eine geplante Aufgabe namens „Secure-Boot-Update“ führt die Aktualisierung dann aus, Teile davon werden erst nach einem Neustart wirksam.

Gehen Sie stufenweise vor: zuerst eine kleine Testgruppe mit jedem verwendeten Gerätemodell, dann die breite Verteilung. Sichern Sie vorher die BitLocker-Wiederherstellungsschlüssel, denn Änderungen am Startvorgang und Firmware-Updates können eine Abfrage des Schlüssels auslösen. Wie Sie Windows-Updates generell in Ringen ausrollen, beschreibt der Beitrag Windows-Updates steuern.

Die Rolle der Hardwarehersteller

Windows kann die neuen Zertifikate nur schreiben, wenn die Firmware das zulässt. Bei einem Teil der Geräte, häufig bei älteren Modellen, ist dafür zuerst ein UEFI- oder BIOS-Update des Herstellers nötig. Microsoft verweist ausdrücklich darauf, dass viele Hersteller entsprechende Firmware-Updates bereitstellen.

Für die Praxis heißt das: Prüfen Sie für jedes Gerätemodell mit Ereignis 1795 oder dauerhaft „InProgress“ die Support-Seite des Herstellers. Geräte, für die keine Firmware mehr erscheint, gehören auf die Liste für den nächsten Austausch. Bei Servern sollten Firmware-Updates ohnehin Teil des regulären Wartungsfensters sein.

Server und virtuelle Maschinen nicht vergessen

Physische Server folgen denselben Regeln wie PCs, inklusive Firmware-Abhängigkeit. Häufig übersehen werden virtuelle Maschinen. Deren UEFI-Firmware wird vom Hypervisor bereitgestellt, und dort gab es eigene Hürden.

Hyper-V

Bei Hyper-V-VMs der Generation 2 schlug die KEK-Aktualisierung zeitweise mit Ereignis 1795 und der Meldung „Das Medium ist schreibgeschützt“ fehl. Microsoft hat das Problem als gelöst markiert: Die Korrektur steckt in den Windows-Updates vom 10. März 2026, für Windows Server 2025 vom 14. April 2026, und muss sowohl auf dem Host als auch in der VM installiert sein. Hosts mit älterem Patchstand sind deshalb ein typischer Grund, warum VMs nicht vorankommen.

VMware

Broadcom beschreibt für vSphere ein grundsätzliches Problem: Viele VMs, die auf älteren ESXi-Versionen angelegt oder aus solchen Vorlagen erzeugt wurden, haben keinen gültigen Plattformschlüssel. Ohne ihn lässt sich die KEK nicht aktualisieren. Die VMs starten laut Broadcom weiterhin, können aber keine künftigen DB- und DBX-Updates empfangen. Die DB-Zertifikate von 2023 lassen sich dagegen schon jetzt einspielen. Für den Plattformschlüssel stellt Broadcom je nach ESXi-Version automatisierte oder manuelle Verfahren bereit, für vSphere 7 nur manuelle. Manuelle Eingriffe können eine BitLocker-Wiederherstellung auslösen, eine Sicherung vorher ist Pflicht. Prüfen Sie die Broadcom-Hinweise für Ihre konkrete Version.

Denken Sie auch an Vorlagen und Golden Images: Eine VM, die aus einer veralteten Vorlage erzeugt wird, startet mit dem alten Zustand.

Checkliste / Erste Schritte

Wie DAVINCI unterstützt

Wir erfassen für Sie den Secure-Boot-Status aller Geräte, Server und VMs, planen Firmware-Updates in Wartungsfenstern ein und kümmern uns um Sonderfälle bei Hyper-V und VMware. Im Rahmen unserer IT-Betreuung über Fernwartung behalten wir solche Themen dauerhaft im Blick. Sprechen Sie uns über das Kontaktformular an.

Verwandte Themen: Wer hier weiterdenkt, liest bei Firmware-Update, Windows-Server-Planung und Windows Server 2025 weiter.