Die SecureBoot-Zertifikate (KEK und DB) von Microsoft stammen aus dem Jahr 2011 und laufen im Jahr 2026 ab.
| Bisheriges Zertifikat | Neues Zertifikat |
|---|---|
| Microsoft Corporation KEK CA 2011 Ablauf: Juni 2026 Key Exchange Key Hiermit werden DB und DBX Updates signiert | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft Windows Production PCA 2011 Ablauf: Oktober 2026 Signature Database (DB) Hiermit wird der Windows Boot-Loader signiert | Windows UEFI CA 2023 |
| Microsoft UEFI CA 2011 Ablauf: Juni 2026 Signature Database (DB) Hiermit werden 3rd Party Bootloader signiert | Microsoft UEFI CA 2023 |
| Option-ROMs wurden bisher ebenfalls mit der Microsoft UEFI CA 2011 signiert | Microsoft Option ROM UEFI CA 2023 |
Nachfolgendes How-To erläutert in Kurzfassung, wie diese mittels PowerShell geprüft und mittels in Windows 11 enthaltener Update-Funktionalität gezielt appliziert werden können.
Prüfen der SecureBoot DB und KEK Zertifikate
Das PowerShell-Modul UEFIv2 von Mike Niehaus installieren und die Ausführung von RemoteSigned Scripts zulassen:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
Install-PackageProvider -Name NuGet -Force -Confirm:$False
Install-Module -Name UEFIv2 -Force -Confirm:$False
Alternativ auf Geräten ohne Internet-Zugang das UEFIv2 PowerShell-Modul unter „Manual Download“ das „raw nupgk File“ herunterladen, es handelt sich um eine Datei im ZIP-Format, diese extrahieren. Darin findet sich das zu ladende Modul das wie folgt importiert wird:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
Import-Module .\UEFIv2.psm1
Damit nun den aktuellen Zustand der SecureBoot-Zertifikate abfragen:
Get-UEFISecureBootCerts -Variable kek | Format-List -Property SignatureSubject
SignatureSubject : CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Get-UEFISecureBootCerts -Variable db | Format-List -Property SignatureSubject
SignatureSubject : CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Dieses typische Beispiel zeigt, dass am System lediglich ein SecureBoot DB-Zertifikat von Microsoft aus 2011 vorhanden ist, welches im Jahr 2026 abläuft.
Welche Updates sind in Windows 11 enthalten?
Die mittels Windows-Updates gepflegten SecureBootUpdates finden sich hier:
dir C:\Windows\system32\SecureBootUpdates
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 14.10.2025 20:25 10542 BucketConfidenceData.cab
-a---- 07.12.2019 10:09 3 dbupdate.bin
-a---- 05.05.2025 22:41 4832 dbupdate2024.bin
-a---- 13.10.2025 22:08 4829 DBUpdate3P2023.bin
-a---- 13.10.2025 22:08 4840 DBUpdateOROM2023.bin
-a---- 14.10.2025 20:25 24053 dbxupdate.bin
-a---- 05.05.2025 22:41 5052 DBXUpdate2024.bin
-a---- 13.10.2025 22:08 3509 DBXUpdateSVN.bin
-a---- 13.10.2025 22:08 716120 KEKUpdateCombined.bin
-a---- 05.05.2025 22:41 45 SbatLevel.txt
-a---- 14.10.2025 20:25 6544 SKUSiPolicy.P7b
Auswahl: Welche Updates möchten wir applizieren
Wir prüfen vor dem Update, ob ein Update nicht bereits angestoßen wurde (Ergebnis >0):
$RegSecureBoot = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Write-Host "AvailableUpdates hat derzeit den Wert: 0x$($RegSecureBoot.AvailableUpdates.ToString("X"))"
AvailableUpdates hat derzeit den Wert: 0x0
Nun konfigurieren wir, welche Updates konkret umgesetzt werden sollen gemäß dieser Dokumentation.
$RegValue = 0x0
$RegValue += 0x0040 # add the Windows UEFI CA 2023 certificate to the Secure Boot DB.
$RegValue += 0x0800 # apply the Microsoft Option ROM UEFI CA 2023 to the DB
$RegValue += 0x1000 # apply the Microsoft UEFI CA 2023 to the DB
$RegValue += 0x0004 # look for a Key Exchange Key signed by the device’s Platform Key (PK)
Write-Host "Setze AvailableUpdates auf: 0x$($RegValue.ToString("X"))"
Setze AvailableUpdates auf: 0x1844
Hinweis: 0x4000 nutze ich in diesem Fall nicht, würde bedeuten: only apply the Microsoft UEFI CA 2023 and Microsoft Option ROM CA 2023 if the DB already has the Microsoft Corporation UEFI CA 2011.
Starten des SecureBoot Zertifikats-Updates
Nun die Durchführung starten, zuvor allerdings den Start-Zeitstempel merken um danach alle seit diesem Zeitpunkt aufgetretenen TPM-WMI Events abzufragen:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value $RegValue
$StartTimeStamp = (Get-Date).AddSeconds(-1)
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Start-Sleep -Seconds 10
Get-WinEvent -FilterHashtable @{ProviderName='microsoft-windows-tpm-wmi'; StartTime=$StartTimeStamp } -ErrorAction SilentlyContinue | Format-Table -Wrap -AutoSize
ProviderName: Microsoft-Windows-TPM-WMI
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
20.10.2025 22:23:18 1795 Fehler Die Systemfirmware hat beim Versuch, eine Variable für den sicheren Start 4 zu aktualisieren, den Fehler Das Medium ist schreibgeschützt.
zurückgegeben. Diese Gerätesignaturinformationen sind hier enthalten.
DeviceAttributes: FirmwareManufacturer:Microsoft Corporation;FirmwareVersion:Hyper-V UEFI Release v4.1;OEMModelNumber:Virtual
Machine;OEMManufacturerName:Microsoft Corporation;OSArchitecture:amd64;
BucketId: 4e22d051e8c143d2875b9d16ef2241c7ec548985a21e5073126d3c1f9bf53bb2
BucketConfidenceLevel: .
Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2169931
20.10.2025 22:20:25 1045 Informationen Update der Datenbank für sicheres Starten zur Installation des Microsoft UEFI CA 2023-Zertifikats wurde erfolgreich angewendet
20.10.2025 22:19:58 1044 Informationen Update der Datenbank für sicheres Starten zur Installation des Microsoft Option ROM-UEFI CA 2023-Zertifikats wurde erfolgreich angewendet
20.10.2025 22:15:57 1036 Informationen Das Update für den sicheren Start von Db wurde erfolgreich angewendet
20.10.2025 22:15:57 1801 Fehler Die Zertifizierungsstelle/Schlüssel für den sicheren Start müssen aktualisiert werden. Diese Gerätesignaturinformationen sind hier enthalten.
DeviceAttributes: FirmwareManufacturer:Microsoft Corporation;FirmwareVersion:Hyper-V UEFI Release v4.1;OEMModelNumber:Virtual
Machine;OEMManufacturerName:Microsoft Corporation;OSArchitecture:amd64;
BucketId: 4e22d051e8c143d2875b9d16ef2241c7ec548985a21e5073126d3c1f9bf53bb2
BucketConfidenceLevel:
UpdateType: 0
HResult: Der Vorgang wurde erfolgreich beendet.
Der Scheduled-Task wird über den COM-Server {5014B7C8-934E-4262-9816-887FA745A6C4} ausgeführt, nennt sich „TPM Maintenance Task Handler“ und wird implementiert in %systemroot%\system32\TpmTasks.dll
Der Fehler betreffend „… Das Medium ist schreibgeschützt.“ bezieht sich in diesem Fall auf den KEK welcher sich auf dieser Hardware nicht tauschen ließ (entweder, weil seitens Firmware nicht vorgesehen oder weil kein mittels Platform-Key PK signierter neuer 2023er KEK im Windows-Update für diese Plattform hinterlegt wurde).
Prüfung nach der Update-Durchführung
Der KEK ist somit unverändert, kein neuer 2023er KEK (Key-Exchange-Key) hinzugekommen:
Get-UEFISecureBootCerts -Variable kek | Format-List -Property SignatureSubject
SignatureSubject : CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Die drei neuen 2023er SecureBoot-Zertifikate sind nun aber verfügbar:
Get-UEFISecureBootCerts -Variable db | Format-List -Property SignatureSubject
SignatureSubject : CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
SignatureSubject : CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
SignatureSubject : CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US
SignatureSubject : CN=Microsoft UEFI CA 2023, O=Microsoft Corporation, C=US
Das System zum Abschluss neu starten!
Nach dem Neustart: Eventuell zuvor deaktivierten BitLocker mit TPM wieder aktivieren!
Fehlgeschlagene Update-Jobs deaktivieren
Da das KEK Update fehlgeschlagen ist, bleibt der Zustand von AvailableUpdates im Zustand 0x4 = look for a Key Exchange Key signed by the device’s Platform Key (PK) zurück:
$RegSecureBoot = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Write-Host "AvailableUpdates hat derzeit den Wert: 0x$($RegSecureBoot.AvailableUpdates.ToString("X"))"
AvailableUpdates hat derzeit den Wert: 0x4
Der Taskplaner-Job läuft periodisch und versucht dieses Update erneut, so lange sich an den Rahmenbedingungen aber nichts ändert, wird dieses Update auch weiterhin nicht gelingen. Es empfiehlt sich daher dies zu beenden, indem wieder 0x0 konfiguriert wird:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x0
Prüfung ob ein OEM-signed KEK für das Gerät verfügbar ist
Zum Suchen, ob für den Platform-Key ein mit diesem signierter KEK verfügbar ist wie folgt vorgehen:
$PK_Sig=(Get-UEFISecureBootCerts -Variable pk).Signature
Write-Host "issued_to: $($PK_Sig.Subject) / issued_by: $($PK_Sig.Issuer)"
issued_to: CN=Ideapad Products / issued_by: CN=Trust - Lenovo Certificate
Write-Host "serial_number: HEX $($PK_Sig.SerialNumber) = Dezimal: $([System.Numerics.BigInteger]::Parse("0$($PK_Sig.SerialNumber)", 'HexNumber'))"
serial_number: HEX 994F8B12DB0C8DB2496ED70FFB2DD913 = Dezimal: 203784895555750606179079273201565292819
Die an Microsoft übermittelten OEM-signierten KEK-Zertifikats-Updates sind hier einsehbar (JSON): https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json => Mit diesen ermittelten Angaben im JSON-String auf GitHub suchen, im vorliegenden Beispiel wird man fündig:
"5f11eeccb10336e653088cba0abc62f2533271a6": {
"KEKUpdate": "Lenovo\\KEKUpdate_Lenovo_PK255.bin",
"Certificate": {
"serial_number": 203784895555750606179079273201565292819,
"issued_to": "CN=Ideapad Products",
"issued_by": "CN=Trust - Lenovo Certificate"
}
},
Weitere Informationen & Follow-Up
Wertvolle Grundlagen-Informationen:
- UEFI Fall 2023 Developers Conference & Plugfest: Evolving the Secure Boot Ecosystem (Slides)
- Microsoft: Windows Secure Boot Key Creation and Management Guidance
- Microsoft: Windows Secure Boot certificate expiration and CA updates
- Microsoft: Frequently asked questions about the Secure Boot update process
Nachfolgende Informationen sind erst nach Erstellung meines How-To’s erschienen, waren zum Zeitpunkt der Erstellung meines Blog-Posts daher noch nicht verfügbar. Ich verweise als Follow-Up nun darauf, da sich dort sehr hilfreiche Informationen finden:
- Offizieller techcommunity.microsoft.com Blogpost „Secure Boot Playbook“ vom 13.11.2025
- Nutzung von WinCsFlags.exe (ist ab Win11 Patchstand 2025/11 verfügbar)
- Nutzung von GroupPolicies (ist ab Win11 Patchstand 2025/11 verfügbar)
- Sehr umfangreiche Informationssammlung zu UEFI Secure Boot / BlackLotus & PKFail auf msxfaq.de
Top Anleitung. Hat wunderbar funktioniert.
Gunnar, Du bist einer der Besten
Schon der Betrag „Edge Policies for non-Domain-joined Devices“ war Top
Danke
Bezüglich dem KEK: Wie kann KEK 2K CA 2023 installiert werden? Braucht es ein Bios Update mit dem neuen Zertifikat?
Um den KEK ohne BIOS-Update zu ergänzen braucht man eine UEFI Implementierung die dies unterstützt, und einen neuen KEK 2023 der mit dem Platform-Key des UEFI (also des Herstellers, z.B. Lenovo/HP/Dell) signiert ist.
Microsoft sammelt wie man im secureboot_objects Github-Repo sehen kann hierzu viele viele Platform-Key-signierte KEK-Files von den Herstellern ein. Wie weit fortgeschritten das ist weiß ich nicht, unsere Geräte hier ließen sich damit bislang nicht aktualisieren.
bei den beiden ist die Beschreibung vertauscht, ich glaube sogar in der MS Docu:
RegValue += 0x0800 # apply the Microsoft UEFI CA 2023 to the DB
RegValue += 0x1000 # apply the Microsoft Option ROM CA 2023 to the DB
Danke für den Hinweis. Die Microsoft Dokumentation wurde mittlerweile aktualisiert und ich habe den Fehler auch oben im Blog-Post ausgebessert.
Wenige Tage nach der Zertifikatsaktualisierung ist Windows 11 Pro wegen einer angeblichen „Hardwareänderung“ nicht mehr aktiviert und lässt sich trotz vieler Stunden Forschung auch nicht mehr aktivieren. Jetzt soll ich eine neue Pro-Lizenz im Store kaufen …
Der hier kolportierte Zusammenhang ist bei Kenntnis wie die OEM-Lizenzierung technisch umgesetzt ist meiner Beurteilung nach nicht zutreffend.