In vielen Tenants, die ich betreue, meldet sich zum Jahresanfang 2026 eine Frage zurück, die lange und gern verdrängt wurde: Sind meine Geräte darauf vorbereitet, dass die Secure-Boot-Zertifikate von 2011 auslaufen? Microsoft hat schon vor einiger Zeit angekündigt, die Microsoft Corporation KEK CA 2011 und die Microsoft UEFI CA 2011 ab Juni 2026 und die Microsoft Windows Production PCA 2011 ab Oktober 2026 nicht mehr als gültige Trust Anchors für Secure Boot zu akzeptieren. An ihre Stelle treten die neuen CAs von 2023. Cloud-Admins sind davon ebenso betroffen, vor allem aber die klassischen Endpoint-Verantwortlichen, die Hardwareflotten verwalten und dafür sorgen müssen, dass Secure Boot weiter funktioniert.

Ohne Update droht der Ausfall erst beim nächsten Rollout

Gleich vorweg: Vor einem plötzlichen Boot-Desaster muss sich niemand fürchten, solange das System nicht selbst ein neues Boot-Manager- oder DBX-Update einspielt, das die ablaufenden Zertifikate entfernt. Geräte mit alten Secure-Boot-Zertifikaten und passender Firmware starten auch nach Juni bzw. Oktober 2026 weiter, solange keine Komponente auf die neuen Zertifikate umgestellt wird. Genau darin liegt die trügerische Sicherheit. Spätestens kommende Firmware- oder Windows-Updates erzwingen den Wechsel, und Geräte, die die 2023er-CAs nicht unterstützen, booten dann ohne jede Vorwarnung nicht mehr. In gemischten Umgebungen, in denen längst nicht alle Geräte auf aktuellem Stand sind, kann ein späterer Rollout so zu einem sehr unangenehmen „Big Bang“ werden.

Mein Tipp aus der Praxis: In größeren Umgebungen sollte man gezielt nach alten Geräten und veralteten Firmware-Versionen suchen, bevor man neue Windows- oder Firmware-Updates breit ausrollt.

Die Bestandsaufnahme zeigt, welche Geräte betroffen sind

Am schwierigsten ist erfahrungsgemäß die Bestandsaufnahme selbst. Viele Unternehmen haben über die Jahre Geräte verschiedener OEMs und Modelle gekauft, und selbst innerhalb einer Modellreihe laufen oft unterschiedliche Firmware-Stände. Man muss also genau wissen,

  • auf welchen Geräten Secure Boot aktiviert ist,
  • welche Zertifikate derzeit in der UEFI-Datenbank liegen
  • und ob Firmware- oder Windows-Updates die neuen Zertifikate bereits mitbringen.

In der Microsoft-Dokumentation steht ausführlich, wie man die Secure-Boot-Schlüssel verwaltet und den Startvorgang absichert. Für den Einstieg genügt oft schon das Eventlog: An den Einträgen im System-Log mit der Quelle „TPM-WMI“ und den Event-IDs 1794 und 1795 erkennt man, ob ein Gerät bereits mit den neuen Secure-Boot-Zertifikaten arbeitet. Mit Intune lassen sich diese Events über Proactive Remediation auslesen, ohne Intune hilft ein gezieltes PowerShell-Skript auf den Endgeräten.

Get-WinEvent -LogName System | Where-Object {
  ($_.ProviderName -eq "TPM-WMI") -and ($_.Id -in 1794,1795)
} | Select-Object TimeCreated, Id, Message

Auf dem Endgerät mit PowerShell 7 ausführen, lokale Adminrechte erforderlich.

Hersteller und Microsoft verteilen die neuen Zertifikate auf getrennten Wegen

Die neuen Secure-Boot-Zertifikate gelangen über zwei Kanäle auf die Geräte. Viele OEMs wie Dell, HP oder Lenovo stellen Firmware-Updates bereit, die die neuen 2023er-CAs und gegebenenfalls die aktualisierte DBX einspielen. Daneben verteilt Microsoft die Zertifikate für Windows 10 und 11 auch über Windows Update. Automatisch landen die Updates allerdings nicht überall; vor allem bei älteren Maschinen oder Custom-Images gibt es immer wieder Ausnahmen. Ich gleiche deshalb vor jeder breiten Welle die Update-Matrizen der Hersteller ab und teste mit einer Gruppe typischer Modelle. Dieser Aufwand hat sich bisher jedes Mal gelohnt.

Im folgenden Ablaufdiagramm sieht man, wie Zertifikatsverteilung und Startvorgang ineinandergreifen:

flowchart TD
  Start["Gerät startet"] --> UEFI["UEFI Secure Boot prüft Zertifikate"]
  UEFI -->|"2011 CA gültig"| BootOld["Boot funktioniert"]
  UEFI -->|"2011 CA abgelaufen, 2023 CA vorhanden"| BootNew["Boot funktioniert"]
  UEFI -->|"2011 CA abgelaufen, 2023 CA fehlt"| BootFail["Boot scheitert"]
  Updates["Firmware/Windows Update installiert?"] -->|"Ja"| CertsUpdate["2023 CA eingespielt"]
  CertsUpdate --> UEFI
  Updates -->|"Nein"| UEFI

Abbildung: Startvorgang und Update-Pfade bei auslaufenden Secure-Boot-Zertifikaten.

Eine Pilotgruppe bewahrt vor einem blinden Rollout

Bevor Updates in die Breite gehen, sollte man die Pilotgruppe mit Bedacht zusammenstellen. Ärger machen in der Praxis vor allem Spezialgeräte, Embedded-Systeme und ungewöhnliche OEM-Modelle, die zudem selten sauber dokumentiert sind. Wer gestaffelt verteilt, die Boot-Events im Blick behält und die Rückmeldungen der Pilotnutzer ernst nimmt, erspart sich böse Überraschungen. Mit Intune oder einer anderen zentralen Managementlösung fällt die Überwachung deutlich leichter, und man kann schnell reagieren, wenn ein Gerät nach dem Update nicht mehr startet. Fehlt ein solches Werkzeug, bleiben nur manuelle Stichproben und das Auswerten der Eventlogs. Einen Rollback-Plan für Firmware- und OS-Updates sollte man so oder so in der Schublade haben.

Ich prüfe 2026 gelassen, aber konsequent

Dass die Secure-Boot-Zertifikate von 2011 ausgemustert werden, ist kein Grund zur Panik. Eine strukturierte Reaktion ist aber überfällig. Ich stoße die Inventarisierung und ein erstes Pilot-Update deshalb nicht auf den letzten Drücker an, sondern jetzt im ersten Quartal. Ältere Geräte, die ohnehin bald das Ende ihres Lebenszyklus erreichen, kommen auf eine eigene Liste. Wer jetzt sauber dokumentiert, kann die breite Umstellung im Sommer und Herbst in Ruhe angehen und wird nicht kalt erwischt, wenn Microsoft oder der OEM das Update irgendwann verpflichtend verteilt. Weitere Tipps und praktische Abfragen zu Geräteinventur und Update-Stand finden sich in meinen Beiträgen zum Supportende von Windows 10 und zu Windows Autopilot Device Preparation.