Secure Boot Zertifikat-Austausch 2026 — UEFI CA 2023 Deep Dive für Admins

Warum 2026 ein Pflichttermin für jeden Admin ist

Secure Boot ist seit 2012 das Fundament dafür, dass Windows-Geräte beim Einschalten nur signierten Code laden. Hinter dieser Garantie steht eine kleine, sehr stabile Public-Key-Infrastruktur, die Microsoft beim Start der Windows-8-Ära aufgebaut hat. Drei dieser Wurzelzertifikate erreichen 2026 ihr Ablaufdatum: zwei im Juni, eines im Oktober. Microsoft tauscht sie planmäßig gegen neue Generationen aus — die 2023er-Zertifikatsfamilie.

Für Administratoren ist das kein „interessanter Hintergrund", sondern ein konkreter Rollout. Ohne den Wechsel verliert ein Gerät zwar nicht die Fähigkeit zu booten — es verliert aber die Fähigkeit, künftige Boot-Manager-Updates, Datenbank-Updates und Bootkit-Revocation-Listen zu erhalten. In einer Welt mit aktiven UEFI-Bootkits wie BlackLotus (CVE-2023-24932) ist das eine Sicherheitslücke mit Ablaufdatum.

Der gute Teil: Microsoft hat den Rollout sauber dokumentiert, die PowerShell-Cmdlets sind etabliert, der Update-Mechanismus läuft über die regulären kumulativen Updates. Der weniger gute Teil: Der Rollout ist opt-in-getrieben, läuft über mehrere Reboots, hat Stolperfallen bei Hyper-V-VMs, älterer OEM-Firmware und BitLocker — und ohne aktive Statusprüfung weiß niemand im Haus, wie weit der Bestand wirklich ist.

• 3 Zertifikate ablaufend
• 2 Deadlines: 06/2026 und 10/2026
• Opt-In via Registry oder Intune
• Multi-Reboot-Rollout
• Hyper-V-Workaround nötig
• BitLocker-Recovery-Risiko

Welche Zertifikate ablaufen — und was sie ersetzt

Microsofts UEFI-Trust-Chain stützt sich auf drei aktive Wurzeln aus dem Jahr 2011, die jetzt rotiert werden:

Altes Zertifikat	Funktion	Ablauf	Neuer Nachfolger
Microsoft Corporation KEK CA 2011	Signiert DB- und DBX-Updates (Key Exchange Key)	06/2026	Microsoft Corporation KEK 2K CA 2023
Microsoft UEFI CA 2011	Signiert Drittanbieter-Bootloader (Shim, GRUB, EFI-Treiber)	06/2026	Microsoft UEFI CA 2023 + Microsoft Option ROM UEFI CA 2023
Microsoft Windows Production PCA 2011	Signiert den Windows-Boot-Manager bootmgfw.efi	10/2026	Windows UEFI CA 2023

Die Aufspaltung der UEFI CA in eine reine OS-Variante und eine separate Option ROM CA ist neu. Hintergrund: Microsoft trennt damit die Vertrauenskette für Drittanbieter-Bootloader von der Vertrauenskette für PCIe-Geräte mit eigener Boot-ROM (Storage-Controller, NICs, GPUs) — eine Lehre aus den Bootkit-Vorfällen der letzten Jahre, in denen Angreifer beide Pfade gleichermaßen ausnutzten.

Technischer Deep Dive: PK, KEK, DB, DBX

Wer die Update-Schritte verstehen will, muss kurz die Architektur verstehen. UEFI Secure Boot kennt vier Variablen-Familien, hierarchisch organisiert:

Variable	Rolle	Wer signiert sie	Wer darf sie ändern
PK (Platform Key)	Wurzel der Kette, ein Eintrag	Self-signed durch OEM	Niemand außer dem PK-Holder
KEK (Key Exchange Key)	Erlaubt Updates an DB und DBX	Vom PK signiert	OEM und Microsoft
DB (Allowed Signature Database)	Erlaubte Signaturen für Boot-Code	Vom KEK signiert	Microsoft (über KEK 2011/2023)
DBX (Forbidden Signature Database)	Sperrliste für widerrufene Bootloader	Vom KEK signiert	Microsoft

Beim Boot prüft die UEFI-Firmware: Ist die Signatur des Boot-Loaders in der DB hinterlegt — und gleichzeitig nicht in der DBX? Nur dann startet der Code. Diese Mechanik ist absichtlich starr: wer den PK kontrolliert, kontrolliert die Plattform.

Der 2026er-Wechsel betrifft Einträge in KEK (das KEK-2K-2023-Zertifikat kommt hinzu) und DB (die UEFI CA 2023 sowie die Windows UEFI CA 2023 kommen hinzu). PK und die OEM-Wurzeln bleiben unangetastet — Microsoft fügt nur eigene Schlüssel hinzu, sie ersetzen nichts. Das ist wichtig für die Reihenfolge: erst muss eine KEK-Variante installiert sein, die DB-Updates signieren darf, dann kann der DB-Eintrag erweitert werden, dann kann ein neuer Boot-Manager mit der 2023er-Signatur installiert werden.

Warum mehrere Reboots

Jeder Schritt braucht einen Reboot. Die UEFI-Firmware liest die Variablen beim Boot, übernimmt Änderungen aus dem laufenden System nur über den dafür vorgesehenen Pfad — eine Variable schreiben, neu starten, Firmware übernimmt sie. In der Praxis verteilt Windows die Aufgabe so:

• Reboot 1: Neue KEK-Einträge schreiben (Microsoft Corporation KEK 2K CA 2023).
• Reboot 2: Neue DB-Einträge schreiben (Windows UEFI CA 2023, Microsoft UEFI CA 2023, Option ROM UEFI CA 2023).
• Reboot 3: Boot-Manager auf eine mit Windows UEFI CA 2023 signierte Variante austauschen.
• Reboot 4 (optional): DBX-Update — Liste der widerrufenen alten Boot-Loader.

PowerShell-Status-Check — was wirklich da ist

Bevor irgendetwas ausgerollt wird, muss man wissen, wo der Bestand steht. Der Microsoft-Standard-Check für Administratoren läuft komplett über die SecureBoot-PowerShell-Module. Drei Befehle reichen für die Erstaufnahme:

# 1. Ist Secure Boot überhaupt aktiv?
Confirm-SecureBootUEFI
# Ergebnis: True = aktiviert, False = deaktiviert / nicht vorhanden

# 2. Steht die Windows UEFI CA 2023 schon in der DB?
[System.Text.Encoding]::ASCII.GetString( `
    (Get-SecureBootUEFI db).bytes `
) -match 'Windows UEFI CA 2023'

# 3. KEK 2K CA 2023 vorhanden?
[System.Text.Encoding]::ASCII.GetString( `
    (Get-SecureBootUEFI KEK).bytes `
) -match 'Microsoft Corporation KEK 2K CA 2023'

Alle drei Befehle liefern True oder False. Drei mal True ist das Zielbild. Wer Geräteflotten verwalten will, packt das in ein Inventar-Skript und schreibt es in eine zentrale Datenbank, ein SIEM oder eine CSV — typischerweise per RMM oder Intune-Proactive-Remediation.

Komplettes Inventar-Skript (kopierfertig)

# Secure-Boot-2023-Inventur für eine Maschine
# Liefert ein PSCustomObject zur weiteren Verarbeitung

function Get-SecureBoot2023Status {
    if (-not (Confirm-SecureBootUEFI)) {
        return [PSCustomObject]@{
            Hostname = $env:COMPUTERNAME
            SecureBoot = $false
            WinUEFI2023 = $null
            UEFI2023 = $null
            OptionROM2023 = $null
            KEK2K2023 = $null
        }
    }

    $db  = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
    $kek = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)

    [PSCustomObject]@{
        Hostname      = $env:COMPUTERNAME
        SecureBoot    = $true
        WinUEFI2023   = $db  -match 'Windows UEFI CA 2023'
        UEFI2023      = $db  -match 'Microsoft UEFI CA 2023'
        OptionROM2023 = $db  -match 'Option ROM UEFI CA 2023'
        KEK2K2023     = $kek -match 'Microsoft Corporation KEK 2K CA 2023'
    }
}

# Lokal ausführen
$status = Get-SecureBoot2023Status
$status | Format-Table -AutoSize

# Cluster-weit per WinRM
$hosts = Get-ADComputer -Filter {OperatingSystem -like "Windows Server*"} | Select-Object -Expand Name
$report = Invoke-Command -ComputerName $hosts -ScriptBlock ${function:Get-SecureBoot2023Status} -ErrorAction SilentlyContinue
$report | Export-Csv -Path "C:\Reports\secureboot-2026.csv" -NoTypeInformation

Wer noch tiefer reingehen möchte — etwa um die DBX-Revocation-Liste oder den Boot-Manager-Hash zu prüfen — verwendet die DBX-Variante:

# DBX-Revocation-Stand erheben (Größe in Bytes)
$dbx = (Get-SecureBootUEFI dbx).bytes
Write-Host "DBX-Größe: $($dbx.Length) Bytes"

# Aktuell signierten Boot-Manager prüfen
mountvol S: /S
$bm = Get-AuthenticodeSignature -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi"
$bm.SignerCertificate | Format-List Subject, Issuer, NotAfter
mountvol S: /D

Im Issuer-Feld steht entweder Microsoft Windows Production PCA 2011 (alt) oder Windows UEFI CA 2023 (neu). Das ist die einfachste Wahrheit über den Boot-Manager-Stand des konkreten Geräts.

Schritt 1 — OEM-UEFI-Firmware aktualisieren

Bevor die Microsoft-Update-Seite Wirkung entfalten kann, muss die OEM-Firmware mitspielen. Lenovo, Dell, HPE, Fujitsu und Supermicro liefern seit 2024 BIOS-Versionen aus, die die 2023er-Wurzeln bereits in ihrer Default-Datenbank mitbringen. Auf älteren Firmware-Ständen kann das Microsoft-Update einzelne Variablen nicht oder nur unvollständig schreiben.

Konkret betrifft das vor allem:

• Lenovo ThinkSystem V2/V3-Serie — BIOS-Versionen ab Mitte 2024 enthalten KEK 2K 2023.
• Dell PowerEdge 14G/15G/16G — Lifecycle Controller Update auf 1.10 oder neuer.
• HPE ProLiant Gen10/Gen11 — über iLO Service Pack for ProLiant (SPP) ab Q3/2024.
• Fujitsu PRIMERGY M5/M6 — über ServerView Update Manager.
• Notebooks vor Baujahr 2020 — kritischer Punkt; teilweise gar kein Update mehr verfügbar. Hier empfiehlt Microsoft die Geräte ggf. abzuschreiben oder im Status „nicht aktualisiert" zu belassen, sofern keine Sicherheitsanforderung dagegen spricht.

Schritt 2 — Rollout aktivieren (Registry, GPO, Intune)

Microsoft bietet vier Pfade, den 2023er-Rollout aktiv anzustoßen. Welcher passt, hängt vom Management-Stack ab:

Pfad A — Automatisch via Windows Update (empfohlen für Desktops)

Wenn die Geräte normale Windows-Updates beziehen und die Telemetrie-Daten mindestens auf Required stehen, übernimmt Microsoft die phasenweise Verteilung selbständig. Der Rollout begann im April 2024 als optionales Preview-Update und wurde 2025 schrittweise zur Default-Auslieferung. Für die meisten Endpunkt-Flotten (Intune, WSUS mit Standard-Settings) ist das ausreichend — sofern die Telemetrie-Stufe stimmt.

Pfad B — Registry-Opt-In (gezielter Push für Server)

Für Server, in denen man den Rollout aktiv steuern möchte, setzt man zwei DWORD-Werte und löst die geplante Aufgabe aus:

# 1. Microsoft-managed Opt-In aktivieren
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot"
New-ItemProperty -Path $path `
    -Name "MicrosoftUpdateManagedOptIn" `
    -Value 0x5944 -PropertyType DWord -Force

# 2. AvailableUpdates auf den vollen Bundle-Wert
#    0x5944 = alle Schritte: KEK + DB + Boot-Manager + DBX
#    0x100  = nur Boot-Manager auf 2023er Signatur
New-ItemProperty -Path $path `
    -Name "AvailableUpdates" `
    -Value 0x5944 -PropertyType DWord -Force

# 3. Geplante Aufgabe sofort starten (sonst wartet sie auf nächsten Idle)
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

# 4. Reboot — danach erneut Skript laufen lassen für nächsten Schritt
Restart-Computer -Force

Die Werte AvailableUpdates sind Bitmasken — Microsoft dokumentiert 0x100 für „nur Boot-Manager", 0x40 und 0x80 für DB-Schritte und 0x5944 als Sammelwert „komplettes Bundle". Für die meisten Umgebungen ist 0x5944 richtig.

Pfad C — Group Policy

Ab April-2025-ADMX-Templates verfügbar unter:

Die Policy übernimmt die Registry-Konfiguration zentral. Vorteil: Rollback per GPO entfernen, kein lokaler Eingriff nötig. Nachteil: greift nur auf Domain-Membern.

Pfad D — Microsoft Intune

Im Intune Admin Center unter Endpoint Security → Account Protection → Profile ein Profil mit Vorlage „Secure Boot certificate deployment" anlegen. Drei Policies werden konfiguriert:

• KEK 2023 Update — fügt das KEK-2K-2023-Zertifikat hinzu.
• DB 2023 Update — fügt UEFI CA 2023 / Option ROM UEFI CA 2023 / Windows UEFI CA 2023 hinzu.
• Boot Manager 2023 Update — tauscht bootmgfw.efi.

Intune verteilt die Profile nach Pilot-Ring (Test → Pilot → Broad), Status ist im Bericht „Secure Boot certificate update" sichtbar.

Spezialfall Hyper-V — die Generation-2-Falle

Generation-2-VMs unter Hyper-V haben ihre eigene UEFI-Firmware mit eigener Variablen-Datenbank. Das Microsoft-Update läuft im Gast ab — die Host-Firmware ist davon unbeeinflusst. Der Standardfall klappt: Gast-Update läuft, neue 2023er-Einträge werden in die VM-Firmware geschrieben, Boot-Manager wird ausgetauscht.

Der häufige Problemfall: Wenn die VM mit einem älteren Hyper-V-Host erzeugt wurde und ihr Secure-Boot-Template noch auf MicrosoftWindows mit dem 2011er-DB-Stand steht, schlägt der KEK-Update-Schritt fehl. Im System-Log erscheint:

Event ID 1795 — Source: Microsoft-Windows-Kernel-Boot

The system firmware returned an error when attempting to
update a Secure Boot variable: Microsoft Corporation KEK 2K CA 2023
Status: 0xC0000013 (The media is write protected.)

Ursache: Die Hyper-V-Firmware der VM kennt das alte KEK-Datenbank-Layout, akzeptiert aber kein Schreiben mehr. Workaround:

• VM herunterfahren. Volles Shutdown, kein Save State.
• Template wechseln. In den VM-Einstellungen unter Sicherheit das Secure-Boot-Template einmal auf Microsoft UEFI Certificate Authority umstellen, anwenden.
• Zurück auf Windows-Template. Erneut auf Microsoft Windows stellen, anwenden. Damit wird die VM-Firmware mit dem aktuellen Datenbank-Stand des Hyper-V-Hosts neu provisioniert.
• VM starten. Im Gast den Update-Pfad erneut anstoßen — KEK-Schritt klappt jetzt.

Der gleiche Effekt lässt sich auch ohne GUI per PowerShell skripten:

# Secure-Boot-Template einer Gen2-VM neu provisionieren
$vm = "sql-prod-01"

Stop-VM -Name $vm -Force

# Einmal auf UEFI CA umschalten
Set-VMFirmware -VMName $vm `
    -SecureBootTemplate "MicrosoftUEFICertificateAuthority"

# Zurück auf Windows-Template — DB wird neu beschrieben
Set-VMFirmware -VMName $vm `
    -SecureBootTemplate "MicrosoftWindows"

Start-VM -Name $vm

Spezialfall Proxmox VE — qm enroll-efi-keys und ms-cert=2023w

Wer Windows-Gäste auf Proxmox VE betreibt, muss den 2023er-Rollout zweistufig denken: die Host-Seite (das Proxmox-System selbst) und die Gast-Seite (jede einzelne VM mit ihrer eigenen OVMF-Firmware-Vars-Disk). Beide haben einen anderen Lifecycle.

Host-Seite — Proxmox-Boot mit Shim und MOK

Seit Proxmox VE 8.1 (November 2023) bringt Proxmox einen Microsoft-signierten Shim mit, in dem der Proxmox-eigene Public-Key als Machine Owner Key (MOK) eingebettet ist. Der Host-Boot-Prozess hängt damit nur noch indirekt am Microsoft-CA-Wechsel — solange das Shim weiterhin gültig signiert ist, bootet der Proxmox-Kernel sauber. Praktisch heißt das: Der Host braucht für den 2026er-Wechsel keinen manuellen Eingriff, sofern das System normal mit apt-Updates gepflegt wird.

Gast-Seite — die OVMF-Vars-Disk pro VM

Jede Windows-VM auf Proxmox bekommt beim Anlegen eine eigene efidisk0, in der KEK, DB und DBX persistiert werden. Das Problem: Diese Vars-Disk wird beim Erzeugen aus einem Template kopiert — und ältere Templates enthalten ausschließlich die 2011er-Wurzeln. Damit landen Microsofts In-Guest-Update-Versuche ins Leere und die Logs des Gasts melden Event-ID 1795 oder 1801.

Proxmox hat dafür ab qemu-server 9.1.4 (in Proxmox VE 9.1) das Cert-Set über die VM-Konfiguration steuerbar gemacht. Der relevante Parameter ist ms-cert auf der efidisk0:

# /etc/pve/qemu-server/100.conf — Auszug
efidisk0: local-zfs:vm-100-disk-0,efitype=4m,ms-cert=2023w,pre-enrolled-keys=1,size=528K
bios: ovmf
machine: q35
# ms-cert-Werte:
#   2011   = Legacy: nur Microsoft-CA-2011-Wurzeln
#   2023w  = Aktuell: 2023er-Windows-Wurzeln (Default in PVE 9.1+ neu erstellte VMs)
#   2023r  = Reserviert für zukünftige Rotation

Frisch in Proxmox VE 9.1 angelegte Windows-VMs erhalten automatisch ms-cert=2023w und sind damit ab Sekunde Null bereit. Bestands-VMs müssen umkonfiguriert werden.

Bestands-VMs umstellen — drei Wege

Weg 1 — Per qm-CLI (empfohlen für Windows 10/11):

# EFI-Vars neu mit 2023-Schlüsseln initialisieren
# Funktioniert offiziell für Windows 10/11 — Windows Server ist explizit ausgenommen
qm enroll-efi-keys 100

# Anschließend VM neu starten, damit OVMF die neue Vars-Disk übernimmt
qm stop 100 && qm start 100

Weg 2 — Per VM-Konfiguration (für Server 2019/2022/2025):

# ms-cert-Wert direkt im VM-Config setzen (qemu-server >= 9.1.4)
qm set 100 --efidisk0 local-zfs:vm-100-disk-0,efitype=4m,ms-cert=2023w,pre-enrolled-keys=1

# Reboot der VM, damit OVMF die neue Vars-Disk lädt
qm reboot 100

Weg 3 — Per Schleife für ganze Cluster:

# Alle laufenden Windows-VMs erkennen und umstellen
for vmid in $(qm list | awk '/running/ {print $1}'); do
    if qm config $vmid | grep -q "ostype: win"; then
        echo "Updating VM $vmid..."
        qm set $vmid --efidisk0 "$(qm config $vmid | grep ^efidisk0: | cut -d: -f2-),ms-cert=2023w"
    fi
done

Voraussetzungen prüfen

# Auf dem Proxmox-Host prüfen:
pveversion -v | grep -E "qemu-server|pve-edk2-firmware"

# Soll-Stand für 2023-Cert-Support:
#   qemu-server         >= 9.1.4
#   pve-edk2-firmware   >= 4.2025.05-1

# PVE-Version selbst:
pveversion
# Empfohlen: Proxmox VE 9.1 oder neuer
# PVE 8.x: kein offizieller Backport — Upgrade-Pfad auf 9.x einplanen

Proxmox-VE-8-Cluster ohne Update-Pfad auf 9.x sind hier ein echter Stolperstein: Es gibt keinen offiziellen Backport der 2023-Cert-Funktionalität. Wer Windows-Gäste mit Secure Boot auf PVE 8 hostet, sollte den 9.x-Upgrade bis Sommer 2026 fest einplanen — sonst läuft die Microsoft-Update-Logik im Gast in eine Sackgasse.

Host-vs-Gast-Matrix — was passiert in welcher Kombination

In Mischumgebungen (manche Hosts mit Secure Boot, andere ohne; manche VMs mit aktivem Secure Boot in OVMF, andere ohne) ist die wichtigste Frage: Was bricht eigentlich, wenn beide Seiten nicht aufeinander abgestimmt sind? Die kurze Antwort: Host- und Gast-Secure-Boot sind unabhängige Vertrauensketten — der Host validiert seinen eigenen Kernel, die VM validiert ihren eigenen Boot-Loader. Trotzdem gibt es Wechselwirkungen.

Host Secure Boot	VM Secure Boot	Bootet?	Konsequenz / Risiko
An	An	Ja ✓	Soll-Zustand. Host-Kernel über Microsoft-Shim+Proxmox-MOK validiert, VM-Boot-Loader über OVMF-DB im Gast. Beide Ketten unabhängig — das CA-Update 2026 muss in beiden Ebenen ausgerollt werden (Host via apt, VM via ms-cert=2023w + In-Guest-Update).
An	Aus	Ja ✓	Funktioniert, aber Lücke im Gast. Host-Kette ist sauber, in der VM kann beliebiger unsignierter Boot-Code laufen — also auch Bootkits wie BlackLotus. Der Host „schützt" die VM nicht, weil er nur seine eigene Boot-Kette prüft. Sinnvoll nur für Linux-Distros ohne Shim oder bewusste Test-VMs. Für Windows-Gäste in Produktion: VM-Secure-Boot aktivieren.
Aus	An	Ja ✓	Funktioniert technisch, aber gefährlich. Die VM glaubt, in einer vertrauenswürdigen Boot-Umgebung zu laufen — der Host kann aber kompromittiert sein (manipulierte OVMF-Firmware, Rootkit im Kernel). Klassisches Confused-Deputy-Szenario: VM-BitLocker bindet PCRs an einen Host, der selbst keinen Trust-Anchor hat. Praktisch nicht akzeptabel für Compliance-Workloads (NIS2, KRITIS, ISO 27001-PA).
Aus	Aus	Ja ✓	Bootet, kein Boot-Trust. Hochflexibel (jeder beliebige Bootloader läuft), aber ohne Schutz gegen Boot-Manipulation auf beiden Ebenen. Lab-Setup, Embedded-Systeme oder Legacy-Hardware ohne UEFI. Für Produktivumgebungen mit aktuellen Compliance-Anforderungen ungeeignet.

Welche Kombination wofür?

• Host An / VM An — Pflichtkombination für Windows-11-Gäste, BitLocker-Workloads, Compliance-relevante Server (NIS2, KRITIS, ISO 27001-PA). Nach dem 2026er-Rollout doppelt prüfen: Host-Shim aktualisiert, VM auf ms-cert=2023w.
• Host An / VM Aus — vertretbar für Linux-Test-VMs ohne Shim-Support, Custom-Kernel-Builds oder Appliances mit eigener Boot-Logik. Bewusste Entscheidung, dokumentieren.
• Host Aus / VM An — vermeiden. Ist meist unbeabsichtigt entstanden, weil ein Host-BIOS-Update Secure Boot deaktiviert hat oder ein Cluster-Node nie korrekt provisioniert wurde. Im Inventar regelmäßig auf diese Anomalie prüfen.
• Host Aus / VM Aus — Lab, Edge-Hardware ohne UEFI, Air-Gap-Diagnose-Systeme. Nicht für Produktion mit modernen Workloads.

Status-Check beider Ebenen in einem Skript

# Auf dem Proxmox-Host laufen lassen — prüft Host UND alle Windows-VMs

# 1. Host-Status
if [ -d /sys/firmware/efi ] && mokutil --sb-state 2>/dev/null | grep -q "SecureBoot enabled"; then
    HOST_SB="AN"
else
    HOST_SB="AUS"
fi
echo "Host Secure Boot: $HOST_SB"

# 2. Pro VM die efidisk0-Konfiguration und ms-cert auswerten
printf "%-6s %-20s %-10s %-10s\n" "VMID" "NAME" "VM-SB" "MS-CERT"
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    cfg=$(qm config $vmid 2>/dev/null)
    name=$(echo "$cfg" | awk '/^name:/ {print $2}')
    if echo "$cfg" | grep -q "^bios: ovmf"; then
        if echo "$cfg" | grep -q "pre-enrolled-keys=1"; then
            vm_sb="AN"
        else
            vm_sb="AUS"
        fi
        ms=$(echo "$cfg" | grep -oP 'ms-cert=\K[^,]+')
        printf "%-6s %-20s %-10s %-10s\n" "$vmid" "$name" "$vm_sb" "${ms:-2011}"
    fi
done

Das Skript liefert in einer Tabelle pro VM, welche Boot-Variante aktiv ist und welche CA-Generation in den OVMF-Vars hinterlegt ist — die Grundlage für die nächste Migrations-Welle.

Status im Gast verifizieren

Nach dem VM-Neustart denselben PowerShell-Check wie für physische Geräte fahren — die drei True-Antworten sind das Zielbild. Bleibt KEK 2K CA 2023 auf False, prüfen Sie:

• Windows-Update-Pfad — der KEK-Eintrag wird durch das In-Guest-Microsoft-Update geschrieben, nicht durch qm enroll-efi-keys. Ohne aktive Telemetrie und Registry-Opt-In bleibt die KEK-Variable leer.
• Custom-Mode-Workaround — in seltenen Fällen kann der KEK-Eintrag über das OVMF-Setup-Menü beim VM-Boot manuell geladen werden (BIOS → Device Manager → Secure Boot Configuration → Custom Mode). Microsoft stellt die KEK-DER-Datei als Download bereit.
• VM-Snapshot-Rollback — bei Snapshot-Restore nach dem CA-Update kann ein Rollback die EFI-Vars wieder auf 2011-Stand zurückfallen. Snapshot-Strategie nach dem Update überprüfen.

BitLocker, vTPM und das Recovery-Risiko

BitLocker bindet seinen Volume Master Key an die Plattform-Konfigurations-Register (PCRs) des TPM. Welche PCRs aktiv sind, hängt von der Konfiguration ab — Standard für Server ist eine Bindung an PCR 0, 2, 4, 7 und 11. Davon ist PCR 7 der relevante: Er bindet die Secure-Boot-Konfiguration und den Status der DB.

Beim Tausch des Boot-Managers oder beim Hinzufügen neuer DB-Einträge ändert sich PCR 7. BitLocker erkennt das beim Boot, weicht auf den Recovery-Key aus und fordert ihn an. Was zu tun ist:

• Vor dem Rollout alle Recovery-Keys in AD oder Microsoft Entra archivieren und stichprobenartig auslesen.
• Pro Schritt die VM/das Gerät aktiv überwachen — nicht „über Nacht und schauen wir morgen".
• Nach dem Update per manage-bde -protectors -get C: prüfen, ob der TPM-Protector wieder gesund ist und kein dauerhafter Recovery-Modus aktiv bleibt.

Auf Server-VMs mit virtuellem TPM (vTPM) gilt die gleiche Logik. Hier ist zusätzlich kritisch, dass der Hyper-V-Host die Key-Storage-Drive (KSD) korrekt verwaltet — bei Cluster-Nodes der HGS (Host Guardian Service) verfügbar bleibt.

Troubleshooting — die wichtigsten Event-IDs

Microsoft logt den Update-Pfad in zwei Event-Logs: System (Source: Microsoft-Windows-Kernel-Boot) und Application (Source: SecureBoot-Update). Die fünf häufigsten IDs:

Event-ID	Bedeutung	Typische Ursache & Lösung
1795	Firmware-Übergabe fehlgeschlagen	VM-Template-Trick (Hyper-V) oder OEM-BIOS-Update fehlt. Status 0xC0000013 = Variable schreibgeschützt.
1796	UEFI-Variable konnte nicht gelesen werden	Firmware-Bug oder degradiertes NVRAM. CMOS-Reset oder OEM-Firmware-Update.
1798	Update bereits installiert / Skip	Kein Fehler — Information, dass dieser Schritt bereits abgeschlossen war.
1801	Update-Aufgabe konnte nicht gestartet werden	Geplante Aufgabe deaktiviert, Telemetrie zu niedrig oder Ressourcenmangel. schtasks /query prüfen.
1808	Update-Schritt erfolgreich angewandt	Erfolg — der Wert UEFICA2023Status wechselt entsprechend.

Status-Registry-Keys mitlesen

Während des Rollouts schreibt Windows den Fortschritt in die Registry. Die wichtigsten Werte:

# Status auslesen
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" |
    Select-Object UEFICA2023Status, UEFICA2023Error

# Fehler 0x80070643 = Update-Aufgabe noch nicht ausgeführt
# Fehler 0xC0000013 = NVRAM read-only / Firmware-Pfad fehlt

Wenn alle drei Statusprüfungen False bleiben

Klassische Ursachen, in absteigender Häufigkeit:

• Telemetrie-Stufe zu niedrig. Microsoft gated den automatischen Rollout an mindestens Required. Setting per GPO unter Datensammlung und Vorabversionen → Telemetrie zulassen.
• OEM-Firmware ohne 2023-Wurzeln. Lenovo/Dell/HPE-Update einspielen.
• Aufgabe deaktiviert. Get-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" prüfen, ggf. Enable-ScheduledTask.
• Kein WSUS-Genehmigungspfad. Bei lokal gepflegtem WSUS müssen die Servicing Stack Updates Q1/2024+ explizit freigegeben sein.
• Disk-Image-VMs ohne Pflege. Goldene Master-Images, die nie geboot wurden, bleiben naturgemäß auf altem Stand. Erst booten, patchen, neu sysprep.

Rückzug — kann man rollen?

Kurz: nein, nicht sauber. Die Microsoft-Logik fügt Einträge in DB und KEK hinzu, sie entfernt nichts. Damit ist auf einer „upgegradeten" Maschine die alte Vertrauenskette weiterhin funktionsfähig — Rollback in dem Sinne, dass die 2023er-Einträge wieder verschwinden, ist ohne harten Eingriff (UEFI-Reset auf Werkseinstellungen, PK-Replace) nicht vorgesehen und auch nicht empfehlenswert.

Sinnvolle „Rollback"-Strategie ist Pausierung des Rollouts: AvailableUpdates auf 0 setzen, damit weitere Schritte nicht ausgerollt werden, und den fehlerhaften Schritt isoliert nachfahren. Vollständiger Reset auf 2011-only ist nur durch UEFI-Werksreset möglich — und damit verbunden den Verlust eigener PK-/KEK-Custom-Konfigurationen.

Pragmatischer 14-Tage-Rollout-Plan

Wer mit einer mittelgroßen Server-Flotte (50-300 Hosts und VMs) 2026 sauber durchkommen will, läuft in der Praxis dieses Schema:

• Tag 1-2 — Inventar. PowerShell-Skript aus Sektion „PowerShell" cluster-/forestweit ausrollen, CSV erzeugen. Ergebnis: drei Spalten True/False pro Host.
• Tag 3 — Pilot-Auswahl. Drei Geräteklassen wählen: ein nicht-kritischer Server, eine Standard-Workstation, eine Hyper-V-Gen2-VM. Auf jedem manuell den Registry-Pfad fahren, dokumentieren.
• Tag 4-6 — OEM-Firmware-Sweep. Über RMM oder iLO/iDRAC/IMM den BIOS-Stand auf die 2023-fähigen Versionen heben. Reihenfolge: erst Server, dann Notebooks.
• Tag 7-10 — Pilot-Ring (10 % der Flotte). Über GPO/Intune-Policy MicrosoftUpdateManagedOptIn aktivieren, beobachten. Inventar-Skript täglich laufen lassen, Status-Verlauf grafisch tracken.
• Tag 11-13 — Broad-Rollout. Restliche 90 %, gestaffelt nach Cluster-Node. Hyper-V-VMs in Wartungsfenstern mit dem Template-Trick durchgehen.
• Tag 14 — Verifikation & Abschlussbericht. Letztes Inventar-Skript, Quote zählen. Geräte mit „nicht aktualisiert" begründen (kein BIOS verfügbar, EOL-Hardware) und in Risiko-Register aufnehmen.

Glossar — die wichtigsten Begriffe

Fazit — was Sie heute tun sollten

Der Wechsel ist kein Notfall, aber er ist auch nicht optional. Wer im April 2026 noch nicht angefangen hat, hat zwei Monate bis zum ersten harten Cut. Drei Schritte für die nächste Woche:

Die wichtigste Botschaft: Der Rollout ist opt-in-getrieben. Was heute auf „nicht aktualisiert" steht, wird morgen nicht magisch grün. Aktive Steuerung ist der Unterschied zwischen einer ruhigen Migration im Sommer und einem Notfall-Sprint im Oktober.

FAQ