uefi.secureBoot.PK.resetOnce = "TRUE"
uefi.secureBoot.KEK.resetOnce = "TRUE"

Die *.nvram löschen entpricht einem BIOS Reset: Holzhammermethode.
Das ist bei einer lebenden (virtuellen) Maschine mit Vorsicht zu genießen.

Dokumentiert ist ein zielgerichteter Ansatz:
Setting a custom Secure Boot configuration on an existing Virtual Machine
https://knowledge.broadcom.com/external/article/377306/secure-boot-custom-certificates.html

Die Default PK und KEK Einträge sehen gut aus.
Die können in die vorhandene virtuelle Maschine übernommen werden.

Den Default PK und KEK Einträge einmalig zu den Current Tabellen kopieren:
VM herruntergetahren. Die *.vmx Datei im Texteditor editiert, hinzugefügt [CODE]uefi.secureBoot.PK.resetOnce = "TRUE"
uefi.secureBoot.KEK.resetOnce = "TRUE"[/CODE]

Nach dem Neustart sollte PK und KEK synchron angezeigt werden.
Z.B. PK[QUOTE]Current UEFI PK
√ Windows OEM Devices PK

Default UEFI PK
√ Windows OEM Devices PK[/QUOTE]

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x4 /f
$StartTimeStamp = (Get-Date).AddSeconds(-1)
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Start-Sleep -Seconds 9
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates
Get-WinEvent -FilterHashtable @{ProviderName='microsoft-windows-tpm-wmi'; StartTime=$StartTimeStamp } -ErrorAction SilentlyContinue | Format-Table -Wrap -AutoSize

Bild 30.07.2026, 15:52: Bei Current PK wird ein grüner Haken ohne Bezeichnung angezeigt, das ist seltsam.
Das kann ein korrupter Eintrag sein. Mit korruptem PK lässt sich kein KEK hinzufügen.

Als Versuch kann ein KEK Update angefragt werden und das Verhalten betrachtet werden.
[CODE]reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x4 /f
$StartTimeStamp = (Get-Date).AddSeconds(-1)
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Start-Sleep -Seconds 9
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates
Get-WinEvent -FilterHashtable @{ProviderName='microsoft-windows-tpm-wmi'; StartTime=$StartTimeStamp } -ErrorAction SilentlyContinue | Format-Table -Wrap -AutoSize[/CODE]



Eine VMware Maschine heruntergefahren, die entsprechende *.nvram Datei umbenannt und die Machine wieder gestartet.
Die wesentlichen Einträge kommen von der *.vmx Datei, die Maschine bootet.
CA2011 und CA2023 sind weiter vorhanden, evtl neu erstellt. Ich bin mit nicht sicher, ob die Current Einträge in der *.nvram Datei gespeichert werden.
Spanndend wird es auf einem Systtem mit:
Current PK wird ein grüner Haken ohne Bezeichnung
Deault PK wird ein grüner Haken mit Bezeichnung

Gut, das kann es sein. Hatte da eine neue VM zum Testen angelegt und Windows neu installiert. Verwende sonst nur VirtualBox. Daher hatte ich da nichts Fertiges bzw. was Älteres in VMware.

Aber ihm fehlt ja nur der KEK und SVN. Alles andere ist bei ihm in Current enthalten.

Hier waren die 2023 Key in den Default Tabelle.
Die bestehenden Current Tabelle einer bestehenden virtuellen Maschine wurden nicht aktualisiert.
Das enstpricht dem Verhalten eines BIOS Updates, bestehende Current Tabellen werden beibehalten.
Die Current Tabelle einer alten bestehenden virtuellen Maschine war hier manuell zu beschreiben, im UEFI den PK Key laden.

Evtl gibt es auch ein reset im UEFI, das die default in die current Tabelle übernimmt.
Das wird Versionsabhängig sein.
Als Hack mag auch die *.nvram Datei zu löschen sein, nicht geteset. Sicherungskopie....

Eine neue virtuelle Maschine wird die Default Tabelle in die Current Tabelle laden.

uefi.allowAuthBypass = "TRUE"

Ja, das hatte ich auch gelesen. Aber nach Installation der Workstation Pro 26H1 war das alles automatisch bereits im VMware UEFI integriert. Windows hat dann wohl nur noch DBX und SVN aktualisiert. Nur "Microsoft Option ROM UEFI CA 2023" geht wohl nicht. Manuell musste ich da in Sachen PK und KEK nichts machen. Auch alle weiteren CA 2023 Zertifikate sind in Default DB bereits enthalten.

Warum das bei ihm da nicht klappt, weiß auch nicht. Entweder hat die VM eine älter Hardwareversion oder aus irgendwelchen Gründen lädt die VM nicht das aktuelle EFI ROM. Da passt irgendwas mit der VM nicht.

Ach so. Und damit man die Zertifikate ggf. manuell wie in den Links oben beschrieben, aktualisieren will, dann muss man das in der Workstation zuerst für jede VM freischalten. Dazu in der .vmx der VM folgendes hinzufügen (müsste auch in der globalen Konfigurationsdatei gehen):

[code]uefi.allowAuthBypass = "TRUE"[/code]

Ansonsten gibt es da im UEFI-Setup keine Option, um die Zertifikate zu bearbeiten.

Aber muss man jetzt halt abwarten, wenn sich Airgun wieder meldet und was daraus geworden ist.

[quote=Airgun post_id=460758 time=1785336519 user_id=40949]VMware® Workstation Pro 26H1 / Windows 11 Pro Gerätesicherheit Sicherer Start ist aktiviert, das autom. Update Zertifikat nicht unterstützt.[/quote]
Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines
https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html

Füge den generischen PK Platform Key WindowsOEMDevicesPK.der hinzu:
Manual Update of the Secure Boot Platform Key in Virtual Machines
https://knowledge.broadcom.com/external/article/423919
https://github.com/microsoft/secureboot_objects/tree/main/PreSignedObjects/

[attachment=0]Screenshot 2026-07-30 174138.png[/attachment]

Das ist jetzt komisch. Bei mir pass das so weit.

Das "Microsoft Corporation KEK 2K CA 2023" ist vorhanden, nur das "Microsoft Option ROM UEFI CA 2023" mag der nicht installieren. Aber das wohl für die VM auch nicht so wichtig.

Aber warum bei Dir jetzt das KEK fehlt, verstehe ich da nicht. Da muss irgendwas nicht passen.

Es geht um die Hardwareversion der VM. Sollte die aktuelle sein. Wenn DU die VM direkt für Windows 11 angelegt hast, sollte das eigentlich passen.

Ich verstehe bloß jetzt nicht, warum das KEK da fehlt. Im VMware UEFI wird es angezeigt. Windows hatte ich da nicht installiert. Hatte nur das UEFI einer neu angelegten Win11 VM aufgerufen. Eventuell müsste ich da vielleicht doch mal Windows installieren und schauen, was das bei mir sagt.

Beil die VMWare Version inkl. KEK Check des PCs, falls es hilft?

Mh? Wieso fehlt da das KEK? Welche Hardwareversion hat die VM? Eventuell wird das falsche EFI ROM geladen.

Das ist jetzt aber auch eine Windows 11 VM mit TPM?

[attachment=0]VMWare Check UEFI KEK.jpg[/attachment]Vielen Dank für diesen Hinweis, hier das Resultat per ScreenShot:

Das scheint alles etwas falsch gedeutet zu sein, Das KEK 2023 ist im VMware UEFI enthalten:

[attachment=0]Screenshot 2026-07-29 192154.png[/attachment]

Daran sollte es nicht liegen. Am besten mal das Skript verwenden:

https://github.com/cjee21/Check-UEFISecureBootVariables

Download: https://github.com/cjee21/Check-UEFISecureBootVariables/archive/refs/heads/main.zip

Und hier dann mal die "Check UEFI PK, KEK, DB and DBX.cmd" mit Adminrechten ausführen. Mich wurde mal interessieren, was da genau bei Dir drinsteht.

Ist ja in Windows integriert. Dann kannst du nur abwarten. Ich wüsste jetzt nicht, wie man das KEK in VMWare integriert. 🤔

Vielen Dank, ja alles aktuell, beil. noch ein Screenshot von HyperV Win11, hier erfolgt dieser Fehler nicht, auch innerhalb Windows 11 Gerätesicherheit

Dieses Event 1803 in VMWare scheint das Problem zu sein.
VMware und auch die Tools sind aktuell bei dir?