Microsoft’s 15‑Year‑Old Secure Boot Time Bomb Just Exploded In VSphere 8 – Here’s How To Survive June 2026 + Video

Introduction:

A digital time bomb quietly buried inside every Windows VM running on VMware ESXi is about to detonate. As of June 2026, Microsoft’s original 2011 Secure Boot signing certificates are beginning to expire – and if you run Secure Boot‑enabled virtual machines on vSphere 8.x, your infrastructure is already in the crosshairs. This is not a theoretical vulnerability; it is a live, operational crisis where Windows Update repeatedly fails to apply critical certificate updates, logging Event ID 1801 errors while VMs remain stuck in a degraded security state. The missing Platform Key (PK) in ESXi virtual firmware effectively blocks the authorization chain needed to rotate the Key Exchange Key (KEK) and Signature Database (DB) – meaning affected systems will progressively lose the ability to receive future boot‑chain protections and revocation updates. This article delivers a complete, battle‑tested remediation playbook for vSphere administrators, covering VMware’s official fixes, manual NVRAM resets, PowerShell verification scripts, and the critical distinction between “still boots” and “still secure.”

Learning Objectives:

Understand the Secure Boot certificate expiration timeline and its impact on ESXi‑hosted Windows VMs.
Identify affected virtual machines using Event ID 1801, registry keys, and PowerShell validation commands.
Execute VMware’s recommended remediation paths – including ESXi upgrades, manual NVRAM key resets, and scheduled task triggers.
Apply verified Linux/Windows commands to audit, force‑update, and verify Secure Boot certificate transitions.
Implement proactive monitoring and automation strategies to prevent future trust‑chain failures.

You Should Know:

The PK/KEK/DB Trust Chain – Why Your VMs Are Stuck in a Loop

UEFI Secure Boot operates on a firmware‑enforced PKI hierarchy stored in authenticated UEFI variables:

PK (Platform Key): Defines platform ownership – who is authorised to change Secure Boot configuration. On ESXi VMs created before vSphere 9.0, VMware configures the PK with a NULL signature by default.
KEK (Key Exchange Key): Authorises updates to the DB and DBX databases.
DB (Signature Database): An allowlist of trusted signers and hashes for EFI components (bootloaders, EFI applications).
DBX (Forbidden Signature Database): A denylist of revoked or known‑vulnerable signers.

When a Windows VM with Secure Boot enabled attempts to apply Microsoft’s 2023 certificate updates, the update orchestrator (the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update) runs through a sequence: DB updates → optional DB additions → KEK update → boot manager replacement. However, because the virtual firmware lacks a valid, signed PK, Windows Update is not authorised to modify the KEK or the DB. The result is a failure loop: the guest OS repeatedly tries to apply the update, logs Event ID 1801, and never completes the transition.

Critical distinction: The VM will continue to boot – certificate expiration does not automatically invalidate firmware‑stored trust anchors. But an expired KEK certificate impacts the ability to update Secure Boot databases, meaning future DBX revocation updates (e.g., protections against BlackLotus, BootHole, or next‑generation bootkits) will never be applied. Your VM remains “functional” but outside the current security baseline – a frozen trust state that attackers will eagerly exploit.

Identifying Affected VMs – Audit Commands for Windows and ESXi

Before applying any fixes, you must identify which VMs are stuck in the failure loop. Run these verification steps inside each Windows guest with administrative privileges:

Check Secure Boot status:

Confirm-SecureBootUEFI

A return value of `True` confirms Secure Boot is enabled.

Query the servicing registry status:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" | Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent

– `UEFICA2023Status = NotStarted` or `InProgress` that never completes indicates a stuck update.
– A non‑zero `UEFICA2023Error` value points to the specific failure cause.

Pull Secure Boot servicing events (including Event ID 1801):

$ids = 1032,1034,1036,1043,1044,1045,1795,1796,1799,1800,1801,1802,1803,1808
Get-WinEvent -FilterHashtable @{LogName='System'; Id=$ids} -MaxEvents 200 | Sort-Object TimeCreated -Descending | Format-Table TimeCreated, Id, Message -AutoSize

This retrieves all relevant Secure Boot certificate servicing events. Event ID 1801 specifically indicates that “Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware”.

Verify whether the 2023 certificates are present in firmware variables:

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

Check DB for Windows UEFI CA 2023
([Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023')

Check DB for Microsoft UEFI CA 2023
([Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft UEFI CA 2023')

Check DB for Microsoft Option ROM UEFI CA 2023
([Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft Option ROM UEFI CA 2023')

Each command returns `True` if the respective 2023 certificate is already enrolled. If any return False, the transition is incomplete.

Check the scheduled task health:

Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' | Select-Object TaskName, State, Enabled
Get-ScheduledTaskInfo -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'

On the ESXi host side, you can also identify VMs with NULL PK signatures by reviewing the VM’s `.nvram` file or using PowerCLI to query the Secure Boot configuration. For large‑scale audits, VMware’s PowerCLI script (available in the vSphere 8.0 U3j release) can enumerate affected VMs across your cluster.

The VMware Remediation Path – ESXi Upgrade and Automated PK Fix

Broadcom released vSphere 8.0 U3j (P09) specifically to address this Secure Boot Platform Key management gap. This update introduces automated PK remediation during VM reboot for vTPM‑disabled virtual machines.

Step‑by‑step upgrade procedure:

Upgrade vCenter Server to the latest version compatible with ESXi 8.0 U3j.
Upgrade each ESXi host to 8.0 U3j (or later) using the VMware Lifecycle Manager or esxcli:
```
esxcli software profile update -p ESXi-8.0U3j-<build>-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
```
(Replace `` with the actual build number from the Broadcom release notes.)
For vTPM‑disabled VMs: After the host upgrade, simply reboot the affected Windows VM. ESXi 8.0 U3j will automatically remediate the NULL PK signature during the reboot sequence, allowing the Windows Secure‑Boot‑Update scheduled task to complete successfully on the next run.
For vTPM‑enabled VMs: Critical caveat – there are no automated remediation methods available at this time for vTPM‑enabled Windows VMs. Broadcom Engineering is actively working with Microsoft on a future release to address this. For now, vTPM‑enabled VMs require the manual NVRAM reset procedure (see Section 4 below).

Verification after upgrade:

Inside the Windows guest, re‑run the registry query and certificate presence checks. A successful transition will show:
– `UEFICA2023Status = Updated`
– `UEFICA2023Error = 0`
– All four certificate presence checks return True.

Manual NVRAM Reset – The Last‑Resort Fix for Stuck or vTPM‑Enabled VMs

For existing VMs already throwing Event ID 1801 errors – especially those with vTPM enabled – you must force the virtual NVRAM to regenerate its factory keys. Warning: Altering Secure Boot variables will trigger BitLocker recovery mode if a vTPM is active. Back up your BitLocker recovery keys and vTPM state before proceeding.

Step‑by‑step manual reset procedure:

Shut down the VM gracefully from within the guest OS.
In vSphere Client, navigate to Edit Settings > VM Options > Boot Options.
Check the box for Force EFI setup (this forces the VM to enter the UEFI firmware setup menu on next power‑on).
Power on the VM and open the console.
Navigate to Device Manager > Secure Boot Configuration.
Select Delete all Secure Boot Keys, then immediately select Enroll all Factory Default Keys (or Reset to Factory Defaults).
Save and exit the firmware setup. The VM will continue booting into Windows.
Once Windows loads, open an elevated PowerShell prompt and force the Secure‑Boot‑Update task to run immediately:
```
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
```
Reboot the virtual machine twice – the first reboot applies the firmware changes, the second seals the new certificates into the UEFI variables.
After the second reboot, re‑run the verification commands from Section 2 to confirm `UEFICA2023Status = Updated` and all 2023 certificates are present.

Alternative method using registry trigger (if the scheduled task does not start automatically):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Secureboot" /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

The `0x5944` value manually signals Windows that Secure Boot updates are available and pending.

For vSphere 7.x environments (where ESXi 8.0 U3j is not available), the same manual NVRAM reset procedure applies, but you may also need to manually download and stage the Microsoft 2023 KEK certificate:
– Download the Microsoft CA 2023 KEK from: https://go.microsoft.com/fwlink/?linkid=2239775
– Add a temporary 128 MB FAT32 disk to the VM, copy the certificate files, and use the UEFI firmware setup to manually enroll them.
– Add the advanced parameter `uefi.allowAuthBypass TRUE` to the VM’s configuration to permit the enrollment.

5. Automation and Large‑Scale Deployment – PowerCLI Script

For organisations managing hundreds or thousands of VMs, manual intervention is not feasible. VMware and third‑party contributors have developed PowerCLI automation scripts that orchestrate the remediation across your entire fleet.

Typical PowerCLI automation workflow:

Triggers update tasks inside each Windows guest using Invoke-VMScript to run the `Start-ScheduledTask` and registry commands remotely.
Shuts down the VM, takes a fallback snapshot, and refreshes the `.nvram` file to reset the virtual firmware.
Performs a 3‑cycle sequential reboot to seal the new certificates into the firmware.
Validates the final status by reading the `UEFICA2023Status` registry value from each VM.
Generates a CSV report on the desktop listing each VM’s final Secure Boot certificate status.

Prerequisite: The script requires Local or Domain Administrator credentials for the target VMs to execute commands inside the OS via vCenter.

Example PowerCLI snippet to check PK status across all VMs:

Get-VM | Where-Object { $<em>.ExtensionData.Config.BootOptions.EfiSecureBootEnabled } | ForEach-Object {
$vm = $</em>
$nvram = $vm.ExtensionData.Config.Files.NvramPath
 Additional logic to parse .nvram or query guest registry via Invoke-VMScript
Write-Host "VM: $($vm.Name) - Secure Boot Enabled"
}

For the full script, refer to the VMware community resources or the download link provided in the original post: https://drive.d724cloud.com/index.php/s/bzXnTDbCiTKrkcg.

6. Linux Hosts and Cross‑Platform Considerations

While this article focuses on Windows VMs, the Secure Boot certificate expiration also affects Linux guests that rely on the Microsoft UEFI CA 2011 for signing shim bootloaders. The 2011 certificate that signs Linux shim and third‑party option ROMs expires in June 2026 as well.

For Linux VMs on ESXi with Secure Boot enabled:

Ensure your Linux distribution has updated its shim package to use the new Microsoft UEFI CA 2023 certificate.
On Red Hat / Fedora / CentOS:
```
dnf update shim-x64
```
On Ubuntu / Debian:
```
apt update && apt install shim-signed
```
After updating the shim, reboot the VM and verify the new certificate is enrolled:
```
mokutil --db
```
Look for “Microsoft UEFI CA 2023” in the output.
If the VM is stuck with the old certificate, you may need to use the same manual NVRAM reset procedure (Section 4) or use `mokutil` to manually enroll the new KEK and DB certificates from within the Linux firmware interface.

For ESXi hosts themselves (not just VMs), ensure your physical server firmware is updated to include the 2023 certificate chain. Dell, HP, and Lenovo have all published BIOS/UEFI updates that embed the new Microsoft certificates.

Proactive Monitoring – Keeping Your Fleet Secure Post‑Migration

Once you have successfully transitioned your VMs to the 2023 certificate chain, ongoing monitoring is essential to prevent future trust‑chain failures.

Implement a scheduled task (Windows) to regularly check Secure Boot status and alert on anomalies:

 Daily audit script – save as Check-SecureBootStatus.ps1
$status = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" -ErrorAction SilentlyContinue
if ($status.UEFICA2023Status -1e "Updated") {
 Log warning or send alert
Write-Warning "Secure Boot 2023 certificates not fully applied on $env:COMPUTERNAME"
 Optionally, trigger the update task again
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
}
 Check for Event ID 1801 in the last 24 hours
$events = Get-WinEvent -LogName System -MaxEvents 100 | Where-Object { $<em>.Id -eq 1801 -and $</em>.TimeCreated -gt (Get-Date).AddDays(-1) }
if ($events) {
Write-Warning "Event ID 1801 detected – Secure Boot update failure on $env:COMPUTERNAME"
}

Deploy this script as a scheduled task across all Windows VMs using Group Policy or your preferred configuration management tool.

On the ESXi side, use PowerCLI to periodically inventory all Secure Boot‑enabled VMs and verify their PK/KEK status:

Get-VM | Where-Object { $<em>.ExtensionData.Config.BootOptions.EfiSecureBootEnabled } | ForEach-Object {
 Use Invoke-VMScript to run the registry query remotely
$result = Invoke-VMScript -VM $</em> -ScriptText "Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object UEFICA2023Status" -GuestCredential $cred
Write-Host "$($_.Name): $($result.ScriptOutput)"
}

What Undercode Say:

Key Takeaway 1: The June 2026 Secure Boot certificate expiration is not a boot‑failure event – it is a security‑update‑failure event. VMs will keep running, but they will progressively lose the ability to receive critical boot‑chain protections and revocation updates. This creates a permanent, unpatched attack surface for bootkits and firmware‑level malware.
Key Takeaway 2: The root cause on ESXi 8.x is the NULL Platform Key (PK) configured by default on VMs created before vSphere 9.0. Without a valid signed PK, Windows Update cannot authorise KEK or DB updates, resulting in Event ID 1801 loops. VMware’s ESXi 8.0 U3j fixes this automatically for vTPM‑disabled VMs – but vTPM‑enabled VMs still require manual intervention.

Analysis (10‑line deep dive):

The Secure Boot 2026 transition represents a fundamental shift in how enterprise trust chains are managed. Unlike typical patch cycles, this is a firmware‑level PKI rotation that touches every Secure Boot‑enabled device in your fleet. The operational challenge is not technical complexity – the procedures are well documented – but rather the visibility gap: most organisations do not have real‑time inventory of which devices have successfully transitioned and which remain frozen on the 2011 trust anchors. The “it still boots” fallacy is dangerously misleading; a device that boots today may be completely unable to accept next year’s Boot Manager or DBX revocation updates, leaving it vulnerable to every known bootkit that Microsoft has ever revoked. For vSphere environments, the VMware‑specific NULL PK quirk adds another layer of friction – and the lack of automated remediation for vTPM‑enabled VMs is a glaring gap that Broadcom and Microsoft are still working to close. Administrators must treat this as a business‑critical governance project, not a one‑click fix. The window for safe remediation is closing rapidly – while the first certificates expire in June 2026, the transition window spans several months, and delaying action only increases the risk of last‑minute firefighting. Proactive auditing, automated scripting, and clear communication with business stakeholders are essential to avoid a scenario where “Secure Boot enabled” becomes a false sense of security rather than a genuine protection.

Prediction:

-1 Organisations that delay remediation will face a cascading series of security incidents starting in late 2026, as attackers increasingly target the frozen DBX state on untransitioned devices – bootkit campaigns that were previously blocked by revocation updates will suddenly succeed on these “still booting” but unpatched systems.
-1 The lack of automated remediation for vTPM‑enabled VMs in ESXi 8.x will create a significant operational bottleneck, forcing administrators to choose between manual NVRAM resets (with BitLocker recovery risks) or leaving critical VMs in a degraded security state until Broadcom releases a fix – potentially months after the first certificates expire.
+1 Forward‑thinking IT teams that implement the ESXi 8.0 U3j upgrade and deploy PowerCLI automation scripts will gain a competitive advantage in security posture, demonstrating proactive firmware‑level governance that exceeds standard compliance requirements.
+1 The Secure Boot 2026 transition will accelerate the adoption of hardware‑based root‑of‑trust technologies and firmware‑level monitoring solutions, as organisations realise that “Secure Boot enabled” is insufficient without continuous validation of the trust chain.
-1 Expect a surge in support tickets and emergency change requests as the June 2026 deadline approaches, with many organisations discovering that their “Secure Boot compliant” VMs have actually been stuck in a failure loop for months – Event ID 1801 will become the most‑dreaded error code of 2026.
+1 VMware’s collaboration with Microsoft on a future automated PK remediation for vTPM‑enabled VMs will set a precedent for faster, more integrated firmware‑update mechanisms across virtualisation platforms, reducing the operational burden of future certificate rotations.
-1 Organisations that rely solely on Windows Update to handle the transition (without proactive ESXi upgrades or manual verification) will experience the highest failure rates, as the NULL PK issue in ESXi 8.x effectively blocks the automated update path – a classic case of virtualisation‑layer friction breaking OS‑level automation.
+1 The PowerCLI automation scripts and community‑shared remediation playbooks will mature into essential tools for vSphere administrators, turning a potential crisis into a well‑managed, repeatable process that strengthens overall infrastructure resilience.

▶️ Related Video (72% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Charlescrampton Planned – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post