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

Secure Boot certificate update failures or warnings in VMware virtual machines as Microsoft Secure Boot certificates approach expiration.

One or more of the following symptoms may be present:

  • Windows Event Viewer logs Event ID 1801, indicating unsuccessful Secure Boot certificate update attempts.
    "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain full protection. This device signature information is included here."
  • Microsoft Secure Boot automated updates fail to install new 2023 certificates.
  • Missing Microsoft Corporation KEK 2K CA 2023 in the virtual machine Secure Boot KEK database.
  • Failure to install updated DB, DBX, or Option ROM certificates.
  • Unable to update the Microsoft UEFI certificate because the following error message is returned for Event 1769:
    The Secure Boot updated failed to update KEK 2023 with error invalid access to memory location.
  • 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.

Important Note:

  • The virtual machines will continue to boot even after the certificate expiry.
  • An expired KEK certificate impacts the ability to update 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

  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

  • VMware ESXi 8.0 U3j (P09) contains the fixes to enable automated remediation of Platform Key during the Virtual Machine reboot for vTPM-disabled Virtual Machines.
  • There are no automated remediation methods available at this time for vTPM-enabled Virtual Machines (Windows & Linux). In coordination with Microsoft, Broadcom Engineering is actively working towards implementing an automated solution in a future release to update the Platform Key (PK) on the affected vTPM-enabled Windows VMs which will facilitate the certificate rollout as outlined in Microsoft Guideline (MS KB ID: 5062713). Broadcom recommendation for Windows VMs with vTPM-enabled is to wait for an automated solution to become available in a future release.

Platform Key Remediation

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

  1. Identify the Virtual Machines where Platform Key Update is required.
    1. Identify the Virtual Machines with Secure Boot & vTPM Enabled (PowerShell option available to list the VMs).
    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.x
    1DisabledDisabledNo ActionSilentPK Update

    Note: This is optional as Secureboot & vTPM are disabled    		No Action
    2EnabledDisabledManual Update from vUEFI interfaceSilentPK UpdateManual Update from vUEFI interface
    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)

    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 9.1.x patch release)

    4DisabledEnabledNo ActionNo ActionNo Action


  3. After verifying the Platform Key is Windows OEM Devices PK, follow Microsoft’s Secure Boot update guidance to complete KEK, DB, DBX, and bootloader updates.
  4. For Linux virtual machines, manually update the certificates by following the steps defined in the Additional Information section of the KB Manual Update of the Secure Boot Platform Key in Virtual Machines.

Identify the Virtual Machines where Platform Key Update is required

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

SilentPK update for vTPM disabled Virtual Machines (for VMware ESXi 8.0 U3j 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 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.

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: We'll update this KB to provide the list of supported Windows versions at the time of the Capsule Update feature delivery.)
    • 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 (starting from planned future patches). While this solution utilizes automated delivery mechanisms to minimize overhead, it will still require customer actions. (Note: This KB will be updated once the patches are available.)
  • 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.

Q: How can I identify VMs that have secure boot enabled?

You can identify VMs with Secure Boot enabled using either the vSphere Client or VMware PowerCLI.

  • Via vSphere Client (UI): You can easily check the status of multiple VMs at once. Navigate to any cluster, host, or folder in your vCenter inventory and click the VMs tab. Right-click any of the column headers, select Show/Hide Columns, and check the box for Secure Boot. This will add a dedicated column displaying the Secure Boot status (Enabled or Disabled) for every VM in that view.
  • Via PowerCLI (Scripting): For searching at scale, you can query the EfiSecureBootEnabled property. Running the following simple PowerCLI command will list all VMs in your environment and their Secure Boot status:

    PowerShell

    Get-VM | Select-Object Name, @{N="SecureBootEnabled";E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}}

    (To filter and only show VMs where it is enabled, you can append | Where-Object {$_.SecureBootEnabled -eq $true} to the command).

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. This capability will be added to ESX 8.x and 9.x in future patches. For ESX 8, this capability is available starting with ESX 8.0 U3j (P09) (Refer to SilentPK update). For ESX 9, this capability will be included in a planned future patch.
  4. Capsule PK update for vTPM-enabled Windows VMs: This method depends on planned Microsoft Windows patches. For supported Windows versions with the required patch installed, the missing Windows OEM Devices PK certificate will be automatically added to the PK database upon a guest reboot following a reboot prompt. This capability will be added to ESXi 8.x and 9.x in future patches. Additionally, a PK update driver is required to trigger the update. This driver will be delivered via Windows Update and also included in a planned VMware Tools release.

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?

  • You can manually check the PK certificate by following the certificate verification steps in KB Manual Update of the Secure Boot Platform Key in Virtual Machines.
  • 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 planned "Out-of-date Platform Key Alarm" feature in upcoming vSphere 8 and 9 releases (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.

We will update this KB when the planned patches become available and will also provide the sample script here.

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:

  • Step 1: 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.
  • Step 2: Perform Capsule PK Update for Secure Boot-enabled AND vTPM-enabled Windows VMs.
  • Step 3: 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.
    • Best Practice Note: Instead of upgrading to the bare minimum Hardware Version 14, consider upgrading to the latest Hardware Version supported by your environment to maximize performance and supportability. For detailed guidance, refer to KB 315390  and KB 312100.
  • 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 will be delivered to ESX 8.x hosts in a planned patch. Once the ESX 8.x patch becomes available, we will update both that KB and this current KB.)

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".

Attachments

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