Home / Writing / Windows

VMware Secure Boot CA 2023 Readiness and the VMW.NULLPK Question

2026.10.29 · Windows
VMware Secure Boot CA 2023 Readiness and the VMW.NULLPK Question

A Windows virtual machine on VMware vSphere logs Event 1803 or Event 1795 from Microsoft-Windows-TPM-WMI while trying to apply the 2023 Secure Boot certificates. Reading the UEFI Platform Key with Get-SecureBootUEFI -Name PK returns a 28-byte EFI_SIGNATURE_LIST header plus a 16-byte SignatureOwner GUID (44 bytes total) followed by a zero byte: VMW.NULLPK. On the next VM in the same cluster, PK is also VMW.NULLPK, yet that machine does not need a Platform Key update at all.

Both observations are accurate. On vSphere, VMW.NULLPK is evidence of how the virtual firmware initialized its Platform Key. It is not, by itself, proof that the guest is missing the 2023 Key Exchange Key or that a hypervisor-level PK replacement is required before Windows can finish the 2023 Boot Manager transition.

I added Detect_VMwareSecureBootUEFICA2023.ps1 and updated the companion inventory and segmentation scripts in endpoint-toolkit to separate those cases cleanly using the rules documented in Broadcom KB 423893 and Microsoft KB 5085046.

Why PK, KEK and DB fail in different places

Windows Secure Boot servicing is driven by the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task and the AvailableUpdates bitmask under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. When armed with 0x5944, the task processes five actions in a fixed order and clears each bit as it succeeds, leaving the 0x4000 modifier bit at completion:

  1. 0x0040 — add Windows UEFI CA 2023 to db (Event 1036).
  2. 0x0800 — add Microsoft Option ROM UEFI CA 2023 to db if Microsoft Corporation UEFI CA 2011 is present (Event 1044).
  3. 0x1000 — add Microsoft UEFI CA 2023 to db if Microsoft Corporation UEFI CA 2011 is present (Event 1045).
  4. 0x0004 — add Microsoft Corporation KEK 2K CA 2023 to KEK (Event 1043).
  5. 0x0100 — install the Windows UEFI CA 2023–signed boot manager on the EFI System Partition (Event 1799, followed by Event 1808 when servicing is complete).

Microsoft's troubleshooting guide (KB 5085046) notes one important exception to strict step-by-step blocking: if step 4 (0x0004) cannot be processed because a PK-signed KEK is missing, the scheduled task still proceeds to step 5 (0x0100) and applies the 2023-signed Windows Boot Manager. On an affected VMware VM, you will commonly see the 2023 DB certificates and the 2023 Boot Manager already applied while AvailableUpdates remains stuck at 0x4004 waiting on the KEK bit.

The trust delegation boundary explains why steps 1 through 3 behave differently from step 4:

  • DB updates are authorized by KEK, not by PK. The Windows update payloads that append the 2023 certificates to db are signed by the existing Microsoft Corporation KEK CA 2011. As long as the 2011 KEK is present in virtual NVRAM, Windows can update db even on a VM whose Platform Key is VMW.NULLPK.
  • KEK updates are authorized by PK. To append Microsoft Corporation KEK 2K CA 2023 at step 4 from inside the guest OS, Windows needs a KEK update payload signed by the platform's PK — on vSphere, Windows OEM Devices PK. When PK is VMW.NULLPK and KEK 2023 is absent from NVRAM, step 4 cannot be authorized from the guest OS and logs Event 1803 (missing PK-signed KEK) or Event 1795 (firmware rejected the variable write).
  • If KEK 2023 is already in NVRAM, step 4 has nothing to prove. When the virtual NVRAM already contains Microsoft Corporation KEK 2K CA 2023, the VM does not need an OS-driven KEK update, which means it does not need a Platform Key replacement to complete the 2023 transition.

Three VMware NVRAM cohorts that look alike from the outside

In vSphere, a VM's Secure Boot databases are initialized in its .nvram file when the VM is first powered on (or inherited verbatim from a VM template or an OVF/OVA that includes an NVRAM file). Per Broadcom KB 423893, the initial certificate set depends on the ESXi release and VM Hardware Version at creation time:

Default vUEFI Secure Boot certificates at VM creation (Broadcom KB 423893)
ESX version & VM HW at creation Initial PK Initial KEK Initial DB (Microsoft certificates)
Earlier than ESXi 8.0 U2 (with HW v14+), or any ESX with HW v13 VMW.NULLPK KEK CA 2011 only Production PCA 2011, UEFI CA 2011
ESXi 8.0 U2 through 8.0 U3i (P08) with HW v14+ VMW.NULLPK KEK 2K CA 2023 + KEK CA 2011 Windows UEFI CA 2023, Microsoft UEFI CA 2023, Production PCA 2011, UEFI CA 2011
ESXi 8.0 U3j (P09)+ or ESX 9.x with HW v14+ Windows OEM Devices PK KEK 2K CA 2023 + KEK CA 2011 Windows UEFI CA 2023, Microsoft UEFI CA 2023, Production PCA 2011, UEFI CA 2011

Look closely at the middle row. Every VM created from scratch on ESXi 8.0 U2 through 8.0 U3i (P08) with VM Hardware Version 14 or newer carries VMW.NULLPK, and already carries Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023 and Microsoft UEFI CA 2023 in NVRAM.

There is one subtle omission in that initial NVRAM table: Broadcom notes that vSphere does not pre-populate Microsoft Option ROM UEFI CA 2023 in db at VM creation, while it does pre-populate Microsoft Corporation UEFI CA 2011. Under Microsoft's 0x4000 modifier rule, the presence of Microsoft Corporation UEFI CA 2011 makes both Microsoft UEFI CA 2023 (0x1000) and Microsoft Option ROM UEFI CA 2023 (0x0800) applicable during Windows servicing.

That omission creates an easy detection bug. If a script only routes VMW.NULLPK guests to standard OS servicing when all applicable 2023 DB certificates are already present in NVRAM, every unserviced ESXi 8.0 U2–U3i (P08) VM fails that check because Microsoft Option ROM UEFI CA 2023 has not been added by Windows yet. The right question is simpler: is KEK 2023 already in NVRAM? If it is, Windows can add any missing 2023 DB certificates (using KEK) and install the 2023 boot manager without touching the Platform Key.

How Broadcom updates VMW.NULLPK when KEK 2023 is missing

When a Secure Boot–enabled VM is genuinely in the first cohort (KEK 2023 is absent from NVRAM and PK is VMW.NULLPK), the Platform Key has to be replaced with Windows OEM Devices PK before Windows can complete step 4 (0x0004). Broadcom's supported path depends on whether a virtual TPM (vTPM) is attached to the VM, and requires VM Hardware Version 14 or newer:

  • vTPM disabled — SilentPK update: On ESXi 8.0 U3j (P09)+ and ESX 9.1.1.0+, vSphere silently enrolls Windows OEM Devices PK during a guest reboot or VM power cycle. Because no vTPM is present, updating the PK from the hypervisor cannot invalidate TPM PCR measurements.
  • vTPM enabled — Capsule PK update: On a vTPM-enabled Windows VM, changing Secure Boot variables from outside the guest OS alters PCR 7 measurements without Windows' coordination and risks BitLocker recovery. Broadcom's automated solution for vTPM-enabled Windows guests uses a standard Windows firmware capsule update delivered through VMware Tools. In Device Manager, this appears under Firmware as Platform Key Firmware.

Broadcom KB 423893 sets several concrete prerequisites for the Capsule PK path that are worth checking before scheduling reboots:

  1. vCenter, host release and cold power-on: Broadcom's documented infrastructure sequence upgrades both vCenter Server and ESX hosts in the cluster to 9.1.1.0+ (automated PK remediation for vTPM-enabled VMs on vSphere 8.x is still listed by Broadcom for a future 8.x patch release). After the host upgrade, the VM must go through a full power-on on the patched host and be on VM Hardware Version 14 or higher.
  2. Windows cumulative update and VMware Tools 13.1.5+ sequence: Requires the July 2026 or later Windows cumulative update and VMware Tools 13.1.5+. On Windows Server 2019, Windows Server 2022, Windows 11 23H2 and Windows 10 21H2, the July 2026+ cumulative update must be installed before upgrading VMware Tools to 13.1.5 so the capsule PK driver is installed. Only Windows Server 2025 and Windows 11 24H2/25H2 allow installing the cumulative update after upgrading to Tools 13.1.5.
  3. Deferred Windows SKUs in VMware Tools 13.1.5: Broadcom notes that the Capsule PK driver is not included in VMware Tools 13.1.5 for Windows Server 2016, Windows 10 22H2 or Windows 10 1809; support for those three is deferred to a future VMware Tools release.
  4. Manual VMX / vUEFI fallbacks: Broadcom documents uefi.secureBoot.PK.resetOnce = "TRUE" (on ESXi 8.0 U3j+ / ESX 9.0+) and manual vUEFI enrollment, but explicitly notes that the VMX method on vTPM-enabled VMs is recommended only for Linux guests. If a manual PK update is used on a vTPM-enabled Windows VM, suspend BitLocker and back up recovery keys before powering off the VM.

What Detect_VMwareSecureBootUEFICA2023 checks

Detect_VMwareSecureBootUEFICA2023.ps1 is a standalone, strictly read-only Intune Remediations detection script. It never writes registry values, never modifies UEFI variables, never triggers the Secure-Boot-Update task and never touches BitLocker protectors. Its only writes are CMTrace log entries under %ProgramData%\Microsoft\IntuneManagementExtension\Logs\PR_VMwareSecureBootCA2023.log.

Several failure modes showed up during review and testing that a naive script gets wrong:

  • Unknown states must fail closed. If Win32_ComputerSystem fails, if Secure Boot state cannot be determined, if Get-SecureBootUEFI cannot read PK, KEK or db on a Secure Boot–enabled VM, or if the Microsoft-Windows-TPM-WMI event log query fails, the script exits 1 with NON-COMPLIANT-COLLECTION-ERROR. It never turns a failed WMI or firmware read into NOT-APPLICABLE (Exit 0), NullPK or absent vTPM.
  • Live NVRAM overrides stale registry and old Event 1808 entries. If a VM was previously updated (UEFICA2023Status = Updated, AvailableUpdates = 0x4000, Event 1808 in the System log) and its .nvram was later reset or restored from an older snapshot, relying on registry and event log state alone reports a false COMPLIANT. Conversely, on successfully serviced systems (observed on Windows 11 24H2/25H2) where no servicing error occurred, UEFICA2023Error may be absent from the Servicing key; an absent UEFICA2023Error alongside UEFICA2023Status = Updated is normalized to 0 rather than treated as a missing-data failure.
  • Event chronology matters in both directions. A historical Event 1803 from before a SilentPK or Capsule PK update must not permanently block a VM that now has Windows OEM Devices PK in NVRAM. A historical Event 1800 from before the last OS boot must not report a permanent reboot requirement, while a current-boot Event 1800 (or a blocking error logged after an older Event 1808/1799) must prevent COMPLIANT. Because frequent Event 1801 assessment entries can fill a 100-event window, the script queries completion and pending-restart events (1808, 1799 and 1800 in System, plus 1799 in the optional Microsoft-Windows-TPM-WMI/Operational channel) and blocking events independently.
  • Not every non-zero PnP code on the Capsule device means "reboot". When the Platform Key Firmware PnP device is present in Device Manager, ConfigManagerErrorCode = 14 (CM_PROB_NEED_RESTART) indicates a staged capsule update waiting on a guest restart. Other non-zero codes (such as 10, 28 or 31) indicate a driver or device failure and are reported separately as NON-COMPLIANT-VMWARE-CAPSULE-ERROR.
Detect_VMwareSecureBootUEFICA2023 verdict markers and exit codes
Marker Exit Condition
COMPLIANT 0 Live NVRAM has KEK 2023 + required 2023 DB certs, Status=Updated, Err=0, Avl=0x4000, Capsule PnP is clean, and Event 1808/1799 is verified with no newer blocker or current-boot pending restart.
NOT-APPLICABLE 0 Confirmed non-VMware platform, or a VMware VM where Secure Boot is confirmed disabled or unsupported (Legacy BIOS).
PREREQ 1 Script was started in 32-bit PowerShell instead of 64-bit PowerShell.
NON-COMPLIANT-COLLECTION-ERROR 1 CIM platform query, Secure Boot state, UEFI variable read (PK/KEK/db), PnP query or TPM-WMI event query failed.
NON-COMPLIANT-VMWARE-CAPSULE-REBOOT 1 VMware Platform Key Firmware PnP device has ConfigManagerErrorCode = 14; guest restart required to complete the Capsule PK update.
NON-COMPLIANT-VMWARE-CAPSULE-ERROR 1 VMware Platform Key Firmware PnP device has a non-zero error code other than 14; inspect Device Manager rather than rebooting.
NON-COMPLIANT-PENDING-REBOOT 1 KEK 2023 is in NVRAM and AvailableUpdates = 0x4100 (or a current-boot Event 1800 is active); guest restart required before Secure Boot servicing can continue.
NON-COMPLIANT-OS-SERVICING-NEEDED 1 KEK 2023 is already in NVRAM (PK replacement not required even with VMW.NULLPK), but one or more required 2023 DB certs (such as Microsoft Option ROM UEFI CA 2023) or OS Boot Manager servicing is still incomplete.
NON-COMPLIANT-VMWARE-PK-BLOCKED 1 KEK 2023 is missing from NVRAM and PK is NullPK or None; blocked on Broadcom hypervisor PK remediation (SilentPK when vTPM=False, Capsule PK when vTPM=True).
NON-COMPLIANT-PK-READY-NEEDS-KEK 1 KEK 2023 is missing from NVRAM, but Windows OEM Devices PK (WinOemPK) is present; ready for standard Windows servicing (AvailableUpdates = 0x5944).
NON-COMPLIANT-VMWARE-PK-UNRECOGNIZED 1 KEK 2023 is missing from NVRAM and PK contains a custom or unrecognized non-null payload instead of Windows OEM Devices PK.

Run locally or through Intune Remediations

In Intune Remediations, deploy Detect_VMwareSecureBootUEFICA2023.ps1 as a detection-only package (leave the remediation script slot empty) with:

  • Run this script using the logged-on credentials: No (runs as SYSTEM in Intune; Get-SecureBootUEFI requires elevated Administrator or SYSTEM privileges)
  • Enforce script signature check: No (or sign according to your organization's policy)
  • Run script in 64-bit PowerShell: Yes

Each run prints a single line under Intune's 2048-character limit with a human-readable reason on the left of | and space-delimited, whitespace-free key=value telemetry tokens on the right:

The following sample output uses illustrative device names and model values.

.\Detect_VMwareSecureBootUEFICA2023.ps1

# Physical device in a mixed-fleet assignment (Exit 0):
NOT-APPLICABLE: Device is not a VMware virtual machine (Manufacturer=LENOVO, Model=EXAMPLE-MODEL) | Host=EXAMPLE-CLIENT Plat=LENOVO SB=Enabled vTPM=N/A Status=Updated Err=0 Avl=0x4000 Capable=2 Conf=High_Confidence PK=N/A KEK23=N/A DbWin23=N/A DbOptRom23=N/A Db3P23=N/A DbAll23=N/A Trust=N/A VMTools=N/A CapOS=N/A CapPnP=N/A LastEvt=1808 Task=Ready OSBuild=26200

# ESXi 8.0 U2-U3i (P08) VM with VMW.NULLPK and pre-populated KEK 2023 (Exit 1):
NON-COMPLIANT-OS-SERVICING-NEEDED: KEK 2023 is in NVRAM (PK update not required; missing DB cert(s): MSOptionRomUEFICA2023); complete Windows Secure-Boot-Update servicing (Status=NotStarted, Avl=None) | Host=EXAMPLE-VM-01 Plat=VMware SB=Enabled vTPM=True Status=NotStarted Err=0 Avl=None PK=NullPK KEK23=True DbWin23=True DbOptRom23=False Db3P23=True DbAll23=False Trust=MSAnd3P VMTools=12.4.0 CapOS=SupportedIn1315 CapPnP=Absent LastEvt=None Task=Ready OSBuild=20348

# Pre-8.0 U2 VM with VMW.NULLPK, vTPM=True, missing KEK 2023 (Exit 1):
NON-COMPLIANT-VMWARE-PK-BLOCKED: Missing KEK 2023 blocked by PK=NullPK (Broadcom KB 423893: vTPM=True, VMTools=13.1.5 (>=13.1.5): requires ESX 9.1.1.0+, VM HW v14+ (cold power-on), and July 2026+ CU for Capsule PK update (Supported in VMTools 13.1.5 (install July 2026+ CU prior to upgrading to Tools 13.1.5))) | Host=EXAMPLE-VM-02 Plat=VMware SB=Enabled vTPM=True Status=InProgress Err=0x80070002 Avl=0x4004 PK=NullPK KEK23=False DbWin23=True DbOptRom23=True Db3P23=True DbAll23=True Trust=MSAnd3P VMTools=13.1.5 CapOS=SupportedIn1315 CapPnP=Absent LastEvt=1803 Task=Ready OSBuild=20348

Segmenting the fleet export

The general fleet inventory script (Get-SecureBootCertInventory.ps1) now also captures pkSt, vtpm, vmt (VMware Tools version), pkCap (Capsule PnP error code), compOk and rebootPend. Its offline companion (Split-SecureBootPopulation.ps1) accepts either the JSON inventory export or the summary lines from Detect_VMwareSecureBootUEFICA2023.ps1, and splits VMware guests by the actual work required instead of placing every non-updated VM into a single VirtualVMware bucket:

.\Split-SecureBootPopulation.ps1 `
  -Path .\DeviceStatus.csv `
  -OutputCsv .\segmented-fleet.csv
  • VMwareCapsuleReboot — Capsule PK staged in Device Manager (ConfigManagerErrorCode = 14); schedule a guest restart.
  • VMwareCapsuleError — Capsule PnP device present with a non-14 error code; investigate the driver or device state before rebooting.
  • VMwareOsServicing — KEK 2023 is already in NVRAM (including ESXi 8.0 U2–U3i P08 VMs with NullPK); assign standard OS-side Secure Boot servicing.
  • VMwarePkReadyNeedsKek — KEK 2023 is missing, but Windows OEM Devices PK is already enrolled in NVRAM; assign standard OS-side Secure Boot servicing.
  • VMwarePkBlockedVtpm — missing KEK 2023 with NullPK and vTPM = True; route to the Broadcom Capsule PK workflow (or manual PK update with BitLocker suspended).
  • VMwarePkBlockedNoVtpm — missing KEK 2023 with NullPK and vTPM = False; route to the Broadcom SilentPK host patch and guest restart workflow.

Keep guest evidence within its boundaries

A guest OS script can observe what is in its own virtual NVRAM, registry, Device Manager tree and event logs. It cannot see vCenter, the ESXi host build, the VM Hardware Version (13 vs. 14+) or whether the VM has completed a cold power-on since the host was patched. Treat the guest detection output as the guest half of the evidence and pair it with vCenter inventory (or Broadcom's Virtual Machine UEFI Secure Boot Platform Key is out of date alarm, which requires patching both vCenter and ESX to 9.1.1.0+) before triggering hypervisor changes.

Be equally conservative with BitLocker. Even when certificate updates run through supported OS or capsule mechanisms, non-standard boot orders — such as PXE network boot ahead of the on-disk Windows Boot Manager, documented in KB 5085046 — or legacy BitLocker PCR bindings (0,2,4,11 instead of PCR 7) can still trigger recovery prompts across a servicing reboot. Screen for legacy PCR bindings first with BitLockerPcrDetection-Ivanti.ps1, and pilot the detection and servicing workflow on representative VMware guests before broad deployment.

The scripts and documentation are in the SecureBootRemediation directory of endpoint-toolkit. For the underlying vendor and OS guidance, see Broadcom KB 423893, Microsoft KB 5085046, Microsoft KB 5080921 and Microsoft KB 5016061.

← Back to Writing