Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines
search cancel

Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

book

Article ID: 423893

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Virtual machines (VMs) are experiencing Secure Boot certificate update failures or warnings. These failures occur because Microsoft Secure Boot certificates reach their expiration, as outlined in MS KB 5062713.

Symptoms include:

  • Windows Event Viewer Logs:
    • Event ID 1801: "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware."
    • Event ID 1769: "The Secure Boot updated failed to update KEK 2023 with error invalid access to memory location."

  • Certificate Installation Failures:
    • Microsoft Secure Boot automated updates fail to install new 2023 certificates.
    • Failure to install updated DB, DBX, or Option ROM certificates.

  • Missing Certificate Entries: Missing Microsoft Corporation KEK 2K CA 2023 in the virtual machine Secure Boot KEK database.
  • Secure Boot updates succeed on some VMs but fail on others with different ESXi or virtual hardware versions.
  • Secure Boot continues to function, but future DB/DBX revocation updates cannot be applied.

  • vCenter Alarms:
    • After both VC and ESX update to 9.1.1.0, vCenter shows the alarm "Virtual Machine UEFI Secure Boot Platform Key is out of date. Refer KB 423893" at VM level and aggregated alarm at Cluster level. This alarm indicates that the virtual machine's UEFI Secure Boot Platform Key (PK) is out of date and needs to be updated.

Important Note:

  • The virtual machines will continue to boot even after certificate expiry.
  • An expired KEK certificate impacts the ability to update some of the Secure Boot databases rather than immediate boot functionality.

Environment

  • ESXi: 7.x, 8.x, 9.x
  • VCF: 4.x, 5.x, 9.x
  • TCP: 3.x, 4.x, 5.x
  • TCI: 2.x, 3.x

Cause

This issue affects Secure Boot-enabled VMs meeting the following conditions:

  1. Key Exchange Key (KEK) is expired or missing latest Microsoft KEK certificates

    In this case, the platform cannot authorize Secure Boot updates, including DB updates and DBX revocations, and Windows may log Event ID 1801 during attempted Secure Boot remediation.

  2. Invalid Platform Key (PK)

    On virtual machines created on ESXi versions earlier than 9.0, the PK is configured with a NULL signature by default due to previous design considerations. In this case, the platform cannot authorize updates to the KEK, which in turn prevents subsequent DB and DBX updates.

Resolution

  1. Table of Contents

    Remediation Recommendations

    Impacted VMs:

    VMs meeting both conditions need remediation. Other VMs should not be affected.

    1. Outdated Certificates (NULL PK, 2011-only KEK, 2011-only DB): Secure Boot-enabled VMs that either are Hardware Version 13, or created on ESX hosts earlier than 8.0 U2, or deployed from templates inheriting the NVRAM from an affected VM.
    2. Supported OS: Running an OS that expects to receive OS updates.

    Remediation Recommendations:

    1. PK: Apply automated solutions as they become available (even if they are released a few months following the 2011 KEK expiration in June 2026, given the non-trivial manual update effort). Only apply manual updates on impacted VMs if automation will never be available for these VMs.
    2. KEK: Apply the 2023 KEK certificate on impacted VMs using OS vendor tools once the Windows OEM Devices PK is in place.
    3. DB: Apply the 2023 DB certificates today on impacted VMs using OS vendor tools (no PK prerequisite).

    Consequences of Inaction on Impacted VMs:

    1. Lacking the Windows OEM Devices PK: Cannot remediate the KEK.
    2. Lacking the 2023 KEK certificate: Cannot apply future DBX updates via built-in OS tools. While rare, it is unpredictable when a new boot vulnerability will be discovered which would prompt a DBX update.
    3. Lacking the 2023 DB certificates:
      1. Windows: Cannot update to a 2023-signed Windows Boot Manager.
      2. Linux: Failure to apply updates to the first-stage bootloader (e.g., a new shim released after June 2026). Depending on the Linux distribution, this failure could occur during the OS update package installation phase or upon the subsequent reboot.

    Platform Key Remediation Tool Availability

    vSphere Major VersionvTPM StatusGuest OSRelease that contains the automated PK remediation solution
    8.xDisabled
    • Windows
    • Linux
    		ESX 8.0 U3j (P09)
    Enabled
    • Windows Server 2025, 2022, 2019, 2016
    • Windows 11 25H2, 24H2, 23H2
    • Windows 10 64-bit 22H2, 21H2, 1809
    		Future release
    • Legacy Windows (outside the supported Windows versions listed above)
    • Linux
    • There will not be an automated PK update solution for these VMs.
    • VMware ESX 8.0 U3j (P09) contains the recommended manual PK update method.
    9.xDisabled
    • Windows
    • Linux
    		ESX 9.1.1.0
    Enabled
    • Windows Server 2025, 2022, 2019, 2016
    • Windows 11 25H2, 24H2, 23H2
    • Windows 10 64-bit 22H2, 21H2, 1809

    ESX 9.1.1.0; and

    The Capsule PK update driver triggering the PK update is available starting in VMware Tools 13.1.5 for supported Windows versions, except Windows Server 2016, Windows 10 64-bit 22H2, and 1809, which will be supported in a future VMware Tools release. For the Capsule PK update, the July 2026 Windows Cumulative Update or later is required.  You must install this cumulative update before installing or upgrading VMware Tools to version 13.1.5 to allow the installation of the PK update driver, except for Windows Server 2025, Windows 11 25H2, and 24H2.

    • Legacy Windows (outside the supported Windows versions listed above)
    • Linux
    • There will not be an automated PK update solution for these VMs.
    • VMware ESX 9.0 contains the recommended manual PK update method.

     

    Available Platform Key Remediation Methods and Steps

    Follow the remediation actions mentioned below to update the Platform Key:

    1. Identify the Virtual Machines where Platform Key is out of date.
      1. Identify the Virtual Machines with Secure Boot & vTPM Enabled (PowerShell option available to list the VMs).
        1. For ESX 9.1.1.0, follow Identify the Virtual Machines with Secure Boot & vTPM Enabled in VMware ESX 9.1.1.0.
      2. Identify the Virtual Machines with missing or NULL Platform Key (this can be identified only inside the guest by executing certain commands).

    2. Follow the Remediation Actions mentioned in the table below for the relevant scenarios for Secure Boot and vTPM status with HW version greater than 13.

      ScenarioSecure BootvTPMRemediation Action
      ESXi 8.0 U3i (P08) and lower builds & ESX 7.xESXi 8.0 U3j (P09)ESX 9.1.1.0
      1DisabledDisabledNo ActionSilentPK Update

      Note: This is optional as Secureboot & vTPM are disabled      		SilentPK Update

      Note: This is optional as Secureboot & vTPM are disabled
      2EnabledDisabledManual Update from vUEFI interfaceSilentPK UpdateSilentPK Update
      3EnabledEnabledManual Update from vUEFI interface

      Manual Update from VMX Configuration

      (preferred for Non Windows VMs)

      For Windows VMs, wait for the automated PK update solution (to be available in an upcoming 8.x patch release)

      Capsule PK Update method for Windows VMs.

       

      For Non Windows VMs follow,

      Manual Update from VMX Configuration 

      4DisabledEnabledNo ActionNo ActionNo Action

    Identify the Virtual Machines where Platform Key is out of date

    Identify the Virtual Machines with Secure Boot & vTPM Enabled

    PowerShell method to list the Secure boot and vTPM status.

    1. Open PowerShell as Administrator
    2. Login to vCenter Server using Connect-VIServer

      Connect-VIServer -Server <vc_fqdn / ip_address> -User <username>

    3. Execute below CmdLet to identify the list of VMs with Secure boot enabled

      Get-VM | Where-Object {$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled -eq $true} | Select Name

    4. Execute below CmdLet to identify the list of VMs with vTPM enabled

      Get-VM | Where-Object { $_.ExtensionData.Config.Hardware.Device | Where-Object { $_.GetType().Name -eq "VirtualTPM" } }

    Note: Sample PowerShell script “SecureBootExportVMList.ps1” attached to this KB can be used to export all the VMs list from a vCenter Server in a CSV format as below:

    Identify the Virtual Machines with missing or NULL Platform Key (inside Guest OS)

    1. Verify the existing Platform Key Certificate.

      1. Linux

        1. Execute the following command and if the command does not return any output (blank result), the Platform Key (PK) needs to be updated.
          mokutil --pk
      2. Windows

        1. Open Windows PowerShell console as Administrator.
        2. Execute below commands:
          $pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der
        3. The Platform Key (PK) needs to be updated if the above command fails with below error, which means the Certificate is Invalid:
          PS C:\> $pk = Get-SecureBootUEFI -Name PK
PS C:\> $bytes = $pk.Bytes
PS C:\> $cert[44..($bytes.Length-1)]
Cannot index into a null array.
At line:1 char:1
+ $cert[44..($bytes.Length-1)]
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

          Note: In some Windows versions, the certutil command will show the result as "00" as below, which also means that the Platform Key (PK) is invalid.
          PS C:\> certutil -dump PK.der
 00                                                 .
 CertUtil: -dump command completed successfully.
PS C:\>$bytes.Length
 45

    Identify the Virtual Machines with Secure Boot & vTPM Enabled in VMware ESX 9.1.1.0.

    To identify VMs that are configured with out-of-date NULL PK, you can monitor the 'Virtual Machine UEFI Secure Boot Platform Key is out of date' alarm directly within the vCenter UI, or execute a PowerCLI script across your upgraded vCenter Server and ESX hosts to generate a detailed inventory of impacted VMs that have out-of-date NULL PK.

    PowerShell method to list the Secure boot and vTPM status.

    1. Open PowerShell as Administrator
    2. Login to vCenter Server using Connect-VIServer

      Connect-VIServer -Server <vc fqdn / ip address> -User <username>

    3. Execute below CmdLet to identify the list of VMs with Secure boot enabled

      Get-VM | Where-Object {$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled -eq $true} | Select Name

    4. Execute below CmdLet to identify the list of VMs with vTPM enabled

      Get-VM | Where-Object { $_.ExtensionData.Config.Hardware.Device | Where-Object { $_.GetType().Name -eq "VirtualTPM" } }

      Note: Sample PowerShell script “SecureBootExportVMListv2.ps1” attached to this KB can be used to export all the VMs list from a vCenter in a CSV format as below:

    Capsule PK update method for Secure Boot and vTPM enabled Virtual Machines (for VMware ESX 9.1.1.0 and future versions)

    Sequence of steps to be performed in Infra:

    1. Upgrade vCenter and ESX hosts in the cluster to 9.1.1.0.
    2. Identify the VMs that are eligible for Capsule PK update (follow section “Identify VMs that are eligible for Capsule PK update”)
    3. Required: Ensure PK update required VMs have gone through a “Power-on” in the new host (i.e, ESX 9.1.1.0).
    4. Ensure VM Hardware version is 14 or higher.

    Sequence of steps to be performed in Guest:

    1. Required: Install the latest Windows cumulative updates (July 2026 Windows cumulative updates or newer) on the Guest OS prior to upgrading VMware Tools to version 13.1.5, which is necessary for PK update support (requires a system restart).

      Note: This strict installation sequence does not apply if the Guest OS is Windows Server 2025 or Windows 11 24H2/25H2. For these specific versions, the Windows cumulative update can be installed after upgrading VMware Tools to version 13.1.5 to successfully update the PK..

    2. Upgrade VMware Tools to 13.1.5. (requires a system restart)
    3. In the Guest OS, open Device Manager and check the 'Platform Key Firmware' status. If the PK driver displays a yellow warning banner, an additional reboot is required to complete the PK update.

    SilentPK update for vTPM disabled Virtual Machines (for VMware ESXi 8.0 U3j, VMware ESX 9.1.1.0 and future versions)

    Schedule a restart of the Virtual Machines, and the Platform Key (PK) will be updated automatically during the reboot. Sample PowerShell method mentioned below can be used to restart multiple Virtual Machines.

    1. Open PowerShell as Administrator
    2. Login to vCenter Server using Connect-VIServer

      Connect-VIServer -Server <vc_fqdn / ip_address> -User <username>

    3. Restart the VMs using Restart-VMGuest CmdLet

      For single VM:
      Get-VM <VM Name>| Restart-VMGuest -Confirm:$false

      Restart all VMs in a Cluster:
      Get-Cluster <my-cluster> | Get-VM | Restart-VMGuest -Confirm:$false

    Note: Sample PowerShell script “RestartMultipleVMs.ps1” attached to the KB can be used to restart multiple VMs by entering the VM Names in a Text file. Script will initiate the Guest OS reboot of these VMs by connecting to vCenter Server and export the status in a CSV file as below:

    Manual Update from VMX configuration for vTPM enabled Virtual Machines (for VMware ESXi 8.0 U3j, VMware ESX 9.1.1.0 and future versions)

    CAUTION: If a vTPM is present and disk encryption software (such as BitLocker on Windows or LUKS on Linux) is sealed to specific TPM PCR registers, preparatory steps are required before performing the key update. These steps include creating a VM snapshot, saving the recovery key (for BitLocker-type solutions), or temporarily disabling TPM-sealed disk encryption. 

    Note: Below steps are recommended only for Linux Virtual Machines with vTPM Enabled. For Windows VMs, Broadcom recommends to wait for an automated solution to become available in a future release.

    1. Suspend TPM and take backup of TPM based applications inside Guest OS by following Guest OS or Application specific documentation.
    2. Shutdown the Virtual Machine
    3. Open PowerShell as Administrator
    4. Login to vCenter Server

      Connect-VIServer -Server <vc_fqdn / ip_address> -User <username>

    5. Add Virtual Machine Advanced Setting

      For Individual VM:
      Get-VM <VM Name> | New-AdvancedSetting -Name 'uefi.secureBoot.PK.resetOnce' -Value "TRUE" -Confirm:$false

      If the same needs to be done for all the VMs in a Cluster provided the VMs are already shutdown:
      Get-Cluster <my-cluster> | Get-VM | New-AdvancedSetting -Name 'uefi.secureBoot.PK.resetOnce' -Value "TRUE" -Confirm:$false

      Note: Follow the procedure Configure Virtual Machine Advanced File Parameters to add the parameter using vSphere Client.

    6. Power On the Virtual Machine
    7. Enable the TPM based application inside the Guest OS, follow Guest OS or Application specific procedures to perform this action.

    Note: Sample PowerShell script “AddResetOnceVMAdvancedParam.ps1” attached to the KB can be used to add ResetOnce Advanced Parameter on multiple VMs by entering the VM List in a text file. Script will add the Advanced config on Powered Off VMs and export the status in a CSV file as below:



    Note: This sample script will give a Warning before proceeding with adding advanced configuration as below:

    Manual Update from vUEFI Interface (for VMware ESXi 8.0 P08 and lower builds, VMware ESX 7.x & 9.x)

    1. Update the Platform Key (PK) by following the procedure described in Manual Update of the Secure Boot Platform Key in Virtual Machines.

    Managing vCenter Alarms

    Post VC and ESX update to 9.1.1.0, you may see "Virtual Machine UEFI Secure Boot Platform Key is out of date" alarms for individual VMs where Platform Key needs an update:

    Bulk Acknowledgement Procedure via UI

    1. Select the vCenter object and navigate to the Monitor tab.
    2. Go to Issues and Alarms > Triggered Alarms.
    3. Filter the "Secure Boot" alarms.
    4. Select all relevant VM alarms and click Acknowledge.

    Bulk Acknowledgement Procedure using PowerCLI Script

    Sample script to Acknowledge Secure Boot Alarms.

    Connect-VIServer -Server <vc_fqdn> -User <username>
$alarmMgr = Get-View AlarmManager
$targetAlarmName = "Virtual Machine UEFI Secure Boot Platform Key is out of date. Refer KB 423893"
$alarmDef = Get-AlarmDefinition -Name $targetAlarmName
$entities = Get-Inventory | Where-Object { $_.ExtensionData.TriggeredAlarmState }
foreach ($entity in $entities) {
    foreach ($alarm in $entity.ExtensionData.TriggeredAlarmState) {
        if ($alarm.Alarm -eq $alarmDef.ExtensionData.MoRef -and -not $alarm.Acknowledged) {
            $alarmMgr.AcknowledgeAlarm($alarm.Alarm, $entity.ExtensionData.MoRef)
        }
    }
}
     

    Disable Alarm (in case Secure boot alarm needs to be disabled)

    1. Select the vCenter object and navigate to the Configure tab.
    2. Go to Alarm Definitions
    3. Filter the "Secure Boot" alarm definition.



    4. Select the alarm and click on Disable..

    Supported Windows Guest OS List for Capsule PK update.

    The Capsule Platform Key (PK) update is supported for Windows 10, Windows 11, and Windows Server 2016/2019/2022/2025 Guest Operating Systems, as listed below..

    Windows Guest OSWindows cumulative updateVMTools version
    Windows Server 2025July 2026 Windows cumulative updates or newer13.1.5
    Windows 11 25H2July 2026 Windows cumulative updates or newer13.1.5
    Windows 11 24H2July 2026 Windows cumulative updates or newer13.1.5
    Windows 11 23H2July 2026 Windows cumulative updates or newer13.1.5
    Windows Server 2022July 2026 Windows cumulative updates or newer13.1.5
    Windows 10 22H2Support will be provided in an upcoming VMware Tools releaseSupport will be provided in an upcoming VMware Tools release
    Windows 10 21H2July 2026 Windows cumulative updates or newer13.1.5
    Windows Server 2019July 2026 Windows cumulative updates or newer13.1.5
    Windows 10 1809Support will be provided in an upcoming VMware Tools releaseSupport will be provided in an upcoming VMware Tools release
    Windows Server 2016Support will be provided in an upcoming VMware Tools releaseSupport will be provided in an upcoming VMware Tools release

Additional Information

Secure Boot Certificate Expiration FAQs.

Table of Contents

  1. Section 1: Background
  2. Section 2: Scope & Impact
  3. Section 3: Remediation
    1. Platform Key (PK)
    2. Key Exchange Key (KEK) and Signature Database (DB)

Section 1: Background

Q: What is UEFI Secure Boot, and how does it work in vSphere VMs?

UEFI Secure Boot is a firmware-based security feature that ensures a virtual machine boots only with trusted, digitally signed software by enforcing a cryptographic chain of trust from firmware to OS loader. In VMware vSphere VMs, this is implemented in the virtual UEFI (vUEFI) firmware, which validates each boot component using Secure Boot databases stored in virtual NVRAM: the Platform Key (PK) establishes the root of trust, the Key Exchange Key (KEK) authorizes updates, the DB contains allowed signatures, and the DBX lists revoked ones. During boot, the firmware verifies the bootloader (e.g., Windows Boot Manager), which in turn verifies subsequent components, preventing execution of untrusted code. The Secure Boot state persists with the VM (including across vMotion), integrates with vTPM for measured boot (e.g., PCR7 for BitLocker and VBS), and supports authenticated updates—often delivered via OS-Driven authenticated writes or firmware update capsules —to maintain trust over time.

SecureBoot Trust Delegation Model

Platform Ownership (PK)

            │

           ▼

Delegated Update Authority (KEK)

           │

          ▼

Operational Trust Lists (DB / DBX)

  • PK defines who controls trust.
  • KEKs define who may update trust.
  • DB/DBX define what is trusted or revoked.

Q: What are the original certificates stored in vUEFI PK, KEK and DB databases?

For vSphere VMs, Secure Boot certificates are initialized by the host at the first VM power-on and remain static for the life of the VM unless updated. The following table outlines the default certificate set based on the ESX version and VM HW Version used at the time of VM creation.

ESX Version and VM HW Version at VM creation

vUEFI database

Certificate

Expiration date

  • ESX 9: 9.x.x.x releases AND VM HW Version 14 or newer
  • ESX 8: 8.0 U3j (P09)+ releases AND VM HW Version 14 or newer

PK

Windows OEM Devices PK

Sep 2038

KEK

Microsoft Corporation KEK 2K CA 2023

Mar 2038

Microsoft Corporation KEK CA 2011

Jun 2026

DB

 

 

 

Windows UEFI CA 2023

Jun 2035

Microsoft UEFI CA 2023

Jun 2038

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate 

Dec 2019

VMware Secure Boot Signing

Oct 2037

8.0 U2 and 8.0 U3, up to 8.0 P08 release AND VM HW Version 14 or newer

PK

VMW.NULLPK

N/A

KEK

Microsoft Corporation KEK 2K CA 2023

Mar 2038

Microsoft Corporation KEK CA 2011

Jun 2026

DB

Windows UEFI CA 2023

Jun 2035

Microsoft UEFI CA 2023

Jun 2038

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate 

Dec 2019

VMware Secure Boot Signing

Oct 2037

  • Earlier ESX versions AND VM HW Version 14 or newer; OR
  • VM HW Version 13 on any ESX version

Note: Secure Boot support for vSphere VMs was introduced starting with HW Version 13.

PK

VMW.NULLPK

N/A

KEK

Microsoft Corporation KEK CA 2011

Jun 2026

DB

Microsoft Windows Production PCA 2011

Oct 2026

Microsoft Corporation UEFI CA 2011

Jun 2026

VMware Certificate

Dec 2019

VMware Secure Boot Signing
(Note: Starting from ESXi670-202004002)

Oct 2037

VM HW Version 12 or earlier on any ESX version

N/A: Secure Boot is not supported on VM Hardware Version 12 or earlier.

Q: What is the Microsoft Secure Boot Certificates expiration and transition?

Refer to the official Microsoft documentation: Secure Boot Certificate Updates Guidance

Section 2: Scope & Impact

Q: Are Secure Boot-enabled ESX hosts impacted by the Microsoft Secure Boot Certificates expiration?

This KB specifically covers vSphere Virtual Machines. For information regarding physical ESX hosts and the Secure Boot certificate expiration, refer to KB Secure Boot Certificate Expirations: Guidance for ESX Host Secure Boot.

Q: What vSphere VMs are affected by this transition, and how?

  • Because Secure Boot support for vSphere VMs was introduced starting with VM Hardware Version 13, Secure Boot certificate expiration is not relevant for VMs running VM Hardware Version 12 or earlier.
  • All vSphere VMs with Secure Boot enabled that currently lack the Microsoft 2023 certificates are affected, regardless of the Guest OS (Windows or Linux).
  • Ultimately, it is recommended that all Secure Boot-enabled VMs shift to use the Microsoft 2023 certificates to maintain long-term guest OS boot compatibility and security compliance.
  • To authorize a Key Exchange Key (KEK) update via the Guest OS, the VM must contain the Windows OEM Devices PK certificate. Currently, there are vSphere VMs (PK mentioned as VMW.NULLPK in above table) lacking this certificate, thus cannot process OS-driven KEK updates to these VMs. Broadcom's remediation strategy prioritizes automated solutions to add the Windows OEM Devices PK certificate to these VMs to minimize operational effort for customers, while also providing fully supported manual PK update methods as an alternative.
  • While vSphere VMs with Secure Boot disabled are NOT at risk of Secure Boot failures, Broadcom's automated PK update solutions handle these VMs differently based on their vTPM status to balance future-readiness with operational safety. The following table summarizes Broadcom's automated PK remediation strategy:

    Current PK CertificateSecure Boot StatusAffected by this certificate transition?vTPM StatusWill Broadcom's automated PK update solution apply?Rationale
    VMW.NULLPKEnabledYesDisabledYesUpdate VMW.NULLPK to the Windows OEM Devices PK certificate to facilitate KEK updates.
    Enabled
    • Yes: OS-Coordinated Update for supported Windows versions
    • No: For Linux and unsupported Windows
    • For supported Windows VMs: Update VMW.NULLPK to the Windows OEM Devices PK certificate, using a Capsule Update mechanism, to facilitate KEK updates. This allows the OS to handle Secure Boot Certificate changes along with the vTPM measurement changes safely without breaking vTPM-based applications. (Note: Refer to the list of Windows versions that support Capsule PK Update.)
    • For Linux and unsupported Windows VMs: No automated PK updates to avoid the risk of breaking vTPM-based applications.
    DisabledNoDisabledYesUpdate VMW.NULLPK to the Windows OEM Devices PK certificate to ensure PK readiness if Secure Boot is enabled in the future.
    EnabledNoNo automated PK updates to avoid the risk of breaking vTPM-based applications.

Q: Does upgrading an older VM to Hardware Version 13+ automatically enable Secure Boot?

No. Upgrading the VM Hardware Version of an existing VM does not automatically enable Secure Boot. Secure Boot must be explicitly enabled in the VM's boot options. Therefore, simply upgrading a VM to VM Hardware Version 13 or newer does not automatically put it at risk of Secure Boot failures.

Q: What will happen to my Secure Boot-enabled VMs if I cannot update KEK and DB certificates prior to their expiration?

  • After expiration of the certificates, the keys are no longer valid for signing new payloads. Specifically, new DB and DBX update payloads will not be signed using the 2011 KEK, and new OS boot components (such as bootloaders) will not be signed using the 2011 DB keys. However, the Secure Boot verification process does not check certificate expiration, which means the 2011 certificates can still verify the integrity and authenticity of payloads that were signed with the 2011 keys, regardless of certificate expiration.
  • OS Boot: Existing guest OSes will continue to boot normally.
  • OS Updates:
    • OS update payloads unrelated to Secure Boot (KEK, DB/DBX, and bootloaders) are completely unaffected.
    • DB/DBX update payloads signed by the 2011 KEK (during its valid period) can be successfully applied even after the 2011 KEK certificate expiration, as long as the 2011 KEK certificate remains in the vUEFI KEK database.
    • New DB/DBX update payloads that are signed solely by, and thus rely solely on, the 2023 KEK for verification will fail if the 2023 KEK certificate is missing from the vUEFI KEK database.
    • Payloads intended to update KEK will always fail if the Windows OEM Devices PK certificate is missing from the vUEFI PK database, regardless of the Microsoft Corporation KEK CA 2011 expiration.
    • KEK update payloads can be successfully applied as long as the Windows OEM Devices PK certificate is present in the vUEFI PK database, regardless of the Microsoft Corporation KEK CA 2011 expiration.
  • OS Installation: VMs lacking the 2023 DB certificates will be unable to boot or install future operating systems that rely solely on these new certificates for verification. Consult your guest OS vendor to determine which new OS releases require the 2023 DB certificates for fresh installations. This ensures you can properly coordinate vUEFI database updates (PK, KEK, and DB) prior to deploying new OSes.

Section 3: Remediation

Q: Who is responsible for updating PK, KEK, and DB for Secure Boot-enabled VMs?

Broadcom's Responsibility:

VMware is taking the lead on ensuring the presence of the Windows OEM Devices PK certificate in the virtual firmware to facilitate KEK update. Our goal is to minimize operational overhead through automated delivery mechanisms for VMs running on major ESX versions currently under General Support.

  • For existing VMs: VMware is delivering a comprehensive solution to add the Windows OEM Devices PK certificate into the vUEFI if it is detected as missing from VMs running on ESX 8.x and 9.x hosts. For ESX 9.x, this capability is available from 9.1.1.0 and for 8.x, this capability is partially available from 8.0 U3j for vTPM disabled VMs. While this solution utilizes automated delivery mechanisms to minimize overhead, it will still require customer actions. (Note: This KB will be updated once the 8.x patch is available for vTPM enabled VMs.)
  • For newly created VMs:
    • If created from a standard VM template or an OVF/OVA template containing an NVRAM file: The VM inherits the exact same Secure Boot certificates as the source template. Upon the VM's first power-on, Broadcom's PK update solution treats this VM as an existing VM (see above).
    • If created from scratch (i.e., not from a template) or from an OVF/OVA template without an NVRAM file (or using the noNvramFile option): The Windows OEM Devices PK certificate is initialized automatically on ESX 9.x hosts. For ESX 8.x hosts, this is initialized automatically after ESX 8.0 U3j (P09) patch is applied. And the Microsoft 2023 KEK and DB certificates are initialized automatically on ESX 8.0 U2 or newer hosts. (See the "original certificates table" above for more details).

Customer's Responsibility:

  • For PK updates:  Customers should execute PK update based on VMware guidance.
  • For KEK and DB updates: Customers should follow their respective OS vendor's guidance to update them natively from within the guest OS.
    • Important Risk Note: Broadcom's KEK/DB update methods (via the vUEFI interface or VMX configuration) can serve as a fallback. However, updating these from outside the guest OS carries the risk of breaking applications (such as triggering BitLocker recovery) for vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the OS's awareness.

Q: How should I handle the Secure Boot certificate transition for virtual appliances?

From a technical perspective, the Secure Boot certificate transition for virtual appliances is identical to that of regular VMs. However, we highly recommend working with your specific appliance provider before making any changes. You should understand your virtual appliance's Secure Boot baseline, vTPM dependencies, application state, and overall maintenance strategy to determine the best path.

By default, for vSphere/VCF management appliances (e.g., vCenter Server), Secure Boot is disabled, so you can safely skip these VMs.

Q: How should I handle the Secure Boot certificate transition for VM templates?

The approach depends on the type of template you are using, as Secure Boot certificate inheritance behaves differently:

  • Standard vCenter VM Templates: VMs created from a standard template will inherit the exact same Secure Boot certificates as the source template. Upon the VM's first power-on, Broadcom's PK remediation solution treats this VM as an existing VM. Therefore, we highly recommend ensuring your VM templates contain the Windows OEM Devices PK certificate, as well as the Microsoft 2023 certificates in the KEK and db databases. To update a template that lacks these certificates, convert the template to a virtual machine, apply the necessary updates, and then convert it back to a template.
  • OVF/OVA Templates: The behavior of an OVF/OVA template depends on whether it includes an NVRAM file:
    • Without NVRAM (or using noNvramFile): If the OVF/OVA does not contain an NVRAM file, or if deployed with the noNvramFile option, the resulting VM will automatically initialize its Secure Boot certificates directly from the underlying ESX host upon its first power-on. You can safely skip these VM templates.
    • With NVRAM: If the OVF/OVA includes an NVRAM file, the deployed VM will inherit the certificates embedded in that file (similar to a standard VM template), provided the noNvramFile option is not used during deployment. To update these templates, you must deploy the OVF/OVA to a virtual machine, apply the certificate updates, and then export it as a new OVF/OVA.

Platform Key (PK)

Q: How can I update PK?

You should always update PK using VMware-supported methods. All methods below require VM Hardware Version 14 or newer. (Note: Secure Boot support was introduced in Hardware Version 13, but updating PK requires the virtual NVRAM capabilities of Hardware Version 14+). VMware currently provides, or plans to provide, the following four update methods:

  1. Manual Update from the vUEFI interface: Applies to ESX 7, 8, and 9. (Refer to KB: Manual Update of the Secure Boot Platform Key in Virtual Machines).
  2. Manual Update from VMX configuration: Supported on ESX 8.0 U3j (P09)+ and ESX 9.0+. (Refer to Manual Update from VMX configuration).  
  3. Silent PK update for vTPM-disabled VMs: vSphere will silently add the missing Windows OEM Devices PK certificate to the PK database for vTPM-disabled VMs during guest reboots or VM power cycles. For ESX 8, this capability is available starting with ESX 8.0 U3j (P09) (Refer to SilentPK update). For ESX 9, this capability is included in 9.1.1.0.
  4. Capsule PK update for vTPM-enabled Windows VMs: Enables a secure mechanism to safely update the out-of-date NULL PK on Secure Boot-enabled, vTPM-enabled Windows virtual machines during a guest reboot without interrupting TPM-based applications. This method requires the virtual machine to be running on an ESX host version 9.1.1.0 or later. The Capsule PK update driver triggering the PK update is available starting in VMware Tools  13.1.5 for supported Windows versions, except Windows Server 2016, Windows 10 64-bit 22H2, and 1809, which will be supported in a future VMware Tools release. For the Capsule PK update, the July 2026 Windows Cumulative Update or later is required. You must install this cumulative update before installing or upgrading VMware Tools to version 13.1.5 to allow the installation of the PK update driver, except for Windows Server 2025, Windows 11 25H2, and 24H2. For ESX 8.x, this capability will be added in a future patch.

We will update this KB when the planned patches become available.

Q: How can I identify VMs that are lacking the Windows OEM Devices PK certificate?

  • Refer to Identify the Virtual Machines with missing or NULL Platform Key.
  • You will be able to easily identify VMs lacking the Windows OEM Devices PK certificate across your environment at scale using one of the following upcoming methods:
    • vCenter Alarms: Using the "Out-of-date Platform Key Alarm" feature in VMware ESX 9.1.1.0 and planned for an upcoming release of vSphere 8 (requires patching both vCenter and ESX).
    • PowerCLI Script: Once ESX is patched (even without patching vCenter), a VMware-provided PowerCLI sample script can be used to inventory VMs lacking the Windows OEM Devices PK certificate.

Q: What are the VMware-recommended PK update workflow and detailed steps for vSphere 8.x and 9.x?

To minimize operational effort for PK updates for VMs across a cluster containing various VM types, we recommend proceeding in the following order:

  • Note: VMs running VM Hardware Version 12 or earlier are out of scope for the PK update as they don't support Secure Boot.

For VMs running HW Version 14 or newer:

  • Perform Silent PK Update for vTPM-disabled VMs regardless of whether Secure Boot is enabled or disabled. While vSphere VMs with Secure Boot disabled are NOT at risk of Secure Boot failures, the Silent PK Update proactively and safely prepares the VM with the correct Windows OEM Devices PK certificate in case Secure Boot is ever enabled in the future.
  • Perform Capsule PK Update for Secure Boot-enabled AND vTPM-enabled Windows VMs.
  • Perform Manual PK Update for vTPM-enabled Legacy Windows & Linux VMs.
    • Important Risk Note: Manual PK update methods (via the vUEFI interface or VMX configuration) update the PK from outside the guest OS. This carries a risk of breaking applications (such as triggering BitLocker recovery) on vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the guest OS's awareness.
  • Exclusion Note: For VMs with Secure Boot disabled AND vTPM enabled, do NOT perform a PK update. These VMs are not at risk of Secure Boot failures. Because Capsule Update is unavailable when Secure Boot is disabled, and hypervisor-level updates carry the risk of triggering security lockdowns (e.g., BitLocker recovery), these VMs should be excluded from the PK update.

For VMs running HW Version 13:

  • For Secure Boot-enabled VMs: You must first upgrade the VM Hardware Version to 14 or newer. Once upgraded, perform the PK update following the three steps above based on the VM's specific configuration. Refer to KB 315390  and KB 312100 for VM Hardware Version upgrade guidance.
  • For Secure Boot-disabled VMs: These VMs should be excluded from the PK update. They do not face Secure Boot failures, and the PK update mechanism does not apply to this hardware version.

We will keep this KB updated with detailed steps for each workflow as the planned patches enabling these PK updates become available.

Q: Will there be future patch for vSphere 7.x version?

As vSphere 7 is beyond its End of General Support date, no automated update tools will be available. Customers remaining on vSphere 7 must perform manual updates for existing and newly created VMs referencing Manual Update of the Secure Boot Platform Key in Virtual Machines or upgrade to a supported version of vSphere to utilize the automation methods.

Q: When can I update PK?

After reviewing the answers to the above questions, you should decide on your update window based on the specific tools you choose to use and the availability of the required patches, as described above.

Key Exchange Key (KEK) and Signature Database (DB)

Q: How can I update KEK and DB?

  • It is always recommended that you follow the OS vendor's guidance to update KEK and DB.
  • As a contingency, VMware provides two supported manual methods: the vUEFI interface (ESX 7, 8, 9) method or the VMX configuration method (ESX 9.0+ and planned 8.x patches).  
    • Important Risk Note: Broadcom's KEK/DB update methods (via the vUEFI interface or VMX configuration) can serve as a fallback. However, updating these from outside the guest OS carries the risk of breaking applications (such as triggering BitLocker recovery) for vTPM-enabled VMs, as it alters Secure Boot variables and vTPM measurements without the OS's awareness.
    • For KEK/DB update via the vUEFI interface for ESX 7, 8, 9, refer to KB Manual Update of the Secure Boot Platform Key in Virtual Machines.
    • For KEK/DB update via the VMX configuration, refer to KB: Secure Boot Custom Certificates.  (Note: This capability currently exists on ESX 9.x hosts and is available on ESX 8.x hosts starting with the 8.0 U3j patch.)

Q: How can I check if the Microsoft 2023 certificates are present in the vUEFI KEK and DB databases?

The new 2023 KEK certificate is Microsoft Corporation KEK 2K CA 2023. Additionally, Microsoft issued three new 2023 DB certificates: Windows UEFI CA 2023, Microsoft UEFI CA 2023, and Microsoft Option ROM UEFI CA 2023.

Note: The Microsoft Option ROM UEFI CA 2023 certificate is optional and is primarily used to sign third-party Option ROMs (typically found on networking or graphics PCIe passthrough devices), see the subsequent FAQ for guidance on how to handle this specific certificate.

While you should always refer to your OS vendor's official documentation for validation, you can generally use the methods described in the Resolution section of this KB to check the KEK database, and use the following OS-native methods to check your DB database:

For Windows: You can verify the DB certificates natively using PowerShell. Running the following command in an elevated prompt will return True if the certificate is present:

PowerShell

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

For Linux: You can use native tools like efitools or mokutil to read Secure Boot variables in plain text. For instance, running the following commands will print the DB lists, allowing you to confirm the presence of the 2023 DB certificates:

Bash

# Using efitools: 
sudo efi-readvar -v db

# Or using mokutil: 
mokutil --db

Q: How does the omission of the Microsoft Option ROM UEFI CA 2023 from vSphere VMs affect the Secure Boot certificate transition?

Currently, the Microsoft Option ROM UEFI CA 2023 certificate is not automatically initialized into the vUEFI DB during VM creation.

  • For VMs without passthrough devices, this certificate is not required for boot.
  • For VMs that do utilize passthrough devices, this certificate might be required if the passthrough device relies on Option ROM firmware to boot.

If you plan to upgrade the firmware of your passthrough device, you must first consult your hardware vendor to understand if the new device firmware solely relies on the Microsoft Option ROM UEFI CA 2023 certificate for Secure Boot verification. If so, this certificate must be present in the VM’s vUEFI DB before the firmware upgrade is performed.

For VMs that require this certificate, we recommend the following steps to add the Microsoft Option ROM UEFI CA 2023 certificate to the vUEFI DB prior to a passthrough device firmware upgrade:

  • For Windows VMs: The Windows OS handles the transition natively by automatically adding the missing Microsoft Option ROM UEFI CA 2023 certificate to the DB, as long as the already-trusted Microsoft Corporation KEK CA 2011 is present in the vUEFI KEK database and the Microsoft Corporation UEFI CA 2011 is present in the vUEFI DB. You should perform the DB update following Microsoft's guidance, verify the certificate is in place, and then perform the physical device firmware upgrade.
  • For Linux VMs: Linux guest OS native update tools (such as fwupd) do not automatically install the Microsoft Option ROM UEFI CA 2023 certificate. Before upgrading the passthrough device firmware, you must manually import the Microsoft Option ROM UEFI CA 2023 certificate into the VM’s vUEFI DB using VMware-supported methods (such as the manual vUEFI interface or VMX configuration methods as outlined above) or with authenticated writes from the Linux shell prompt. Confirm the certificate is successfully enrolled in the DB, and then proceed with the device firmware upgrade.

Q: When can I update KEK?

  • Via OS Methods: You must update PK first if the Windows OEM Devices PK certificate is missing from your VM's UEFI.  A KEK update initiated from within the Guest OS will always fail if a valid Platform Key is not present to authorize the change. Once the Windows OEM Devices PK certificate is present, you can update KEK at any time following your OS vendor's guidance.
  • Via VMware Methods: If using the manual vUEFI or VMX methods, you can update based on tool availability.

Q: When can I update DB?

  • Via OS Methods: You can update DB at any time per the OS vendor's guidance. Specifically, for Windows VMs, Microsoft has delivered DB update payloads via Windows Update for this certificate transition. Because these payloads were signed by the 2011 KEK, they can be applied anytime (even after the 2011 KEK certificate expires), as long as the 2011 KEK certificate remains present in the virtual firmware.
  • Via VMware Methods: If using the manual vUEFI interface or VMX configuration methods, you can update based on tool availability.

Q: When will the Microsoft 2011 DB certificates be forced into revocation?

Certificate revocation means it is explicitly removed from the DB or added to the DBX. We are not currently aware of any near-term timeline for a forced revocation from our OS partners, consult your OS vendor for this.

Change Log:

  • 29-Apr-2026: Modified the Environment section to add Telco cloud versions and added FAQs section in the Additional Information section.
  • 26-May-2026: Added a Table of Contents at the beginning to make the FAQ section easier to read. Also added new FAQs and additional clarity on Secure boot-disabled VMs, Identifying secure boot-enabled VMs, VM templates, Virtual appliances, VM hardware versions & Checking the presence of Microsoft 2023 certificates.
  • 27-May-2026: Modified the resolution section to add the fix information on 8.0 P09 to automatically remediate PK during VM reboot for vTPM disabled VMs. Also, updated the FAQ section to list the 8.0 P09 version.
  • 29-May-2026: Modified the FAQ "Who is responsible for updating PK, KEK, and DB for Secure Boot-enabled VMs" - removed a duplicate line and updated the 8.0 U3j (P09) patch information. Also, made couple of more changes, modified patch name from 8.0 P09 to the actual release name 8.0 U3j (P09), modified "VMware's" to "Broadcom's" and corrected a syntax error in PowerCLI command Connect-VIServer, changed "-Name" to "-Server".
  • 02-July-2026: Added "Remediation Recommendations" & "Platform Key Remediation Tool Availability" sections at the beginning of Resolution section to explain more details on the Platform Key updates. Also, added a Table of Contents section for Resolution section.
  • 02-Sep-2026: Updated the Issue/Resolution and FAQ sections for VMware ESX 9.1.1.0 release. This version supports Capsule PK update method for vTPM enabled VMs, SilentPK update for vTPM disabled VMs and vCenter Alarms to identify the VMs with out of date Platform Key.

Attachments

SecureBootExportVMListv2.ps1 get_app
AddResetOnceVMAdvancedParam.ps1 get_app
RestartMultipleVMs.ps1 get_app
SecureBootExportVMList.ps1 get_app
Powered by Wolken Software