UEFI CA 2023 Migration — Secure Boot-Zertifikate vor dem Ablauf erneuern

Warum diese Migration kritisch ist

Microsoft hat seine Secure Boot-Infrastruktur 2011 mit einem Satz von Zertifikaten aufgebaut, die nun nach 15 Jahren Laufzeit auslaufen. Die drei zentralen Zertifikate — Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011 und Microsoft UEFI CA 2011 — verlieren zwischen Juni und Oktober 2026 ihre Gültigkeit. Ohne Migration auf die Nachfolgerzertifikate der Windows UEFI CA 2023 können betroffene Geräte keine neuen Boot-Level-Sicherheitsupdates mehr installieren.

Das klingt zunächst nach einem reinen Zertifikatswechsel, hat aber weitreichende Konsequenzen. Secure Boot verifiziert kryptografisch, dass der Bootloader nicht manipuliert wurde — ein fundamentaler Baustein der Vertrauenskette vom TPM über den Bootprozess bis zum Betriebssystem. Wenn die Signaturzertifikate ablaufen, kann Windows keinen neuen Bootmanager mehr signieren und ausliefern. Das betrifft nicht den normalen Betrieb — Geräte booten weiterhin — aber die Fähigkeit, boot-level Schwachstellen zu schließen, geht verloren.

Verschärfend kommt hinzu, dass Microsoft parallel die BlackLotus-Revokation (CVE-2023-24932) vorantreibt. Dabei werden verwundbare Boot Manager über die Secure Boot Forbidden List (DBX) gesperrt. Wer die Zertifikatsmigration nicht abgeschlossen hat, bevor die Enforcement-Phase greift, riskiert nicht-bootfähige Systeme.

Welche Zertifikate betroffen sind

Die folgende Tabelle zeigt die ablaufenden Zertifikate und ihre Nachfolger:

Der KEK (Key Exchange Key) autorisiert Änderungen an der Signatur-Datenbank DB und der Sperrliste DBX. Die DB enthält die Zertifikate, mit denen Bootloader und Option ROMs signiert sind. Wenn der KEK abläuft, können keine neuen Einträge mehr in DB oder DBX geschrieben werden — Updates des Bootmanagers und Revokationen verwundbarer Komponenten werden unmöglich.

Zeitplan der Migration

Microsoft hat die Migration in mehrere Phasen gegliedert:

Phase 1: OEM-Bereitstellung (ab 2024)

Neue Geräte, die seit 2024 ausgeliefert werden, enthalten bereits die Windows UEFI CA 2023 in ihrer Firmware. Allerdings ist bei vielen dieser Geräte zwar das Zertifikat im DB-Store vorhanden, der Bootmanager aber noch mit dem alten Zertifikat signiert. Die Migration ist also auch auf neuen Geräten nicht automatisch abgeschlossen.

Phase 2: Rollout für Bestandsgeräte (ab 2025)

Seit November 2025 stehen die Werkzeuge für die gesteuerte Migration zur Verfügung. Microsoft liefert die neuen Zertifikate schrittweise über Windows Update aus — allerdings nur an sogenannte „High-Confidence-Geräte", bei denen die Telemetrie-Daten auf Kompatibilität schließen lassen.

Phase 3: Zertifikatsablauf (Juni–Oktober 2026)

Ab Juni 2026 beginnen die alten Zertifikate abzulaufen. Geräte, die bis dahin nicht migriert wurden, funktionieren weiter — aber sie können keine neuen Bootmanager-Updates mehr empfangen und sind von künftigen Boot-Level-Patches ausgeschlossen.

Wer manuell handeln muss

Die automatische Migration über Windows Update erfasst nur einen Teil der Geräteflotte. Folgende Systeme erfordern manuelles Eingreifen durch die IT-Administration:

• Windows Server (alle Versionen) — kein automatischer Rollout vorgesehen
• Windows 10 — wird nicht über den automatischen Kanal bedient
• Systeme ohne Telemetrie — Geräte, bei denen diagnostische Daten deaktiviert sind, werden vom automatischen Rollout ausgeschlossen
• Virtuelle Maschinen — Hyper-V, VMware und andere Hypervisoren erfordern separate Behandlung
• Linux-Dual-Boot-Systeme — besondere Vorsicht bei geteilter Secure Boot-Konfiguration

In der Praxis bedeutet das: In den meisten Unternehmensumgebungen muss die Migration aktiv gesteuert werden. Sich auf den automatischen Rollout zu verlassen, ist für verwaltete Infrastrukturen keine Option.

Bestandsaufnahme: Wo steht Ihre Flotte?

Bevor Sie mit der Migration beginnen, brauchen Sie ein klares Bild des Ist-Zustands. Microsoft stellt dafür Registry-basiertes Monitoring bereit.

Registry-Überwachung

Unter HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing geben zwei Schlüssel Auskunft über den Migrationsstatus:

UEFICA2023Status zeigt den Fortschritt:

WindowsUEFICA2023Capable zeigt die Zertifikatspräsenz:

Zusätzlich signalisiert EventID 1808 (Quelle: TPM-WMI) im System-Eventlog den erfolgreichen Abschluss der Migration. EventID 1801 weist darauf hin, dass die aktualisierten Zertifikate noch nicht angewendet wurden.

PowerShell-Abfrage für die Flotte

Für eine schnelle Bestandsaufnahme über die gesamte Flotte lässt sich der Registry-Status per PowerShell abfragen und zentral auswerten — etwa über Microsoft Intune, SCCM oder ein bestehendes Monitoring-System.

Deployment-Methoden im Vergleich

Microsoft bietet vier Wege, die Migration zu steuern. Laut Microsoft sollte pro Gerät nur eine Methode verwendet werden, um Konflikte zu vermeiden.

Methode 1: Microsoft Intune

Für Intune-verwaltete Geräte die empfohlene Variante. Drei Einstellungen in der Kategorie „Secure Boot" steuern den Rollout:

• Enable SecureBoot Certificate Updates — aktiviert die Zertifikatsauslieferung
• Configure Microsoft Update Managed Opt In — steuert den kontrollierten Rollout
• Configure High Confidence Opt-Out — deaktiviert den automatischen Rollout auf High-Confidence-Geräten

Methode 2: Registry-Konfiguration

Für Umgebungen ohne Intune kann die Migration über einen Registry-Key angestoßen werden:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
  -Name "AvailableUpdates" -Value 0x5944

Der Wert durchläuft während der Migration eine definierte Sequenz. Nach jedem Schritt ist ein Neustart erforderlich:

Methode 3: Gruppenrichtlinie

Unter Computer Configuration > Administrative Templates > Windows Components > Secure Boot steht die Einstellung „Enable Secure Boot certificate deployment" zur Verfügung. Voraussetzung sind aktuelle ADMX-Templates für Windows 11 und Windows Server. Microsoft empfiehlt Gruppenrichtlinien gegenüber direkter Registry-Manipulation, da GPO-gesetzte Werte persistent sind.

Methode 4: Windows Configuration System (WinCS)

Für domänengebundene Windows-Clients und -Server steht als weitere Option das Windows Configuration System zur Verfügung. Diese Methode nutzt das Feature Feature_AllKeysAndBootMgrByWinCS und eignet sich für Umgebungen, die WinCS bereits für andere Konfigurationsaufgaben einsetzen.

Praxisempfehlung: Migration in fünf Schritten

Aus unserer Erfahrung mit Systemhärtung empfehlen wir folgendes Vorgehen:

Schritt 1 — Inventar erstellen. Erfassen Sie den UEFICA2023Status aller Geräte über Ihr vorhandenes Endpoint-Management. Segmentieren Sie nach Betriebssystem, Gerätealter und Verwaltungsmethode. Geräte ab Baujahr 2024 haben die neuen Zertifikate oft schon im DB-Store — der Bootmanager muss aber trotzdem aktualisiert werden.

Schritt 2 — OEM-Firmware-Updates einspielen. Vor der Zertifikatsmigration sollten aktuelle BIOS/UEFI-Updates der Hardwarehersteller installiert werden. Einige OEMs liefern die neuen Zertifikate bereits über ihre Firmware-Updates aus.

Schritt 3 — Pilotgruppe testen. Wählen Sie eine repräsentative Geräteauswahl und führen Sie die Migration durch. Planen Sie rund 48 Stunden und mindestens einen Neustart ein. Überwachen Sie den Registry-Status und die Eventlog-Einträge. Testen Sie insbesondere BitLocker-Recovery, PXE-Boot und Dual-Boot-Szenarien.

Schritt 4 — Breit ausrollen. Nach erfolgreicher Pilotphase rollen Sie die Migration gestaffelt über die Produktivflotte aus. Nutzen Sie die Deployment-Methode, die zu Ihrer Verwaltungsinfrastruktur passt — Intune, GPO oder Registry.

Schritt 5 — Verifizieren und dokumentieren. Prüfen Sie, dass UEFICA2023Status auf allen Geräten den Wert Updated zeigt. Dokumentieren Sie den Abschluss — die Migration ist ein relevanter Nachweis für Compliance-Audits und Cyber-Versicherungen.

Fallstricke, die wir in der Praxis sehen

Uns begegnen in der Praxis Konstellationen, die die Migration erschweren:

Deaktiviertes Secure Boot. Überraschend viele Systeme haben Secure Boot gar nicht aktiviert — sei es nach Hardware-Wartung, wegen Kompatibilitätsproblemen mit Treibern oder weil es bei der Ersteinrichtung vergessen wurde. Diese Geräte sind von der Zertifikatsmigration nicht betroffen, haben aber ein grundlegenderes Problem: Ohne Secure Boot ist die gesamte Vertrauenskette vom Firmware-Start bis zum Betriebssystem unterbrochen.

Veraltete Firmware. Ältere Geräte mit Firmware-Versionen vor 2020 unterstützen unter Umständen den erweiterten Zertifikats-Store nicht. Hier muss zuerst ein BIOS/UEFI-Update erfolgen, bevor die Zertifikatsmigration möglich ist.

Test-Platform-Keys in Produktion. Laut msxfaq.de wurden bei einigen AMI-basierten Mainboards Test-Platform-Keys (PK) mit öffentlich bekannten Schlüsseln in Produktionssystemen ausgeliefert. Bei diesen Geräten ist die gesamte Secure Boot-Kette kompromittiert — ein reines Zertifikatsupdate reicht nicht, es muss ein Firmware-Update des Herstellers eingespielt werden.

Linux-Dual-Boot. Systeme mit Linux-Dual-Boot verdienen besondere Aufmerksamkeit. Die Revokation alter Zertifikate über DBX-Updates kann dazu führen, dass Linux-Bootloader, die mit den alten Zertifikaten signiert sind, nicht mehr starten. Prüfen Sie vorab, ob Ihre Linux-Distribution signierte Bootloader mit den neuen Zertifikaten bereitstellt.

Zusammenhang mit der BlackLotus-Revokation

Die UEFI CA 2023 Migration und die BlackLotus-Revokation (CVE-2023-24932) sind zwei parallele, aber miteinander verzahnte Prozesse. Die BlackLotus-Revokation sperrt verwundbare Boot Manager über die DBX-Sperrliste. Seit Mai 2023 ist der Patch verfügbar (KB5025885), die Enforcement-Phase mit automatischer Revokation ist für Anfang 2026 vorgesehen.

Beide Prozesse greifen auf dieselbe Secure Boot-Infrastruktur zu. Wer die Zertifikatsmigration nicht rechtzeitig abschließt und gleichzeitig von der BlackLotus-Revokation betroffen ist, steht vor einem doppelten Problem: Der alte Bootmanager wird gesperrt, aber ein neuer kann nicht installiert werden, weil die Signaturzertifikate abgelaufen sind.

Was passiert, wenn Sie nichts tun?

Das Nicht-Handeln hat abgestufte Konsequenzen:

Kurzfristig (bis Juni 2026) passiert nichts Sichtbares. Alle Systeme booten und funktionieren normal.

Ab Juni 2026 können Geräte mit abgelaufenen Zertifikaten keine neuen Bootmanager-Updates empfangen. Windows-Updates selbst funktionieren weiterhin, aber boot-level Sicherheitspatches — wie sie etwa für Bootkit-Schwachstellen nötig sind — können nicht mehr installiert werden.

Langfristig entsteht eine wachsende Sicherheitslücke auf Firmware-Ebene. Neue Schwachstellen im Bootprozess — vergleichbar mit BlackLotus — können nicht mehr gepatcht werden. Für Unternehmen, die Defense-in-Depth ernst nehmen, ist das keine akzeptable Position.

Firmware-Sicherheit als Teil der Härtungsstrategie

Die UEFI CA 2023 Migration ist kein isoliertes Zertifikatsprojekt, sondern ein Baustein der umfassenden Firmware-Sicherheit. In Kombination mit Virtualization-Based Security (VBS), Credential Guard und TPM-gestützter Attestierung bildet Secure Boot die Grundlage der hardwarebasierten Vertrauenskette in modernen Windows-Umgebungen.

Unternehmen, die bereits Secured-Core-Konfigurationen einsetzen oder planen, sollten die Zertifikatsmigration als Pflichtaufgabe betrachten — Secured-Core setzt funktionierendes Secure Boot zwingend voraus.

Ihre Firmware-Sicherheit ganzheitlich bewerten lassen. In unserem Systemhärtungs-Assessment prüfen wir den Secure Boot-Status, die Zertifikatskonfiguration und die gesamte Boot-Kette Ihrer Geräteflotte — und erstellen einen konkreten Migrationsplan mit Zeitplanung und Risikobewertung. Jetzt Systemhärtungs-Assessment anfragen.