Veröffentlicht im Juni 2026 · Lesezeit: ca. 8 Minuten
Das Problem in einem Satz
Microsoft tauscht im Jahr 2026 zentrale UEFI-Sicherheitszertifikate aus — und PCs, die das dazugehörige Update nicht erhalten haben, könnten eines Tages einfach nicht mehr starten. Der kritische Moment ist nicht das Ablaufdatum des Zertifikats selbst, sondern der Tag, an dem Microsoft die alten Zertifikate aktiv sperrt.
Was ist Secure Boot — und warum ist das jetzt relevant?
Secure Boot ist eine Schutzfunktion, die in nahezu jedem modernen PC und Laptop aktiviert ist. Sie stellt sicher, dass beim Systemstart ausschließlich vertrauenswürdige Software geladen wird. Konkret prüft die UEFI-Firmware bereits vor dem Laden des Betriebssystems, ob der Windows Boot Manager digital signiert und das verwendete Zertifikat in der eigenen Vertrauensliste (db) hinterlegt ist.
Diese Architektur schützt unter anderem vor dem sogenannten Bootkit-Angriff — Schadsoftware, die sich so tief ins System einnistet, dass sie selbst nach einer Windows-Neuinstallation überlebt. Bekannte Beispiele sind BlackLotus (2022–2023), das genau diese Angriffsfläche ausgenutzt hat.
Was läuft 2026 ab — und warum ist das gefährlich?
Die Zertifikate, mit denen Microsoft seit 2011 Bootloader und UEFI-Komponenten signiert hat, haben ein Verfallsdatum:
| Zertifikat | Ablaufdatum |
|---|---|
| Microsoft Corporation UEFI CA 2011 | 27. Juni 2026 |
| Microsoft Corporation KEK CA 2011 | 24. Juni 2026 |
| Microsoft Windows Production PCA 2011 | 19. Oktober 2026 |
Microsoft hat Nachfolger vorbereitet: die 2023er Zertifikatsfamilie (Windows UEFI CA 2023, Microsoft UEFI CA 2023, KEK 2K CA 2023). Diese werden seit Ende 2024 schrittweise über Windows Update ausgerollt.
Aber: Das Ablaufdatum allein bricht nichts
Ein verbreitetes Missverständnis — das auch in der ersten Berichterstattung zu diesem Thema kursierte — ist die Annahme, dass ein PC am Tag des Zertifikatsablaufs nicht mehr bootet. Das ist so nicht korrekt.
Wie das Fachmagazin c’t in der Ausgabe 13/2026 ausführlich analysiert hat (Axel Vahldiek, „Sicherer Start in der Krise“), sichern sogenannte Timestamp-Zertifikate die bestehenden Bootloader weiterhin ab — auch wenn das übergeordnete CA-Zertifikat formal abgelaufen ist. Ein signierter Bootloader bleibt gültig, solange der Zeitstempel seiner Signatur vor dem CA-Ablauf liegt.
Das echte Risiko: Die dbx-Sperrliste
Das eigentliche Risiko entsteht an einem anderen Punkt: der dbx-Datenbank (Forbidden Signature Database). Diese Liste enthält Zertifikate, die Secure Boot aktiv verweigert — selbst wenn sie früher in der Erlaubnisliste standen.
Microsoft hat nach dem BlackLotus-Vorfall begonnen, verwundbare und kompromittierte Bootloader über die dbx zu sperren. Irgendwann — ein genaues Datum ist öffentlich nicht bekannt — werden die alten 2011er Zertifikate dort eingetragen. Ab diesem Moment werden alle PCs, die noch mit alten Bootloadern und ohne neue 2023er Zertifikate arbeiten, beim nächsten Start von der UEFI-Firmware blockiert.
Das ist kein theoretisches Szenario: Microsoft hat im Rahmen von KB5025885 bereits eine Methode veröffentlicht, um die neuen Zertifikate manuell einzuspielen — ein Hinweis darauf, dass die Sperrung der alten Certs konkret geplant ist.
PKfail: Das unterschätzte zweite Problem
Parallel zur Zertifikatsmigration existiert ein weiteres, strukturelles Sicherheitsproblem: PKfail.
Zahlreiche Gerätehersteller haben Mainboards mit einem internen AMI- oder Phoenix-Testzertifikat im sogenannten Platform Key (PK) ausgeliefert — dem Wurzelzertifikat der gesamten Secure-Boot-Vertrauenskette. Diese Zertifikate tragen Bezeichnungen wie „DO NOT TRUST“ oder „DO NOT SHIP“ und waren ausschließlich für interne Entwicklungszwecke vorgesehen.
Ist ein solches Testzertifikat als PK eingetragen, ist die gesamte Secure-Boot-Kette kompromittiert: Ein Angreifer mit dem passenden privaten Schlüssel (der durch ein Datenleck 2023 öffentlich wurde) könnte beliebige Bootloader signieren und damit Secure Boot vollständig aushebeln.
Betroffen sind Geräte zahlreicher namhafter Hersteller. Eine vollständige Liste ist unter https://pk.fail einsehbar.
Was bedeutet das konkret für IT-Verantwortliche?
Für Unternehmensumgebungen und IT-Dienstleister ergeben sich daraus klare Aufgaben:
Sofortmaßnahme: Überprüfen, ob alle Windows-PCs die neuen 2023er UEFI-Zertifikate erhalten haben. Das ist nicht mit einem einfachen Blick in die Systemsteuerung möglich — die UEFI-Variablen liegen in einem Binärformat, das erst ausgelesen und geparst werden muss.
Risikobewertung: PCs priorisieren, bei denen die neuen Zertifikate fehlen, die Windows-Version veraltet ist (Windows 10 oder Windows 11 vor 24H2 erhalten keine kostenlosen Sicherheitsupdates mehr) oder bei denen PKfail erkannt wurde.
Manuelle Eskalation: Für PCs, bei denen Windows Update die Zertifikate nicht automatisch einspielt, hat Microsoft mit KB5025885 eine manuelle Methode dokumentiert. Vor deren Anwendung muss bei BitLocker-verschlüsselten Laufwerken der Wiederherstellungsschlüssel gesichert werden.
Meine Lösung: Ein PowerShell-Diagnoseskript
Um diese Prüfung systematisch und skalierbar durchführen zu können, habe ich ein PowerShell-Skript entwickelt, das alle relevanten Parameter in einem Durchlauf prüft und bewertet.
Das Skript prüft:
- Secure Boot Status und Windows-Version (Updatefähigkeit)
- Alle UEFI-Zertifikate in
dbundKEKmit Ablaufdaten dbx-Sperrliste: Sind 2011er Zertifikate bereits aktiv geblockt?- PKfail: Testzertifikat im Platform Key?
- Boot Manager: Signatur und CA-Kette
- Ausstehende Windows Updates
Das Ergebnis:
Das Skript gibt eine klare Risikobewertung aus (OK, INFO, WARNUNG, KRITISCH) und benennt konkret, was fehlt oder gesperrt ist. Bei Bedarf gibt es automatisch die KB5025885-Befehle zur manuellen Nachbesserung aus — inklusive BitLocker-Hinweis, wenn das Laufwerk verschlüsselt ist.
Zusätzlich wird automatisch eine Protokolldatei unter ./log/[Hostname].log abgelegt. Das macht den Einsatz auch bei Kunden ohne IT-Kenntnisse möglich: Skript starten, Log-Datei per E-Mail zusenden, fertig.
Netzwerkbetrieb: Ein zweites Skript (SecureBoot-Network.ps1) führt den Check via PSRemoting auf beliebig vielen PCs parallel aus und erstellt einen CSV-Gesamtbericht.
GitHub-Repository: 👉 https://github.com/rentasad/SecureBoot-Check
Das Repository enthält das Skript, eine ausführliche technische Dokumentation sowie eine Schritt-für-Schritt-Anleitung für Endkunden — auf Deutsch und Englisch.
Technischer Hintergrund: Warum ist das so schwer zu prüfen?
Eine kurze Erklärung für alle, die sich wundern, warum es kein einfaches Windows-Bordmittel für diese Prüfung gibt:
Die UEFI-Zertifikatsdatenbanken (db, KEK, PK, dbx) werden von Windows als binäre UEFI-Variablen verwaltet. Das Format heißt EFI Signature List und besteht aus einer Folge von Einträgen mit GUID, Größenangaben und dem eigentlichen Zertifikatsinhalt im DER-Format.
PowerShell kann diese Variablen über Get-SecureBootUEFI auslesen — jedoch liefert das Cmdlet die Rohdaten als Byte-Array. Das Parsing des binären Formats, die Extraktion der einzelnen X.509-Zertifikate und deren Auswertung (Ablaufdatum, Fingerprint, Subject/Issuer) muss manuell implementiert werden.
Genau das macht das Diagnoseskript: Es parst die EFI Signature List, extrahiert alle enthaltenen Zertifikate und bewertet sie gegen bekannte Thumbprints und Namenspatterns der 2011er und 2023er Microsoft-Zertifikate.
Zusammenfassung: Was jetzt zu tun ist
- Jetzt prüfen: Welche PCs haben die neuen 2023er UEFI-Zertifikate — und welche nicht?
- Windows Update sicherstellen: Alle PCs auf aktuellem Stand halten; Windows 11 24H2 ist Voraussetzung für weiteren kostenlosen Support.
- PKfail prüfen: Ist Secure Boot auf allen Geräten wirklich wirksam?
- Manuelle Nachbesserung vorbereiten: Für PCs, die per Update nicht erreichbar sind, KB5025885 kennen und anwenden können.
- Vor Oktober fertig sein: Microsoft wird die alten Zertifikate sperren. Wann genau, ist unbekannt — aber die Wahrscheinlichkeit steigt mit jedem Monat.
Quellen
- Vahldiek, Axel: „Sicherer Start in der Krise“. In: c’t Magazin für Computertechnik, Ausgabe 13/2026, Heise Medien GmbH & Co. KG, Hannover.
- Microsoft Support: KB5025885 — How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
- UEFI Forum: UEFI Specification 2.10 — EFI_SIGNATURE_LIST Format
- PKfail-Datenbank: https://pk.fail
- GitHub-Repository: https://github.com/rentasad/SecureBoot-Check
Dieser Beitrag und das Diagnoseskript entstanden in Zusammenarbeit mit Claude Cowork (Anthropic). Das Skript, die technische Analyse und die Dokumentation wurden im Dialog zwischen Mensch und KI erarbeitet.