Secure Boot gehört seit Jahren zu den Grundlagen eines sicheren Windows-Clients. Kaum jemand schaut sich die Zertifikate an, auf denen es beruht. Jetzt wird das nötig: Die Zertifikate, mit denen Microsoft seit 2011 Boot-Komponenten signiert, erreichen 2026 ihr Ablaufdatum. Microsoft verteilt die Nachfolger von 2023 über Windows-Updates. Ob das auf Ihren Geräten tatsächlich funktioniert, hängt aber von Firmware, Hardware und Konfiguration ab.
Dieser Artikel erklärt, was das in der Praxis bedeutet, und wie Sie inventarisieren und die Umstellung planen. Für exakte Daten, Registry- und Intune-Einstellungen verweisen wir bewusst auf die offizielle Anleitung von Microsoft, «Windows Secure Boot certificate expiration and CA updates». Sie wird laufend aktualisiert.
Was Secure Boot macht und welche Zertifikate betroffen sind
Secure Boot ist eine UEFI-Funktion. Beim Start prüft die Firmware, ob Bootloader, Treiber und Option ROMs von Erweiterungskarten mit einem vertrauenswürdigen Zertifikat signiert sind. Was nicht passt, wird nicht ausgeführt. So lassen sich Bootkits verhindern, die sich vor dem Betriebssystem einnisten.
Die Vertrauensbasis liegt in UEFI-Variablen der Firmware: dem Platform Key (PK) des Geräteherstellers, dem Key Exchange Key (KEK), der Datenbank erlaubter Zertifikate (DB) und der Sperrliste (DBX). Betroffen sind drei Microsoft-Zertifikate aus 2011:
| Zertifikat 2011 | Zweck | Nachfolger 2023 |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | Signiert Updates von DB und DBX | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft Windows Production PCA 2011 | Signiert den Windows-Boot-Manager | Windows UEFI CA 2023 |
| Microsoft UEFI CA 2011 | Signiert Bootloader und Option ROMs von Drittanbietern, etwa den Linux-Shim | Microsoft UEFI CA 2023 und Microsoft Option ROM UEFI CA 2023 |
KEK CA 2011 und UEFI CA 2011 laufen ab Juni 2026 ab, das Windows Production PCA 2011 im Oktober 2026. Prüfen Sie die genauen Daten in der Anleitung von Microsoft.
Was der Ablauf in der Praxis bedeutet
Zuerst die gute Nachricht: Geräte hören nicht am Ablaufdatum auf zu starten. Die Firmware prüft beim Booten in der Regel nicht, ob ein Zertifikat abgelaufen ist. Die Probleme entstehen schleichend:
- Keine Updates für Boot-Komponenten: Neue Versionen des Windows-Boot-Managers werden mit dem Nachfolgezertifikat signiert. Geräte ohne Windows UEFI CA 2023 in der DB können sie nicht nutzen und bleiben bei Sicherheitslücken im Bootprozess ungeschützt.
- Keine Sperrlisten-Updates: Ohne den neuen KEK kann Microsoft nach Ablauf keine neuen Einträge für DB und DBX mehr signieren, die das Gerät akzeptiert. Neue Sperren gegen bekannte unsichere Bootloader kommen nicht mehr an.
- Wiederherstellungs- und Installationsmedien: Sobald die Umstellung abgeschlossen ist und alte Boot-Manager in einem späteren Schritt gesperrt werden, starten alte USB-Sticks, ISO-Dateien und PXE-Images nicht mehr. Auch Ihre Medien müssen aktualisiert werden.
- Linux und Drittanbieter: Neuere Versionen des Linux-Shims und Option ROMs, etwa von Grafik- oder Netzwerkkarten, werden künftig mit den neuen Drittanbieter-Zertifikaten signiert. Fehlt das passende Zertifikat in der DB, starten sie mit aktivem Secure Boot nicht.
Achtung: Secure Boot zu deaktivieren ist keine Lösung. Es entfernt den Schutz, statt das Zertifikatsproblem zu beheben, und kann Compliance-Regeln in Intune verletzen.
Inventar: Wo stehen Ihre Geräte?
Bevor Sie etwas ändern, brauchen Sie einen Überblick über die ganze Flotte. Die wichtigsten Fragen pro Gerät: Ist Secure Boot aktiv? Welcher Hersteller, welches Modell, welche Firmware-Version? Ist das Zertifikat Windows UEFI CA 2023 bereits in der DB? Ist BitLocker aktiv und der Wiederherstellungsschlüssel zentral hinterlegt?
Ein Grossteil davon lässt sich mit einem kleinen, rein lesenden PowerShell-Skript erfassen, das mit Administratorrechten läuft:
# Secure Boot aktiv? (wirft auf Geräten ohne UEFI einen Fehler)
Confirm-SecureBootUEFI
# Ist das neue Windows-Zertifikat in der DB?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).bytes) -match 'Windows UEFI CA 2023'
# Hersteller, Modell, Firmware-Version und -Datum
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model
Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion, ReleaseDate
# BitLocker-Status des Systemlaufwerks
Get-BitLockerVolume -MountPoint $env:SystemDrive | Select-Object ProtectionStatus, KeyProtectorVerteilt wird ein solches Skript zum Beispiel über Intune Remediations, sofern lizenziert, als Plattformskript oder als geplante Aufgabe. Wichtig ist, dass die Ergebnisse zentral zusammenlaufen und nach Hardwaremodell und Firmware-Version gruppiert werden können.
Beispiel aus der Praxis: Für ein solches Inventar haben wir einen kleinen Collector gebaut, der die Werte auf den Clients nur liest und an einen zentralen Endpunkt sendet, dazu ein einfaches Dashboard. Es zeigt pro Modell, wie viele Geräte die neuen Zertifikate bereits haben, wo Firmware fehlt und wo BitLocker-Schlüssel nicht hinterlegt sind. Der Ansatz ist bewusst schlank und ändert auf den Geräten nichts.
Den Rollout planen
Microsoft verteilt die neuen Zertifikate über Windows-Updates und steuert den Rollout teilweise selbst. Sie können ihn aber auch gezielt anstossen. Die Mechanismen dafür beschreibt die offizielle Anleitung. Für die Planung gilt:
- BitLocker absichern: Bevor Sie Firmware oder Boot-Komponenten anfassen, müssen die Wiederherstellungsschlüssel aller Geräte in Entra ID oder Active Directory hinterlegt und auffindbar sein. Änderungen an Secure-Boot-Variablen und Firmware können eine BitLocker-Wiederherstellung auslösen. Ohne Schlüssel ist das Gerät dann nicht mehr zugänglich.
- Firmware aktualisieren: Die Aktualisierung des KEK muss mit dem Platform Key des Geräteherstellers signiert sein. Microsoft arbeitet dafür mit den Herstellern zusammen, aber nicht jedes Modell ist abgedeckt. Aktuelle Firmware vom Hersteller ist deshalb eine wichtige Voraussetzung. Prüfen Sie die Hinweise Ihrer Hersteller zu den einzelnen Modellen.
- Pilot pro Hardwaremodell: Testen Sie je Modell und Firmware-Stand einige Geräte, bevor Sie breit ausrollen. Firmware-Implementierungen unterscheiden sich, und Probleme zeigen sich meist modellspezifisch.
- Medien erneuern: Wiederherstellungsmedien, Installations-ISOs, WinPE- und PXE-Images mit aktuellen Boot-Komponenten neu erstellen.
- Kontrollieren: Nach dem Rollout erneut inventarisieren. Erst wenn der Status zentral sichtbar grün ist, gilt ein Gerät als umgestellt.
Sonderfälle: VMs, alte Hardware, Dual Boot
- Virtuelle Maschinen: Auch VMs mit UEFI haben Secure-Boot-Variablen, etwa Hyper-V-VMs der Generation 2. Ob die neuen Zertifikate, insbesondere der KEK, dort eingespielt werden können, hängt vom Hypervisor und seinen Updates ab. Prüfen Sie die Hinweise des jeweiligen Herstellers, auch bei Windows Servern und Terminalservern.
- Ältere Hardware: Geräte, für die der Hersteller keine Firmware mehr liefert, lassen sich möglicherweise nicht vollständig umstellen. Sie starten weiter, erhalten aber keine Updates für den Bootprozess mehr. Das ist ein Argument, sie in der Ersatzplanung vorzuziehen.
- Dual Boot und Linux: Geräte mit Linux brauchen das neue Drittanbieter-Zertifikat für künftige Shim-Versionen. Prüfen Sie diese Geräte separat und halten Sie die Distribution aktuell.
- Erweiterungskarten: Server und Workstations mit eigenen Grafik-, RAID- oder Netzwerkkarten laden Option ROMs. Auch hier lohnt ein Blick in die Hinweise der Hersteller.
Checkliste
Checkliste
- Offizielle Microsoft-Anleitung zu Ablauf und CA-Updates gelesen, Zeitplan geprüft
- Inventar aller Geräte: Secure Boot aktiv, Modell, Firmware, Zertifikatsstatus
- BitLocker-Wiederherstellungsschlüssel für alle Geräte zentral hinterlegt und geprüft
- Firmware-Updates der Hersteller pro Modell bereitgestellt
- Pilot pro Hardwaremodell durchgeführt
- Rollout gestaffelt angestossen und mit erneutem Inventar kontrolliert
- Wiederherstellungs-, Installations- und PXE-Medien erneuert
- VMs, Server, Linux- und Dual-Boot-Geräte separat geprüft
- Geräte ohne Firmware-Support in der Ersatzplanung berücksichtigt
Die Umstellung der Secure-Boot-Zertifikate ist kein Anlass zur Panik, aber auch kein Thema, das sich von selbst erledigt. Wer jetzt inventarisiert, BitLocker absichert und modellweise vorgeht, behält die Kontrolle und bleibt auch künftig für Updates des Bootprozesses erreichbar.
Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.
Kontakt aufnehmen