Microsoft has announced that the original Secure Boot certificates introduced with Windows and UEFI Secure Boot in 2011 are approaching the end of their lifecycle and will begin expiring between June and October 2026.

To maintain a trusted boot chain and continue receiving future boot-level security updates, Microsoft is rolling out a new generation of Secure Boot certificates and revocation lists through Windows Update and firmware updates.

For administrators managing Windows Server on physical hardware, Hyper-V, or VMware vSphere, it is important to understand whether Secure Boot is enabled, whether the required updates have already been deployed, and how to verify the current migration status of a system.

In this post, we will examine the upcoming Secure Boot certificate expiration, review Microsoft’s Secure Boot servicing mechanism, verify the readiness of fully patched Windows Server systems, and explore VMware-specific considerations that may affect the successful deployment of the new Secure Boot certificates.


Table Of Contents
  1. Background
  2. How Secure Boot Validation Works During System Startup
  3. Affected Systems
  4. Checking the Deployment Status of the 2023 Secure Boot Certificates
  5. Activating the 2K23 Certificates: Updating the UEFI NVRAM and Boot Manager Database
  6. Secure Boot Certificate Updates on VMware vSphere
  7. Links


Background

After more than 15 years of service, Microsoft’s original Secure Boot certificates issued in 2011 are reaching their planned expiration dates. The first certificates begin expiring in June 2026, followed by additional Secure Boot certificates in October 2026.

Systems that continue relying on the older certificate chain will not immediately stop booting, but they may enter a degraded security state and eventually lose the ability to receive future Secure Boot and bootloader security updates.


The UEFI Secure Boot DB and KEK need to be updated with the corresponding new certificate versions.

It is important to note that this Secure Boot certificate transition only affects systems where Secure Boot is enabled. Systems running in legacy BIOS mode or UEFI mode with Secure Boot disabled are not impacted by the upcoming certificate expiration because they do not rely on the Secure Boot trust hierarchy during the startup process.


You can verify whether Secure Boot is enabled by running the following PowerShell command:

PS> Confirm-SecureBootUEFI


Two of the most important Secure Boot databases are the Key Exchange Key (KEK) database and the Allowed Signature Database (DB).

The KEK database contains trusted certificates that are authorized to update the Secure Boot configuration, including the DB and DBX databases.

The DB database contains the certificates and digital signatures that are trusted during the boot process. When the firmware loads a boot component, its digital signature is validated against the certificates stored in the DB database.

As part of Microsoft’s Secure Boot certificate transition, both the KEK and DB databases must be updated with new 2023 certificates. These new certificates will eventually replace the existing 2011 certificate chain that has been used by Windows systems for more than a decade.

The hierarchy of these certificates are as follows:

Platform Key (PK)
        │
        ▼
Key Exchange Keys (KEK)
        │
        ▼
Allowed Signature Database (DB)
Forbidden Signature Database (DBX)
  • PK = Root of trust
  • KEK = Allowed to update DB and DBX
  • DB = Trusted certificates used during boot
  • DBX = Revoked certificates that must no longer be trusted


To determine which PK Certificate, KEK certificate and DB certificate currently is used by Windows we can use the UEFIv2 PowerShell module.

The UEFIv2 PowerShell module we first need to install and import on the system we want to check.

PS> Install-Module -Name UEFIv2
PS> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
PS> Import-Module -Name UEFIv2


On legacy VMware virtual machines (pre-ESXi 8.0 U2 / ESXi 9.0 design), the PK is often unprovisioned or uses a non-standard signature type. When you run the check, PowerShell returns a warning because it cannot find a valid certificate to decode:

That GUID (452e8ced...) essentially represents a “NULL” or “Empty” signature. In this state, your VM is “unowned,” and Windows will fail to apply the 2023 certificate updates.

PS> (Get-UEFISecureBootCerts pk).signature


The following command shows the certificates that are allowed to modify Secure Boot databases.

The output shows the contents of the active Key Exchange Key (KEK) database. In this example, only the original Microsoft Corporation KEK CA 2011 certificate is present, indicating that the system has not yet received the corresponding 2023 Key Exchange Key used to authorize future Secure Boot database updates as part of Microsoft’s Secure Boot certificate transition.

PS> (Get-UEFISecureBootCerts kek).signature


The following command shows the certificates that Secure Boot actually trusts when validating boot components.

The output above shows the contents of the active Secure Boot Allowed Signature Database (DB) on a Windows Server 2022 virtual machine running on VMware vSphere. In addition to VMware’s own Secure Boot signing certificates, the database contains the original Microsoft 2011 Secure Boot certificates, indicating that the system has not yet been migrated to the new Microsoft 2023 Secure Boot trust chain.

PS> (Get-UEFISecureBootCerts db).signature


Microsoft is updating both to transition from the 2011 trust chain to the new 2023 trust chain.

  • the trust anchors used during boot (DB)
  • and the certificates authorized to update Secure Boot itself (KEK)


Unlike the KEK, DB, and DBX databases, which are updated as part of Microsoft’s Secure Boot certificate transition, the Platform Key (PK) typically remains unchanged. The PK is usually issued and managed by the platform manufacturer, such as Dell, Lenovo, HP, or VMware, and serves as the root of trust that authorizes updates to the Secure Boot hierarchy below it.

As we will see later in this post, an invalid Platform Key configuration on VMware virtual machines can prevent the Secure Boot certificate migration from completing successfully. We will therefore also examine how to identify this issue and update the Platform Key to allow the remaining Secure Boot certificate updates to be installed successfully.

How Secure Boot Validation Works During System Startup

Understanding how Secure Boot validation works helps explain why Microsoft’s 2023 certificate migration requires updates not only to the Windows Boot Manager but also to the underlying UEFI Secure Boot databases.

Although Windows installs and manages the Secure Boot certificate updates, the actual Secure Boot validation process is performed by the UEFI firmware. During system startup, the firmware uses the Platform Key (PK), Key Exchange Keys (KEK), and Secure Boot signature databases (DB and DBX) to verify that the Windows Boot Manager is signed by a trusted certificate before allowing it to execute.

The simplified Secure Boot startup sequence is shown below:

Power On
   │
   ▼
UEFI Firmware
   │
   ├─ Reads PK (Platform Key)
   ├─ Reads KEK (Key Exchange Keys)
   ├─ Reads DB (Trusted Certificates)
   ├─ Reads DBX (Revoked Certificates)
   │
   ├─ Validates bootmgfw.efi
   │      against certificates in DB
   │      and checks DBX
   │
   └─ If trusted, executes Boot Manager
               │
               ▼
Windows Boot Manager
               │
               ├─ Validates winload.efi
               ├─ Loads Windows Kernel
               └─ Starts Windows


This means that the Windows Boot Manager itself does not decide whether it is trusted. Instead, the UEFI firmware performs the trust validation before the Boot Manager is allowed to run. If the Boot Manager’s signature cannot be validated against the certificates stored in the Secure Boot databases, the firmware will block the boot process.

This is also the reason why the Secure Boot certificate migration requires updating the firmware trust chain. The UEFI firmware must first trust the new Windows UEFI CA 2023 certificate before it can successfully validate and start a Windows Boot Manager signed with the new 2023 certificate chain.

Affected Systems

Physical and virtual machines (VMs) on supported versions of Windows 10, Windows 11, Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, the systems released since 2012, including the long-term servicing channel (LTSC).

Not affected: Copilot+ PCs released in 2025


Secure Boot uses certificate-based trust hierarchy to ensure that only authorized software runs during system startup. At the top of this hierarchy is the Platform Key (PK), typically managed by the OEM or a delegate, which acts as the root of trust. The PK authorizes updates to the Key Enrollment Key (KEK) database, which in turn authorizes updates to two critical signature databases: the Allowed Signature Database (DB) and the Forbidden Signature Database (DBX). This layered structure ensures that only validated updates can modify the system’s boot policy, maintaining a secure boot environment. See how it works in Updating Secure Boot keys.


Windows systems released since 2012 might have expiring versions of the certificates listed below. The UEFI Secure Boot DB and KEK need to be updated with the corresponding new certificate versions.

See what new certificates will be available in the coming months to maintain UEFI Secure Boot continuity.

Expiration dateExpiring certificateUpdated certificateWhat it doesStoring location
June 2026Microsoft Corporation KEK CA 2011Microsoft Corporation KEK 2K CA 2023Signs updates to DB and DBXKEK
June 2026Microsoft Corporation UEFI CA 2011 (or third-party UEFI CA)*a) Microsoft Corporation UEFI CA 2023b) Microsoft Option ROM UEFI CA 2023a) Signs third-party OS and hardware driver componentsb) Signs third-party option ROMsDB
Oct 2026Microsoft Windows Production PCA 2011Windows UEFI CA 2023Signs the Windows bootloader and boot componentsDB


You need two new certificates for Microsoft Corporation UEFI CA 2011, which together allow for more granular control.

Microsoft and partner OEMs will be rolling out certificates to add trust for the new DB and KEK certificates in the coming months. (origin article published Jun 2025)


The CAs ensure the integrity of the device startup sequence. When these CAs expire, the systems will stop receiving security fixes for the Windows Boot Manager and the Secure Boot components.

Compromised security at startup threatens the overall security of affected Windows devices, especially due to bootkit malware. Bootkit malware can be difficult or impossible to detect with standard antivirus software. For example, even today, the unsecured boot path can be used as a cyberattack vector by the BlackLotus UEFI bootkit (CVE-2023-24932).


Every Windows system with Secure Boot enabled includes the same three certificates in support of third-party hardware and Windows ecosystem. Unless prepared, physical devices and VMs will:

  • Lose the ability to install Secure Boot security updates after June 2026.
  • Not trust third-party software signed with new certificates after June 2026.
  • Not receive security fixes for Windows Boot Manager by October 2026.


To prevent this, you’ll need to update your organization’s entire Windows ecosystem with certificates dated 2023 or newer. This will also help you apply mitigations needed to help secure your systems against the BlackLotus and similar boot-level cyberattacks today.


Microsoft will update the Secure Boot certificates as part of their latest cumulative update cycle.


Source: https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856

Checking the Deployment Status of the 2023 Secure Boot Certificates

Before examining the Secure Boot trust hierarchy in detail, it is useful to first determine which Secure Boot certificates are currently present on the system. This allows us to quickly identify whether the new 2023 Secure Boot certificates have already been deployed and whether they are active or only staged for a future migration phase.

The following PowerShell commands, based on Dell’s Secure Boot certificate verification guidance, can be used to inspect the currently configured Secure Boot certificate databases and determine the current deployment state of the Microsoft 2023 Secure Boot certificates.


The 4 commands below check for the presence of the 4 major 2023 Secure Boot certificates in the active Secure Boot databases.

Checks whether the Windows UEFI CA 2023 certificate is present in the active Allowed Signature Database (DB). This certificate is used to trust newer Microsoft Windows boot components, including updated Windows Boot Manager and WinPE images signed with the new 2023 certificate chain.

PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Windows UEFI CA 2023'


Checks whether the Microsoft UEFI CA 2023 certificate is present in the active Allowed Signature Database (DB). This certificate is used to trust additional Microsoft UEFI applications and boot loaders that are signed using the new 2023 trust chain.

PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Microsoft UEFI CA 2023'


Checks whether the Microsoft Corporation KEK 2K CA 2023 certificate is present in the active Key Exchange Key (KEK) database. The KEK database sits above the DB and DBX databases in the Secure Boot trust hierarchy and authorizes future updates to the allowed and forbidden signature databases. The presence of this certificate indicates that the system is prepared to receive and trust future Secure Boot database updates signed with the new 2023 key.

PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'


Checks whether the Microsoft Option ROM UEFI CA 2023 certificate has already been deployed to the active Secure Boot database (DB).

PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Microsoft Option ROM UEFI CA 2023'
False


For a more detailed inspection of the Secure Boot certificate databases, we can install and use the PowerShell UEFIv2 module if not already done as shown in the above Background section. This module provides additional cmdlets that allow us to enumerate and examine the certificates stored in the active and default Secure Boot databases.

The active Secure Boot database (db) contains the certificates currently used by the firmware to validate trusted boot components during system startup. It is the live, active database currently stored in your NVRAM that the system uses during boot to validate bootloaders.

The default Secure Boot database (dbdefault) represents the firmware’s baseline certificate store and may already contain newer certificates that have been staged for a future activation but are not yet actively used during the boot process. It represents the original, hardcoded list of trusted certificates provided by your hardware vendor (in this case, VMware) or a recent firmware update. Your firmware wants to trust these.

PS> Install-Module -Name UEFIv2
PS> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
PS> Import-Module -Name UEFIv2



The following command shows the certificates currently present in the active Secure Boot allowed signature database (DB), which is used by the firmware during every system boot to validate trusted boot components.

In this example, only the original Microsoft 2011 certificates and the VMware Secure Boot signing certificates are present, indicating that the new Microsoft 2023 Secure Boot certificates have not yet been activated in the active Secure Boot database.

PS> (Get-UEFISecureBootCerts db).signature


The following command displays all certificates stored in the Secure Boot default allowed signature database (dbdefault).

Unlike the active db database, the dbdefault database already contains the new Microsoft 2023 Secure Boot certificates.

This indicates that the updated trust anchors have been staged in the firmware but have not yet been activated in the active Secure Boot database, which means the system is still booting exclusively with the original 2011 certificate chain.

This usually happens because a BIOS/firmware update added the new 2023 certificates to the hardware’s fallback profile (dbdefault), but it didn’t automatically overwrite your active NVRAM settings (db) to avoid disrupting your current boot setup.

PS> (Get-UEFISecureBootCerts dbdefault).signature


In addition to checking the individual Secure Boot certificates, Windows also maintains several registry values that provide insight into the current state of the Secure Boot certificate migration. These values can be viewed by querying the following registry key:

PS>  Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


WindowsUEFICA2023Capable
Indicates whether the system is capable of using the new Windows UEFI CA 2023 trust chain. A value of 0 means the Windows UEFI CA 2023 certificate is not present in the active Secure Boot database (DB). A value of 1 indicates that the certificate is present, while a value of 2 confirms that the system is booting from a Windows Boot Manager signed with the Windows UEFI CA 2023 certificate.

UEFICA2023Status
Represents Microsoft’s overall deployment status for the Secure Boot certificate migration. Depending on the deployment stage, values such as NotStarted, InProgress, or Updated may be reported. Microsoft recommends using this value as the primary indicator when assessing the status of the Secure Boot certificate update process. A value of Updated indicates that the Secure Boot certificate transition has completed successfully and the system has been migrated to the new 2023 trust chain.

ConfidenceLevel
Provides Microsoft’s confidence assessment regarding the readiness of the system for the Secure Boot certificate migration. During the rollout process, values such as Under Observation - More Data Needed may be displayed while Microsoft continues to evaluate device telemetry. Once sufficient validation data has been collected, a higher confidence level may be reported. A value of High Confidence indicates that Microsoft has positively validated the migration state based on the system’s Secure Boot configuration and telemetry data.


In the example shown below, the values WindowsUEFICA2023Capable = 2, UEFICA2023Status = Updated, and ConfidenceLevel = High Confidence indicate a successfully completed Secure Boot certificate migration. The system is booting from a Windows UEFI CA 2023-signed Boot Manager and all required Secure Boot certificates have been deployed successfully.

Activating the 2K23 Certificates: Updating the UEFI NVRAM and Boot Manager Database

If our status check revealed that the 2023 certificates are present in dbdefault but missing from our active db, your next step is to commit them to the live database.

Bringing our active Secure Boot environment up to date requires pulling those newer keys out of the firmware’s storage and writing them directly into our system’s NVRAM.


While some guides suggest manually adding the AvailableUpdates registry key, this is unnecessary on modern Windows systems.

The built-in Scheduled Task shown below is perfectly capable of detecting the update requirements. If the update isn’t applying, the problem is almost always the Firmware Trust Anchor (PK) rather than a missing registry flag or Windows update. As we will see later in this post, this was exactly the case for a VMware vSphere virtual machine, where an invalid Platform Key configuration prevented the Secure Boot certificate migration from completing successfully.


If not we can run each of the following commands separately from an administrator PowerShell prompt:

The command initiates the certificate and boot manager deployment on the device.

PS> reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f


The command causes the task that processes the AvailableUpdates registry key to run right away. Normally the task runs every 12 hours.

PS> Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"


Verify the state:

The Get-WinEvent command can be used to review Secure Boot-related events and identify issues that prevent the complete deployment of the new 2023 Secure Boot certificates.

PS> reg query HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
PS> Get-ScheduledTaskInfo -TaskName "Secure-Boot-Update" -TaskPath "\Microsoft\Windows\PI\"
PS> Get-WinEvent -LogName System | ? {$_.ProviderName -match "TPM-WMI|Secure-Boot"} | Select -First 20


After manually initiating the Microsoft Secure Boot update workflow, the Windows UEFI CA 2023 certificate was successfully added to the active Secure Boot database and the Windows Boot Manager was updated to a version signed with the new certificate chain.

However, subsequent update attempts generated Event ID 1796 (“The parameter is incorrect”), suggesting that additional Secure Boot variable updates may not be fully supported by the VMware virtual firmware implementation. The system nevertheless progressed through the most critical migration steps successfully.

On this VMware VM, the Microsoft update task successfully added Windows UEFI CA 2023 to the active DB and updated Boot Manager, but Microsoft UEFI CA 2023 remained only in dbdefault, while later Secure Boot variable updates failed with Event ID 1796.

PS> (Get-UEFISecureBootCerts db).signature
PS> (Get-UEFISecureBootCerts dbdefault).signature


Now after running the Secure Boot update workflow the Windows UEFI CA 2023 certificate state is → WindowsUEFICA2023Capable : 1

The WindowsUEFICA2023Capable : 1 value indicates that the Windows Servicing Stack has detected a firmware environment that is physically capable of supporting the 2023 certificates but is currently blocked from applying them.

In my case this is a VMware VM, this specifically signaled that while the virtual hardware was compatible, the lack of a valid Platform Key (PK) prevented the OS from having the “write permissions” needed to advance the status to the next stage. We will see in the next section below how to solve this and finally have the state WindowsUEFICA2023Capable : 2.

  • 0 → Windows UEFI CA 2023 certificate not present in the active DB
  • 1 → Windows UEFI CA 2023 certificate present in the active DB
  • 2 → Windows UEFI CA 2023 certificate present and system booting from a Windows UEFI CA 2023-signed Boot Manager


PS> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


More about here https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Secure Boot Certificate Updates on VMware vSphere

As documented by Broadcom, virtual machines created on ESXi versions earlier than 9.0 may use a Platform Key (PK) configured with a NULL signature.

Because the Platform Key represents the root of trust within the Secure Boot hierarchy, it cannot authorize updates to the Key Exchange Key (KEK) database. As a result, the subsequent KEK, DB, and DBX certificate updates required for Microsoft’s Secure Boot certificate migration cannot be completed successfully until the Platform Key is updated.


The VMware virtual machines stuck at UEFICA2023Status in state InProgress and for the KEKLastUpdateErrorReason we see Firmware_MissingKEKInPackage as shown below.

PS> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


Before applying the VMware-specific EFI certificate update, the Secure Boot update process may generate several warning and error events in the Windows System log.

The following command can be used to review Secure Boot-related events and identify issues that prevent the complete deployment of the new 2023 Secure Boot certificates.

PS> Get-WinEvent -LogName System | ? {$_.ProviderName -match "TPM-WMI|Secure-Boot"} | Select -First 20


We can identify the virtual machines with missing or NULL Platform Key by running the following PowerShell commands in an elevated prompt:

$pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der


The Platform Key (PK) needs to be updated if the above command fails with an error like Cannot index into a null array or the certutil command (shown above) will show the result as “00” , which both means the Certificate is Invalid and we need to replace and update.


Or we can also use the UEFIv2 PowerShell module if installed and shown already further above.

PS> (Get-UEFISecureBootCerts pk).signature


Later after applying this workaround it will looks like here:


Or here when using the separate PowerShell commands it will looks like here:


To solve this issue for secure boot enabled Windows VMs they have vTPM disabled I will manually update the Secure Boot Platform Key for the virtual machines.

More about you will find here https://knowledge.broadcom.com/external/article/423919.


Therefore we first need to prepare a disk for the platform key update.

  • Add a 128-MB virtual disk to the virtual machine.
  • Format the disk as FAT32.
  • Download the required certificate from Microsoft – Platform Key (PK) – WindowsOEMDevicesPK.der
  • Copy the certificate to the newly partitioned volume with 128MB size.


To manually update the Secure Boot Platform Key for the virtual machines first shutdown the virtual machine and to be safe take a snapshot.

Then attach the disk containing the Microsoft PK.

To be able to edit the EFI Secure Boot Configuration we first need to add the following advanced configuration paramers.

Edit Settings >  Advanced Parameters 

Add new option: uefi.allowAuthBypass = "TRUE"


We also need to force the VM to enter Setup Mode.


Power on the VM.

Because of uefi.allowAuthBypass = "TRUE" we set previously we now have a further menu item with Secure Boot Configuration.

Navigate to Enter Setup > Secure Boot Configuration > PK Options > Enroll PK


> PK Options > Enroll PK


> Enroll PK


Select Enroll PK Using File.


Select the disk you have attached with the Platform Key (PK). We finally we will see the volume name with PK I was using previously.


Select the PK file.


Commit changes and exit.


Shut down the system.


After the update, remove the VMX entry: uefi.allowAuthBypass = "TRUE"


Also remove the disk with the Platform Key (PK) from the VM.


Power on the virtual machine.

After completing the update and rebooting the virtual machine, verify that the Platform Key is updated successfully by executing the commands below.

$pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der


PS> (Get-UEFISecureBootCerts KEK).signature | Select-Object Thumbprint, Subject


Looks good now and we can trigger the Final Handshake.

Force the scheduled task to run now that it actually has permission to succeed:

PS> Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"


Check your registry one last time. The InProgress status should finally be gone:

PS> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing | Select-Object UEFICA2023Status
PS> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing


The verification of a successful 2023 Secure Boot migration isn’t just a registry key, it’s the presence of the actual certificate strings within the UEFI variables.

Using PowerShell to scan the DB and KEK bytes for these specific 2023 identifiers confirms that the ‘handshake’ between the OS and the Firmware is complete. If all four strings return True, your system is fully prepared for the 2026 legacy certificate deprecation.”

PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Windows UEFI CA 2023'
PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Microsoft UEFI CA 2023'
PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
PS> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match 'Microsoft Option ROM UEFI CA 2023'


The previous Event ID 1803 errors (“A PK-signed Key Exchange Key (KEK) cannot be found for this device”) disappeared, and the System event log now reports successful deployment of the Secure Boot updates, including Event ID 1043 (“Secure Boot KEK update applied successfully”) and Event ID 1808, confirming that the device has updated Secure Boot certificates and keys.

PS> Get-WinEvent -LogName System | ? {$_.ProviderName -match "TPM-WMI|Secure-Boot"} | Select -First 20


So if you are running on VMware ESXi 8.0.x and still see InProgress after a reboot, don’t keep running the scheduled task.

Check your Platform Key (PK). If it’s a NULL or legacy key, the firmware will silently block the update.


Use the Broadcom KB 423893 method to manually enroll the Microsoft 2023 PK. Once that anchor is set, the rest of the certificates will fall into place automatically.

Links

How To Check Secure Boot Certificates
https://www.dell.com/support/kbdoc/en-us/000385747/how-to-check-secure-boot-certificates

Secure Boot Certificate updates: Guidance for IT professionals and organizations
https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f#bkmk_how_updates_are_deployed

Registry key updates for Secure Boot: Windows devices with IT-managed updates
https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Updating Windows Boot Manager and WinPE with the Windows UEFI CA 2023 Certificate
https://lenovopress.lenovo.com/lp2353-updating-windows-boot-manager-and-winpe-windows-uefi-ca-2023-certificate

Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines
https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.htm

Manual Update of the Secure Boot Platform Key in Virtual Machines
https://knowledge.broadcom.com/external/article/423919

Act now: Secure Boot certificates expire in June 2026
https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856

Windows Secure Boot certificate expiration and CA updates
https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e

Windows Secure Boot Key Creation and Management Guidance
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11