Secure Boot-Zertifikate laufen ab — Was IT-Admins jetzt tun müssen
Die seit 2011 genutzten Microsoft-Zertifikate für Secure Boot erreichen ihr Ablaufdatum. Ohne rechtzeitige Aktualisierung verlieren eure Windows-Systeme schrittweise den Schutz gegen Bootkit-Malware.
Stellt euch vor, euer Türschloss verliert ab einem bestimmten Tag seine Wirksamkeit — nicht sofort, aber Schritt für Schritt. Genau das passiert mit dem Secure Boot-Mechanismus aller Windows-Systeme, die noch mit den 2011er Zertifikaten arbeiten. Ab Ende Juni 2026 laufen diese Zertifikate aus — und wer nicht rechtzeitig handelt, hinterlässt eine wachsende Angriffsfläche auf Kernel-Ebene.
In diesem Beitrag erkläre ich, was genau passiert, welche Systeme betroffen sind und vor allem: wie ihr das Problem systematisch löst — für Clients, Server und virtuelle Maschinen.
Was ist Secure Boot — und warum ist das so kritisch?
Secure Boot ist eine UEFI-Sicherheitsfunktion, die verhindert, dass beim Systemstart nicht signierte oder manipulierte Software geladen wird. Der Mechanismus prüft kryptografisch, ob der Bootloader und alle früh geladenen Treiber von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert sind — und das bevor Windows überhaupt startet.
Dieser vorgelagerte Schutz ist entscheidend, weil Bootkit-Malware sich unterhalb des Betriebssystems einnistet und von herkömmlicher Antivirus-Software praktisch nicht erkannt werden kann.
BlackLotus (CVE-2023-24932) war das erste UEFI-Bootkit, das Secure Boot auf vollständig gepatchten Windows 11-Systemen umgehen konnte. Es zeigt, warum eine funktionierende, aktuelle Zertifikatskette unverzichtbar ist — denn ohne sie können keine neuen Sicherheitsmitigation für den Boot-Pfad mehr eingespielt werden.
Diese drei Zertifikate laufen ab
Die gesamte Vertrauenskette von Secure Boot basiert auf drei Zertifikaten, die alle aus dem Jahr 2011 stammen:
| Zertifikat | Funktion | Ablauf |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | Autorisiert Updates der DB und DBX (Signatur-Datenbanken) | Juni 2026 |
| Microsoft UEFI CA 2011 | Signiert Drittanbieter-Bootloader, Option-ROMs, Firmware-Komponenten | Juni 2026 |
| Microsoft Windows Production PCA 2011 | Signiert den Windows-Bootloader selbst (gespeichert in der DB) | Oktober 2026 |
Was passiert, wenn ihr nicht handelt?
Ein Ablauf der Zertifikate bedeutet keinen sofortigen Boot-Fehler. Standard-Windows-Updates werden weiterhin installiert. Allerdings geraten betroffene Systeme in einen sogenannten “Degraded Security State” — der Schutz des Boot-Prozesses nimmt mit der Zeit immer weiter ab.
Konkret verlieren nicht aktualisierte Systeme nach dem Ablaufdatum folgende Fähigkeiten:
- Keine neuen Sicherheits-Updates für Windows Boot Manager mehr
- Keine Aktualisierungen der Secure Boot-Datenbanken (DB) und Sperrlisten (DBX)
- Keine Mitigation für neu entdeckte Schwachstellen im Boot-Pfad
- Mögliche Kompatibilitätsprobleme mit neuen Betriebssystemen, Firmware und Secure Boot-abhängiger Software
- Drittanbieter-Bootloader mit neuen Zertifikaten werden nicht mehr als vertrauenswürdig anerkannt
Die neuen 2023-Zertifikate — mehr als ein simpler Tausch
Microsoft hat die Gelegenheit genutzt, die Vertrauensarchitektur grundlegend zu verbessern. Die neuen Zertifikate sind nicht einfach 1:1-Ersatz — die Verantwortlichkeiten wurden klar getrennt:
Ersetzt den KEK. Autorisiert weiterhin DB- und DBX-Updates — jetzt mit stärkerer Kryptografie.
Signiert ausschließlich Windows-Boot-Komponenten — keine Drittanbieter-Software mehr im gleichen Trust-Scope.
Speziell für Drittanbieter-Option-ROMs und Add-in-Card-Firmware (z.B. Grafikkarten, Netzwerkkarten).
Systeme, die keine Option-ROMs von Drittanbietern benötigen, müssen diesen auch nicht mehr vertrauen — das verkleinert die Angriffsfläche erheblich.
Die Lösung: Schritt-für-Schritt-Vorgehen nach Systemtyp
Schritt 1 — Inventur: Welche Systeme sind betroffen?
Bevor ihr irgendetwas tut: Verschafft euch einen Überblick. Prüft zunächst, ob Secure Boot auf euren Systemen überhaupt aktiviert ist, und kontrolliert dann den Zertifikatsstatus über den Registry-Schlüssel UEFICA2023Status.
PowerShell-Inventur für einen einzelnen Rechner:
Confirm-SecureBootUEFI# Zertifikatsstatus prüfen (Ziel: “updated”)
$key = “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State”
(Get-ItemProperty -Path $key -ErrorAction SilentlyContinue).UEFICA2023Status
Mögliche Rückgabewerte: updated (fertig), pending (Update läuft), not started (noch nicht begonnen), oder der Schlüssel fehlt komplett.
Für eine domänenweite Inventur per PowerShell (alle Rechner abfragen):
$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
$results = foreach ($pc in $computers) {
$status = Invoke-Command -ComputerName $pc -ScriptBlock {
$key = “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State”
$sb = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue) -eq $true
$cert = (Get-ItemProperty -Path $key -ErrorAction SilentlyContinue).UEFICA2023Status
[PSCustomObject]@{ SecureBoot = $sb; CertStatus = $cert }
} -ErrorAction SilentlyContinue
[PSCustomObject]@{ Computer = $pc; SecureBoot = $status.SecureBoot; Status = $status.CertStatus }
}
$results | Sort-Object Status | Format-Table -AutoSize
# Export als CSV:
$results | Export-Csv -Path “SecureBootStatus.csv” -Encoding UTF8 -NoTypeInformation
Schritt 2a — Windows Clients (Windows 10/11)
Ihr müsst lediglich sicherstellen, dass der folgende Registry-Schlüssel gesetzt ist (aktiviert die automatische Verteilung):
$path = “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot”
$val = (Get-ItemProperty -Path $path -Name MicrosoftUpdateManagedOptIn -ErrorAction SilentlyContinue).MicrosoftUpdateManagedOptIn
if ($val -eq $null -or $val -eq 0) {
Set-ItemProperty -Path $path -Name MicrosoftUpdateManagedOptIn -Value 1 -Type DWord
Write-Host “Opt-in gesetzt.” -ForegroundColor Green
} else {
Write-Host “Opt-in bereits aktiv (Wert: $val)” -ForegroundColor Cyan
}
Schritt 2b — Windows Server ⚡ Manuelle Aktion erforderlich!
Im Gegensatz zu Windows-Clients werden Server-Systeme nicht über den kontrollierten Feature-Rollout (CFR) versorgt. IT-Admins müssen manuell aktiv werden. Ausnahme: Server-Hardware, die seit 2024/2025 neu zertifiziert wurde, enthält die 2023-Zertifikate bereits ab Werk.
Vorgehen für Windows Server 2022 / 2019:
- Inventur: Registry-Schlüssel
UEFICA2023Statusauf allen Servern prüfen (Skript aus Schritt 1 verwenden) - OEM-Firmware-Updates: Neueste Firmware vom Hersteller einspielen — dies ist Voraussetzung für den Zertifikatstausch auf physischen Servern
- Pilotgruppe: Mit einer kleinen Gruppe weniger kritischer Server beginnen und den Prozess validieren
- Zertifikate einspielen: Über die im Microsoft Server Playbook beschriebene Methode (SCCM, Intune, lokales PowerShell-Skript oder WSUS-Gruppenrichtlinie)
- Ergebnis prüfen:
UEFICA2023Statussollte nach einem Neustart den Wert updated zeigen
Event ID 1795 — Fehlerbehandlung:
Get-WinEvent -LogName System -MaxEvents 500 |
Where-Object { $_.Id -eq 1795 } |
Select-Object TimeCreated, Message
Event ID 1795 bedeutet: Windows konnte die Zertifikate nicht an die Firmware übergeben. Ursache ist meist fehlendes Firmware-Update vom OEM.
Schritt 2c — Hyper-V VMs
Für Generation-2-Hyper-V-VMs galt bis März 2026 ein bekanntes Problem (Event ID 1795: “Media is write protected”). Microsoft hat hierfür ein Fix via Windows Update im März 2026 veröffentlicht. Prüft also zuerst, ob die aktuellen Patches installiert sind, bevor ihr das Zertifikats-Update startet.
Schritt 3 — Status im Windows Security Center überwachen
Ab April 2026 zeigt die Windows Security App unter Gerätesicherheit → Secure Boot den aktuellen Zertifikatsstatus mit farbigen Badges:
Admin-Checkliste: Was jetzt sofort zu tun ist
UEFICA2023Status prüfenMicrosoftUpdateManagedOptIn auf Clients prüfen/setzenDie Zeitlinie auf einen Blick
| Datum | Ereignis |
|---|---|
| Jetzt (April 2026) | Windows Security App zeigt Zertifikatsstatus. Rollout läuft bereits für viele Clients. |
| 27. Juni 2026 | Erstes Ablaufdatum: Microsoft Corporation KEK CA 2011 und Microsoft UEFI CA 2011 laufen ab. |
| Oktober 2026 | Microsoft Windows Production PCA 2011 läuft ab (Bootloader-Signatur). |
Fazit: Jetzt handeln, nicht im Juni in Panik geraten
Die Deadline ist weniger als drei Monate entfernt. Die gute Nachricht: Die Lösung ist klar definiert und die Werkzeuge sind vorhanden. Wer jetzt mit der Inventur beginnt, OEM-Updates einspielt und den manuellen Server-Prozess anstößt, hat alle Zeit der Welt für einen sauberen, getesteten Rollout. Wer wartet, riskiert einen hektischen Juni — und eine Umgebung, die zunehmend ungeschützt gegen Boot-Level-Angriffe ist.
© 2026 IT-Service Walter — isw-adtools.de
Windows-Administration & IT-Sicherheit für Profis | Euskirchen