Im Jahr 2026 laufen mehrere zentrale Secure-Boot-Zertifikate von Microsoft ab. Was zunächst wie ein technisches Detail wirkt, kann in der Praxis weitreichende Folgen haben: Systeme, deren Firmware die neuen Zertifikate nicht kennt oder aktualisieren kann, riskieren künftig Probleme bei Bootloader-Updates – im schlimmsten Fall startet das Betriebssystem nach einem Sicherheitsupdate nicht mehr.
Viele Unternehmen verlassen sich darauf, dass Windows Updates die notwendigen Änderungen automatisch durchführen. Genau das funktioniert jedoch nicht in jeder Umgebung. Abhängig von Firmware, Hardwarehersteller oder Virtualisierungsplattform können manuelle Maßnahmen erforderlich werden.
In diesem Beitrag erfahren Sie, welche Stichtage relevant sind, warum die Zertifikatsumstellung wichtig ist und wie Sie prüfen, ob Ihre physischen und virtuellen Systeme für die Änderungen vorbereitet sind.
Secure Boot ist eine Sicherheitsfunktion moderner Computer, die verhindert, dass beim Starten des Systems nicht vertrauenswürdige oder manipulierte Software geladen wird. Beim Einschalten prüft Secure Boot, ob die Firmware (UEFI) und das Betriebssystem mit gültigen, vom Hersteller signierten Zertifikaten versehen sind. Nur wenn diese Signaturen stimmen, wird der Bootvorgang fortgesetzt. Dadurch wird das Risiko von Schadsoftware, Rootkits oder unerwünschten Änderungen am Systemstart deutlich reduziert. Secure Boot ist vor allem in Unternehmensumgebungen und bei aktuellen Windows-Versionen ein wichtiger Bestandteil der Gerätesicherheit.
Microsoft stellt zwar kein einzelnes, offizielles “Riesen-Poster” als Flowchart bereit, aber der Prozess lässt sich in eine klare logische Kette unterteilen. Das Prinzip nennt sich Chain of Trust (Vertrauenskette): Jede Komponente überprüft die Signatur der nächsten, bevor sie diese ausführt.
Hier ist die detaillierte Funktionsweise:
Damit die Validierung funktioniert, nutzt das UEFI-BIOS vier Datenbanken, die im NVRAM (dem Speicher des Mainboards) liegen:
2. Der Boot-Ablauf (Das Flowchart im Detail)
Beim Einschalte des PCs läuft folgender Prozess ab:
Hardware-Start: Die CPU startet die UEFI-Firmware.
Firmware-Selbsttest: Die Firmware prüft ihre eigene Integrität. Wenn alles okay ist, sucht sie nach dem Bootloader (z.B. bootmgfw.efi).
Signatur-Extraktion: Die Firmware liest die digitale Signatur aus der Bootloader-Datei aus.
Die Sperr-Prüfung (dbx):
Die Firmware prüft, ob der Hash des Bootloaders in der dbx steht.
Falls ja: Boot-Vorgang wird sofort abgebrochen (Security Violation).
Die Erlaubnis-Prüfung (db):
Die Firmware prüft, ob die Signatur mit einem Zertifikat in der db übereinstimmt (z.B. dem Microsoft Windows Production PCA).
Falls gültig: Die Firmware führt den Bootloader aus.
Falls ungültig: Der Start wird blockiert.
Übergabe an Windows: Der Windows Boot Manager übernimmt und verifiziert nach dem gleichen Prinzip den Windows-Kernel, die Treiber und das ELAM-Modul (Frühstart-Antiviren-Programm).
Entgegen der häufigen Annahme gibt es keinen einzelnen Stichtag, an dem Systeme plötzlich nicht mehr starten. Microsoft verwendet verschiedene Zertifikate für unterschiedliche Aufgaben im Secure-Boot-Prozess – entsprechend laufen sie zu unterschiedlichen Zeitpunkten im Jahr 2026 ab. Entscheidend ist dabei weniger das eigentliche Ablaufdatum als die Zeit danach: Sobald Microsoft sicherheitsrelevante Updates für den Windows Boot Manager oder andere Boot-Komponenten mit den neuen 2023-Zertifikaten signiert, müssen diese Zertifikate bereits auf den betroffenen Systemen vorhanden sein. Dafür müssen die neuen Secure-Boot-Variablen im UEFI-NVRAM des Systems hinterlegt werden. Genau hier liegt jedoch die Herausforderung: Befindet sich ein Gerät beispielsweise im Setup Mode oder verhindert der Hardwarehersteller Änderungen an den Secure-Boot-Variablen, kann Windows die neuen Zertifikate nicht automatisch installieren. In diesem Fall schlagen spätere Bootloader-Updates fehl oder Sicherheitsupdates können nicht mehr eingespielt werden.
Entgegen mancher Panikmache werden die PCs im Unternehmen am 24. oder 27. Juni nicht plötzlich den Dienst verweigern oder explodieren. Microsoft hat klargestellt:
Systeme booten weiterhin: Ein bereits installierter Bootloader wird meist auch nach Ablauf des Zertifikats geladen, solange die Firmware den Zeitstempel der Signatur akzeptiert (was die meisten UEFI-Implementierungen tun).
Das Problem ist das „Danach“: Wenn nach diesem Datum ein Sicherheits-Patch für den Windows Boot Manager erscheint (z. B. gegen eine neue Zero-Day-Lücke), wird dieser mit dem neuen 2023er Zertifikat signiert sein. Wenn das BIOS/UEFI dieses neue Zertifikat nicht kennt, wird es das Update ablehnen – das System bleibt auf einem alten, unsicheren Stand hängen oder bootet nach dem Update gar nicht mehr.
Microsoft stellt genau das im April bereit:
https://msrc.microsoft.com/update-guide/releaseNote/2026-Apr
Mit dem langen Einzeiler lässt sich schön darstellen, welche UEFI-Zertifikate noch fehlen:
$k=[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes);$d=[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes);[pscustomobject]@{KEK_2023=$k -match 'Microsoft Corporation KEK 2K CA 2023';Windows_UEFI_CA_2023=$d -match 'Windows UEFI CA 2023';Microsoft_UEFI_CA_2023=$d -match 'Microsoft UEFI CA 2023';OptionROM_UEFI_CA_2023=$d -match 'Microsoft Option ROM UEFI CA 2023'}
Wenn man den gebündelten Status verschiedener Werte und deren Ablauf sehen möchte, steht hier ein Skript bereit: SecureBootInventoryDataCollection.ps1
Vorher
Nachher
Der Aktualisierungsprozess variiert je nach Mainboard-Hersteller erheblich. Bei HP-Systemen mit „HP Sure Start“ kann es beispielsweise zu Komplikationen kommen, da diese proprietären BIOS-Schutzmechanismen den Schreibzugriff auf das NVRAM einschränken oder das Zurücksetzen der Zertifikate blockieren können.
Zu beachten ist auch BitLocker, da bei Manipulationen in diesem Bereich die Daten wieder entschlüsselt werden müssen. Beim normalen OS-/Windows-gesteuerten Einspielen der Microsoft Secure-Boot-2023-Zertifikate ist ein vorheriges Pausieren von BitLocker in der Regel nicht zwingend erforderlich. Microsoft nennt aber explizit, dass bei veralteter Firmware oder fehlgeschlagenen Zertifikatsupdates BitLocker-Recovery-Prompts, Boot-Hänger oder Boot-Fehler auftreten können, deshalb sind Pilotierung, Firmware-Stand und Recovery-Key-Verfügbarkeit wichtig (siehe auch unten bei Referenzen: Update Secure Boot Certificates for Windows Devices).
Es gibt zwei Möglichkeiten, um Kopfschmerzen bei einem potenziellen Fehlerfall vorzubeugen. Entweder pausieren oder den Code zum Entsperren aufschreiben.
Kann übersprungen werden, wenn die Firmware der Hardware aktuell ist.
BitLocker verwalten im Startmenü suchen → Schutz anhalten
oder den PowerShell Befehl ausführen
Suspend-BitLocker -MountPoint "C:" -RebootCount 2
Einmal im Entra ID-Konto speichern, falls vorhanden. Anklicken, dauert ein paar Sekunden. Fertig. Keine weiteren Schritte nötig.
Dann Wiederherstellungsschlüssel drucken (sicher ist sicher) → Beliebigen Drucker oder Print to PDF auswählen
Nachdem wir die Bedenken bezüglich BitLocker ausgeräumt haben, können wir das Opt-in-Flag zum bevorzugten Installieren des neuen Zertifikats aktivieren.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "MicrosoftUpdateManagedOptIn" -Value 1 -Type DWord
Soll im Registry so aussehen
Mit dem Registry-Schlüssel können wir das Update bzw. den Rollout der neuen Zertifikate auslösen. Der Wert 0x5944 ist eine Bitmaske und kombiniert mehrere Secure-Boot-Update-Aktionen. Damit werden die relevanten 2023-Zertifikate in KEK bzw. DB ausgerollt und der Windows Boot Manager auf die 2023-signierte Variante aktualisiert. Während der Verarbeitung löscht Windows erfolgreich abgeschlossene Bits automatisch aus AvailableUpdates. Ein temporärer Wert wie 0x4100 zeigt an, dass ein Neustart erforderlich ist, bevor die Boot-Manager-Aktualisierung vollständig abgeschlossen werden kann.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Nach dem Setzen des Registry-Werts wird der Update-Prozess durch Windows verarbeitet. Je nach Systemzustand und Firmware kann hierfür ein Neustart erforderlich sein.
Mit dem Task werden die eigentlichen Aufgaben gestartet. Die obigen Registry-Werte sind die Voraussetzung, dass dieser Task die Arbeit tatsächlich durchführt.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
1.
Dauer ca. 2 Minuten
2.
4. System neustarten
Nach dem Neustart soll die Abfrage ähnlich aussehen
Dies kann zu einem zufälligen vollständigen Systemfreeze führen, der nur durch langes Drücken des Power-Buttons zum kontrollierten Herunterfahren gebracht werden kann, da der Prozess wiederholt versucht wurde, jedoch nicht ausgeführt werden konnte.
Man kann danach unter Windows Events bei der TPM-WMI Quelle (EventID 1801) folgende Meldung sehen:
Abhilfe können folgende PowerShell Befehle schaffen:
Voraussetzungen und Checks:
Install-Module UEFIv2 -Force Get-UEFISecureBootCerts db | select SignatureSubject Get-UEFISecureBootCerts kek | select SignatureSubject
Update forcieren
WinCsFlags.exe /apply --key "F33E0C8E002" Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Wenn fertig, Flag wieder zurückdrehen
WinCsFlags.exe /apply --key "F33E0C8E001"
Eine Aktualisierung des NVRAMs ist bei Citrix-VMs nicht ohne Weiteres möglich, da diese Informationen aus der Metadatensammlung des Templates bezogen und nicht dynamisch vom Betriebssystem überschrieben werden können. Administratoren müssen hier das Basis-Template aktualisieren und die betroffenen VMs neu aus dem geänderten Template bereitstellen (Re-provisioning). Siehe auch für PVS:
Hier ist ein Skript für XenServer um eine Übersicht erstellen zu können:
#!/bin/bash
# Print Table Header
printf "%-30s | %-36s | %-12s | %-36s | %-12s\n" "VM Name" "KEK GUID" "KEK 2023" "DB GUID" "DB 2023"
echo "$(printf '%0.s-' {1..140})"
# Get list of all VM UUIDs
vms=$(xe vm-list is-control-domain=false params=uuid --minimal | tr ',' ' ')
for vm_uuid in $vms; do
vm_name=$(xe vm-list uuid=$vm_uuid params=name-label --minimal)
# Discover all GUIDs present in this VM's varstore
mapfile -t guids < <(varstore-ls "$vm_uuid" 2>/dev/null | awk '{print $1}' | sort -u)
kek_guid=""
kek_status="MISSING"
db_guid=""
db_status="MISSING"
for guid in "${guids[@]}"; do
# Discover variable names under this GUID
mapfile -t varnames < <(varstore-ls "$vm_uuid" 2>/dev/null | awk -v g="$guid" '$1==g {print $2}')
for varname in "${varnames[@]}"; do
lower_var=$(echo "$varname" | tr '[:upper:]' '[:lower:]')
if [[ "$lower_var" == "kek" ]]; then
kek_guid="$guid"
if varstore-get "$vm_uuid" "$guid" "$varname" 2>/dev/null | strings | grep -q "2023"; then
kek_status="INSTALLED"
else
kek_status="MISSING"
fi
fi
if [[ "$lower_var" == "db" ]]; then
db_guid="$guid"
if varstore-get "$vm_uuid" "$guid" "$varname" 2>/dev/null | strings | grep -q "2023"; then
db_status="INSTALLED"
else
db_status="MISSING"
fi
fi
done
done
printf "%-30s | %-36s | %-12s | %-36s | %-12s\n" \
"$vm_name" \
"${kek_guid:-NOT FOUND}" "$kek_status" \
"${db_guid:-NOT FOUND}" "$db_status"
done
VMware-Tipp: Das Löschen der .nvram-Datei erzwingt eine Neukonfiguration der UEFI-Variablen beim Neustart. Mit vSphere 8.0 Update 3h (oder vSphere 9) werden dabei automatisch die neuen, gültigen Zertifikate hinterlegt. Beachte jedoch, dass durch das Zurücksetzen eventuell manuell konfigurierte Boot-Einträge verloren gehen und nach dem Neustart neu eingerichtet werden müssen.
Microsoft stellt für Azure Virtual Desktop eine eigene Referenz zum Secure-Boot-2023-Zertifikatsupdate bereit. Darin wird beschrieben, welche AVD-Session-Hosts und Golden Images betroffen sind, wie der Update-Status überwacht werden kann und welche Rollout-Methoden, z. B. Intune, GPO, Registry oder Windows Update, unterstützt werden.
Secure Boot Certificate Updates for Azure Virtual Desktop – Microsoft Support
Fazit
Es gibt sowohl auf materieller als auch auf virtueller Ebene Handlungsbedarf, um unangenehmen Überraschungen aus dem Weg zu gehen.
Auf physischen Rechnern sollte man sich vorab informieren, ob der Hardwarehersteller Besonderheiten vorsieht, die beachtet werden müssen, und den oben beschriebenen Prozess entsprechend anpassen.
Für die virtuelle Welt empfehlen wir generell, die betroffenen VMs, Clones und Kataloge mit neuen Templates neu aufzubauen. Das Klonen einer alten VM kann später zu unerwarteten Problemen führen: Stammt das Zertifikat im Katalog aus dem alten Master oder Template, erhält ein frisch erstelltes System weiterhin das alte Zertifikat und kann nicht mehr hochfahren und dadurch auch nicht gepatcht werden.
Microsoft-Anleitung für Secure-Boot-Zertifikate von Windows Servern | heise online
Windows Server Secure Boot playbook for certificates expiring in 2026 | Microsoft Community Hub
Sample Secure Boot Inventory Data Collection script – Microsoft Support
Secure Boot Certificate updates: Guidance for IT professionals and organizations – Microsoft Support
Registry key updates for Secure Boot: Windows devices with IT-managed updates – Microsoft Support
January 13, 2026—KB5073724 (OS Builds 19045.6809 and 19044.6809) – Microsoft Support
Secure Boot certificates have been updated but are not yet applied – Microsoft Q&A
Wir sind für Sie da.
Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen?
Wir sind gerne für Sie da.
HEIKO WESSELS
Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an
Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.
