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.
Hallo Zusammen, für größere Unternehmen mit Hypervisoren wie HyperV , VMware; und VMs die es schon länger gibt bzw. vor dem Update des Hypervisors (bei VMware aus meiner Sicht VMware ESXi 8.0 Update 2
(Build 22380479) sind erstmals die 2023 Certs vorhanden) . erstellt worden sind, kommen hier kein automatisches Update welches das PK Cert. tauscht vermutlich auch das KEK. Dies wird ein manueller Step werden pro VM und mit einer Downtime verbunden sein. Bei einer großer Anzahl von VMs wird dies ein dementsprechender Aufwand werden (zeitlich wie auch Wartungsfenster technisch). und erst dann können die DB und DBXs in Windows freigeben werden. Wie der manuell Step bei HyperV aussieht kann ich nicht sagen. Für VMs auf VmwareBasis wird das pro VM sicher 20 – 30 min benötigen. Sieht das hier jemand anders? LG Johannes
Wie es mit VMWare aussieht weiß ich ad-hoc nicht. Aber für HyperV hat Microsoft angekündigt mit dem kumulativen Update im März 2026 das Hyper-V Update zur Verfügung zu stellen, damit der Hyper-V Host bzw. die virtuelle UEFI-Firmware das DB und KEK Update unterstützt. Und andererseits dann auch die nötigen PK-signierten KEK-Updates für ein reguläres Update (wie hier im Blog skizziert) aus der VM heraus bereitzustellen, sodass die VMs auf gleiche Weise wie physische Maschinen aktualisiert werden können. Quelle: https://github.com/microsoft/secureboot_objects/issues/318#issuecomment-3775306299
VWMARE bringt hier laut Support keine Updates welches das PK und Kek bei bestehenden VMs virt.Efi tauscht. Um es nicht manuell über die Secure boot Options replacen zu müssen, sehen die ersten Test, wie folgt, vielversprechenden aus und können automatisiert werden. Downtime jedoch erforderlich. .
Bei HyperV VMs sind wir uns noch nicht sicher. Derzeit sehe ich noch keine weiteren Hinweise in weiteren Foren oder Microsoft PlayBooks bezgl. dem Windows Update.
LG
Johannes
Prerequisite ESXi version 8.0.2
Shutdown VM
rename .nvram
Boot VM
Set regkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot AvailableUpdates to 0x5944.
Run Scheduled Task „Secure-Boot-Update“ twice with reboots.
Check bootx64.efi
Check [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).bytes) -match ‚Windows UEFI CA 2023‘
Check [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match ‚Microsoft Corporation KEK 2K CA 2023‘
Check Registry Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing UEFICA2023Status => Updates
Tested on to Test-VMs look good at the Moment.
Was mache ich jetzt mit dem OEM-signed KEK der für mein Gerät zur verfügbar steht?
„serial_number“: „5341e015c43af8a84836b9a5ff691488“
KEKUpdate_ASUS_PK8.bin
Da das KEKUpdate_ASUS_PK8.bin bereits seit 8 Monaten im GitHub-Repo zur Verfügung steht sollte es jedenfalls bereits im Windows-Update-Mechanismus enthalten sein und ist somit wie beschrieben mittels des TaskPlaner-Jobs applizierbar.
Das ist der Fehler den ich bekomme.
ProviderName: Microsoft-Windows-TPM-WMI
TimeCreated Id LevelDisplayName Message
———– — —————- ——-
1/29/2026 6:44:58 AM 1801 Error Updated Secure Boot certificates are available on this device b…
1/28/2026 6:52:12 PM 1801 Error Updated Secure Boot certificates are available on this device b…
1/28/2026 6:32:13 PM 1795 Error The system firmware returned an error The parameter is incorrec…
1/28/2026 6:28:06 PM 1795 Error The system firmware returned an error The parameter is incorrec…
1/28/2026 6:26:35 PM 1795 Error The system firmware returned an error The parameter is incorrec…
1/28/2026 6:26:30 PM 1795 Error The system firmware returned an error The parameter is incorrec…
1/28/2026 6:26:14 PM 1795 Error The system firmware returned an error The parameter is incorrec…
1/28/2026 6:26:14 PM 1034 Information Secure Boot Dbx update applied successfully
Es ist zweckmäßig die vollständige Eventlog-Message abzurufen und zu lesen, diese sind in der Regel mehrzeilig (siehe mein Beispiel oben). Basierend auf den Fragmenten die hier gepostet wurden würde ich raten: Windows hat korrekt erkannt, dass es einen neuen KEK + DB für dieses Gerät hat und hat auch versucht diese ins NVRAM zu schreiben, das BIOS (UEFI Firmware) des Geräts hat hierbei aber einen Fehler gemeldet. Also next step: Prüfen was konkret aktualisiert wurde und was nicht. Und um das Problem zu beheben wird es ein Firmware-/BIOS-Update des Herstellers brauchen.
Hallo Gunnar, also das Mainboard ist von 2017, also kommt da leider kein BIOS Update mehr.
Ich habe das Zertifikat jetzt manuell über das BIOS eingepflegt und noch einmal alles nach deiner Anleitung neu konfiguriert und jetzt läuft es.
Checking for Administrator permission…
Running as administrator – continuing execution…
29 January 2026
Manufacturer: ASUS
Model: All Series
BIOS: American Megatrends Inc., 4101, 4101, ALASKA – 1072009
Windows version: 24H2 (Build 26100.7623)
Secure Boot status: Enabled
Current UEFI PK
√ ASUSTeK MotherBoard PK Certificate
Default UEFI PK
WARNING: Failed to query UEFI variable PKDefault
Current UEFI KEK
X Microsoft Corporation KEK CA 2011
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)
Default UEFI KEK
WARNING: Failed to query UEFI variable ‚KEKDefault‘ for cert ‚Microsoft Corporation KEK CA 2011‘
WARNING: Failed to query UEFI variable ‚KEKDefault‘ for cert ‚Microsoft Corporation KEK 2K CA 2023‘
WARNING: Failed to query UEFI variable ‚KEKDefault‘
Current UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
√ Microsoft Corporation UEFI CA 2011 (revoked: False)
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ ASUSTeK MotherBoard SW Key Certificate (revoked: False)
√ ASUSTeK Notebook SW Key Certificate (revoked: False)
√ Canonical Ltd. Master Certificate Authority (revoked: False)
Default UEFI DB
WARNING: Failed to query UEFI variable ‚dbDefault‘ for cert ‚Microsoft Windows Production PCA 2011‘
WARNING: Failed to query UEFI variable ‚dbDefault‘ for cert ‚Microsoft Corporation UEFI CA 2011‘
WARNING: Failed to query UEFI variable ‚dbDefault‘ for cert ‚Windows UEFI CA 2023‘
WARNING: Failed to query UEFI variable ‚dbDefault‘ for cert ‚Microsoft UEFI CA 2023‘
WARNING: Failed to query UEFI variable ‚dbDefault‘ for cert ‚Microsoft Option ROM UEFI CA 2023‘
WARNING: Failed to query UEFI variable ‚DBDefault‘
Current UEFI DBX
2025-10-14 (v1.6.0) : SUCCESS: 431 successes detected
Windows Bootmgr SVN : 7.0
Windows cdboot SVN : 3.0
Windows wdsmgfw SVN : 3.0
Press any key to continue . . .
Siehe hier: https://github.com/cjee21/Check-UEFISecureBootVariables