In vielen Umgebungen, die ich betreue, hat sich bislang kaum jemand um die Secure-Boot-KEK-Zertifikate gekümmert, also vor allem um die Microsoft Corporation KEK CA 2011 und die UEFI CA 2011. Jetzt, im Juni 2026, endet ihre Gültigkeit endgültig. Plötzlich redet jeder darüber, denn auch aktuelle Geräte ohne Firmware-Update oder ungepatchte VMs können beim nächsten UEFI- oder Secure-Boot-Update Ärger machen. Wer seinen Gerätebestand nicht kennt, muss mit einer Welle von Supportfällen rechnen und erlebt bei künftigen Updates oder Sicherheitsmaßnahmen womöglich unangenehme Überraschungen.
Systeme mit den alten KEKs laden bald keine neuen Boot-Komponenten mehr
Sind die 2011er KEK-Zertifikate offiziell abgelaufen, können Systeme, die nur diesen alten Zertifikaten vertrauen, keine neuen Boot-Manager oder UEFI-Updates mehr einspielen, sobald diese ausschließlich mit den 2023er KEKs signiert sind. Das betrifft vor allem DBX-Updates (UEFI Revocation List), UEFI-Firmware-Updates und Boot-Manager, die Microsoft in den kommenden Monaten auf die neuen Zertifikate umstellt. Nach aktuellem Kenntnisstand laufen bestehende Installationen erst einmal weiter, solange niemand ein Update einspielt. Gelöst ist das Problem damit nicht, nur vertagt: Spätestens beim nächsten größeren Feature- oder Sicherheitsupdate kann das System im ungünstigsten Fall stehen bleiben.
Wie Secure Boot und die Zertifikatsketten im Detail zusammenspielen, habe ich in meinem Einstiegsbeitrag beschrieben: Secure-Boot-Zertifikate laufen 2026 ab – das sollten Admins wissen.
Registry und Eventlog verraten, welche Geräte die 2023er-Ketten bereits kennen
In der Praxis steht jetzt die mühsame Bestandsaufnahme an, denn man muss herausfinden, welche Geräte für die Zeit nach dem KEK-Ablauf schon vorbereitet sind. Unter https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance erklärt Microsoft ausführlich, wie sich der aktuelle Status prüfen lässt. Am schnellsten geht es auf Windows-Geräten (ab Windows 10/11, mit Adminrechten), indem man nachsieht, welche Zertifikate installiert sind. Die Angaben dazu liegen in der Registry unter:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Für jede Zertifikatskette (KEK, DB, DBX) gibt es dort einen eigenen Unterschlüssel. Worauf es ankommt, sind die letzten Installationszeitpunkte und die Thumbprints der Zertifikate. Windows schreibt diese Einträge bei den jüngsten Secure-Boot-Key-Updates, meist zusammen mit Firmware- oder OS-Updates. Bequemer ist für die meisten Admins allerdings das Eventlog:
- Event Viewer → Anwendungen und Diensteprotokolle → Microsoft → Windows → SecureBoot-Management → Operational
- Nach Einträgen suchen, die ein Update von KEK oder DB dokumentieren; darin sollte der Thumbprint der 2023er KEKs zu finden sein.
In Tenants mit Intune liefert außerdem die Geräteinventur den Secure-Boot-Status. Allerdings melden nicht alle OEMs verlässlich an Intune. Oft bleibt dann nur, Intune-Inventurdaten, Eventlog und Registry gemeinsam auszuwerten. Vor allem bei älteren Notebooks, deren Firmware-Updates nie ordentlich dokumentiert wurden, erlebe ich immer wieder Überraschungen.
Alte Firmware, VMs und Dual-Boot-Systeme fallen am ehesten durchs Raster
Auf drei Fälle sollte man besonders achten:
- Geräte mit veralteter Firmware, für die der OEM keine Pflege mehr anbietet. Ohne offizielles UEFI-Update lassen sich die 2023er KEKs dort häufig gar nicht installieren.
- Virtuelle Maschinen: Hyper-V-VMs der Generation 2 und VMs mit Azure Trusted Launch verwenden eigene Secure-Boot-Ketten. Für Azure Trusted Launch sollen die neuen KEKs laut aktueller Ankündigung automatisch verteilt werden, auf lokalen Hyper-V-Hosts sind je nach VM-Konfiguration womöglich manuelle Updates nötig. Wer seit Jahren dieselben Images verwendet, sollte das dringend kontrollieren.
- Linux-Dual-Boot-Systeme: Hier wird es schnell kompliziert, weil viele Distributionen eigene Shim-Signaturen mitbringen. Kennt die Hardware die neuen KEKs noch nicht, kann nach dem Ablauf der alten Microsoft-KEKs ein Kernel- oder Bootloader-Update scheitern. Wie weit die einzelnen Distributionen sind, ist sehr unterschiedlich.
Bei älteren Geräten und verschachtelten Boot-Konfigurationen entstehen daraus schnell echte Supportfälle.
# Prüfung in PowerShell (lokal, als Admin):
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object KEKUpdateTimestamp, KEKThumbprint
Voraussetzung: lokale Adminrechte und mindestens Windows 10. Die Ausgabe liefert Zeitstempel und Thumbprint der letzten KEK-Updates.
Praxistipp: Die Firmware-Update-Tools der OEMs zeigen häufig nicht an, welche Secure-Boot-Keys nach dem Update wirklich installiert sind. Ich kontrolliere das deshalb jedes Mal zusätzlich in der Registry oder im Eventlog.
Nach dem Ablauf booten alte Systeme weiter, bleiben aber bei Updates hängen
Systeme mit den alten KEKs starten auch nach dem Ablaufdatum die vorhandenen Bootloader und Betriebssysteme. Signierte Updates, etwa DBX-Updates zum Sperren unsicherer Bootloader, oder neue Boot-Manager können sie aber nicht mehr laden, sobald diese nur noch mit den 2023er KEKs signiert sind. Mittelfristig trifft das jeden, dem aktuelle Sicherheit wichtig ist oder der Feature-Updates installieren will. Bei virtuellen Maschinen (Hyper-V Gen2, Azure Trusted Launch) hängt alles vom Update-Stand der Secure Boot Policy auf dem Host und vom verwendeten Image ab. In Azure findet man diese Angabe im Azure-Portal unter VM → Einstellungen → Secure Boot Policy.
Unter Linux muss man nach dem Ablauf der alten KEKs mit Schwierigkeiten bei künftigen Kernel- oder Shim-Updates rechnen, wenn nicht Hardware und Distribution gleichermaßen rechtzeitig aktualisiert wurden. Ohne Überblick drohen hier unerwartete Bootprobleme.
Die Zusammenhänge habe ich vereinfacht dargestellt:
flowchart TD
User["Admin prüft Status"] --> CheckReg["Registry HKLM...Servicing"]
User --> CheckEvt["Eventlog SecureBoot-Management"]
CheckReg --> Status2023["2023 KEK installiert?"]
CheckEvt --> Status2023
Status2023 -- "Ja" --> OK["Fertig, Update-ready"]
Status2023 -- "Nein" --> FWUpdate["Firmware/VM-Update nötig"]
FWUpdate -- "Update verfügbar" --> OK
FWUpdate -- "Kein Update" --> Risk["Langfristig unsicher"]
Abbildung: Entscheidungsbaum zum Ablauf der Secure-Boot-KEKs und zum Update-Status.
Ohne Firmware-Update bleibt nur die Eskalation beim Hersteller
In Projekten treffe ich immer wieder auf Geräte, für die der Hersteller den Support eingestellt oder einfach kein Update veröffentlicht hat. Dann bleibt meist nur, sich direkt an den OEM-Support zu wenden und über die offiziellen Business-Kanäle zu eskalieren. Microsoft weist in der aktuellen Dokumentation darauf hin, dass die OEMs die neuen Schlüssel ausliefern müssen. Wer das Thema jetzt liegen lässt, riskiert, dass ganze Geräteflotten mittelfristig nicht mehr zu gebrauchen sind, und gerade bei kritischer Infrastruktur geht das ins Geld.
Aus der Praxis noch ein Hinweis: Manchmal bringt eine gezielte Suche nach „UEFI Secure Boot KEK Update“ zusammen mit der Modellnummer etwas, weil andere Admins in Foren Workarounds oder inoffizielle Updates teilen. Unsignierte oder nicht vom OEM stammende Firmware spiele ich aber grundsätzlich nicht ein, und davon rate ich auch euch ab. Bei VMs lohnt sich die Suche nach Updates für das Hyper-V-Image, alternativ setzt man die VM mit aktuellen Secure Boot Policies neu auf.
Der KEK-Ablauf gehört zum Pflichtprogramm jeder Flottenverwaltung und ist mehr als eine Compliance-Frage
Viele halten den Ablauf der Secure-Boot-KEKs anfangs für eine Randnotiz, doch inzwischen ist Handeln gefragt. Wer seine Geräteflotte ernsthaft verwaltet und in den kommenden Monaten keine bösen Überraschungen erleben möchte, prüft jetzt Registry und Eventlog, spürt veraltete Geräte auf und zieht bei OEMs und Cloud-VM-Images nach. Das ist umständlich, aber deutlich günstiger als ein Ausfall oder ein fehlgeschlagenes Update. Kontrolliert also eure Flotte, haltet Ausreißer schriftlich fest und richtet euch im Zweifel nach Microsofts Guidance.
