Secure Boot Zertifikate 2026: Prüfung per PowerShell

Die ursprünglichen Secure Boot Zertifikate aus dem Jahr 2011 verlieren 2026 ihre Gültigkeit. Konkret betrifft dies die KEK-Zertifizierungsstelle am 24. Juni 2026, die Zertifikate für Drittanbieter am 27. Juni 2026 und die Windows-Produktions-CA am 19. Oktober 2026. Systeme ohne die neuen 2023-Zertifikate starten nach diesen Daten zwar weiterhin ins Windows-Betriebssystem und installieren Standardupdates.

Sie verlieren jedoch die Fähigkeit, neue Sicherheitsupdates für den frühen Boot-Prozess zu verarbeiten. Die UEFI-Firmware blockiert künftig alle neuen Startladeprogramme und DBX-Sperrlisten, da die kryptografische Vertrauenskette für diese Komponenten fehlt. Im Laufe der Zeit schränkt dies den Schutz vor neuen Bootkits massiv ein und bricht Vertrauensstellungen für BitLocker-Härtungen.

Die Architektur: PK, KEK, DB und der Zertifikats-Split

Um den Handlungsbedarf zu verstehen, musst du die Hierarchie der UEFI-Schlüssel betrachten. Der Plattformschlüssel (PK) des Hardwareherstellers bildet die Wurzel. Darunter liegt der Key Enrollment Key (KEK). Er autorisiert Änderungen an der Allowed Signature Database (DB) und der Revoked Signature Database (DBX).

Microsoft tauscht aktuell folgende Schlüssel aus:

KEK-Ebene: Die „Microsoft Corporation KEK CA 2011“ wird durch die „Microsoft Corporation KEK 2K CA 2023“ ersetzt. Ohne diesen neuen KEK verweigert die Firmware künftig jedes Update der DB und DBX.
DB-Ebene (Windows): Die „Microsoft Windows Production PCA 2011“ weicht der „Windows UEFI CA 2023“. Diese signiert den eigentlichen Windows-Bootloader.
DB-Ebene (Drittanbieter): Hier gibt es eine technische Abspaltung. Das alte Zertifikat „Microsoft UEFI CA 2011“ verifizierte bisher Bootloader von Drittanbietern und Option-ROMs von Hardware-Erweiterungskarten gleichermaßen. Microsoft spaltet dies in zwei neue Zertifikate auf: „Microsoft UEFI CA 2023“ für Drittanbieter-Bootloader und „Microsoft Option ROM UEFI CA 2023“ exklusiv für Option-ROMs.

Diese logische Trennung verhindert ein Ausnutzen der Bootloader-Vertrauensstellung durch kompromittierte Hardware-ROMs. Du kontrollierst das Systemvertrauen damit wesentlich präziser.

Inventarisierung der Umgebung per PowerShell

Bevor du Updates verteilst, musst du den Ist-Zustand erfassen. Ein manuelles Auslesen der UEFI-Variablen skaliert in Unternehmensnetzwerken nicht. Nutze stattdessen das folgende PowerShell-Skript. Der Code stammt von MVP Patrick Gruenauer (Blog SID-500.COM) und fragt die Secure Boot Datenbank der Active Directory Computer über WinRM ab.

Für die Ausführung auf Server-Systemen benötigst du entsprechende lokale administrative Berechtigungen. Ich nutze hierfür strikt abgetrennte Konten aus meinem angepassten Tier-3-Administrationsmodell, um die Rechteausweitung im Netzwerk zu verhindern.

# Retrieve all computers in Active Directory and check for the presence of the "UEFI CA 2023" certificate
# Prerequisite: Neccesary permissions to access remote computers and PS Remoting enabled on target machines (via GPO or Enable-PSRemoting)
$cred = Get-Credential -Message "Enter credentials with access to remote computers"
Get-ADComputer -Filter * | ForEach-Object {
    $computerName = $_.Name
    $secureBootInfo = Invoke-Command -ComputerName $computerName -Credential $cred -ScriptBlock {
        [System.Text.Encoding]::ASCII.GetString(
        (Get-SecureBootUEFI -Name db).Bytes
        ) -match "UEFI CA 2023" # sollte 2023 sein
    }
    if ($secureBootInfo -eq $true) {
        [PSCustomObject]@{
            ComputerName = $computerName
            CertficateStatus = "UEFI CA 2023 found"
        }
    } else {
        [PSCustomObject]@{
            ComputerName = $computerName
            CertficateStatus = "UEFI CA 2023 NOT !!! found"
        }
    }
} | Format-Table -AutoSize

Anleitung: Zertifikate aktualisieren

Die Aktualisierung erfolgt durch das Beschreiben des NVRAM (Non-Volatile Random-Access Memory) auf dem Mainboard. Microsoft liefert die neuen Zertifikate als reguläres Update für Windows aus. Das Betriebssystem injiziert die Firmware-Schlüssel während des nächsten Neustarts. Bei älteren OEM-Geräten ist ein dediziertes UEFI-Update des Hardware-Herstellers zwingend, da diese automatische Windows-Updates für Firmware-Variablen oft blockieren.

Schritt 1: BitLocker-Schutz temporär aussetzen

Jede Änderung am KEK oder der DB verändert die PCR-Werte (Platform Configuration Registers) im TPM (Trusted Platform Module). Ist BitLocker aktiv, erkennt das TPM eine Abweichung im Boot-Prozess und sperrt das Laufwerk. Das System verlangt beim Neustart den 48-stelligen Wiederherstellungsschlüssel. Pausiere den Schutz daher zwingend vor der Verteilung.

Alternativ überwachst du dies per PowerShell auf den Endpunkten:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

Schritt 2: Updates ausrollen

Stelle sicher, dass die Geräte die aktuellen Windows-Updates abholen und installieren. Für Geräte ohne Unterstützung für Firmware-Updates via Windows Update lädst du die Management-Tools des jeweiligen Herstellers herunter und verteilst die anstehenden BIOS-Aktualisierungen über deine Softwareverteilung.

Schritt 3: Verifizierung nach Neustart

Das eigentliche Beschreiben der UEFI-Variablen passiert beim Booten. Nach dem erfolgreichen Startvorgang läuft BitLocker automatisch weiter. Nutze das obige PowerShell-Skript erneut, um den Rollout-Erfolg deiner Flotte zu validieren.

Betrachtung der Migration

Der Wechsel auf die 2023-Zertifikate ist ein Stresstest für dein Lifecycle-Management. Die UEFI-Implementierungen der Hersteller sind stark fragmentiert. Während moderne Systeme die neuen Werte direkt über Windows Update in den NVRAM schreiben, blockieren ältere Mainboards den Import. Hier musst du das BIOS manuell flashen.

Ein kritisches Risiko bildet das Zusammenspiel mit Festplattenverschlüsselungen. Verteilst du die Zertifikate automatisiert, ohne BitLocker vorher zu pausieren, provozierst du sofortige Recovery-Szenarios auf allen Endgeräten. Du musst deine Skripte für die Softwareverteilung penibel anpassen.

Die Aufspaltung der Zertifikate in Bootloader und Option-ROMs bringt dir mehr Kontrolle. Ein schädliches Firmware-Modul auf einer Erweiterungskarte kann die Vertrauensstellung des Bootloaders nun nicht mehr missbrauchen.

Wer diese Migration aussitzt, betreibt seine Systeme ab Mitte 2026 de facto ungepatcht auf Firmware-Ebene, da das System neue Malware-Signaturen für die DBX strikt abweist. Der administrative Aufwand ist hoch. Aber ein ungeschützter Boot-Vorgang bietet aktuellen Bootkits eine direkte Angriffsfläche.