Enterprise Preparation for the 2026 Microsoft Secure Boot Certificate Expiration

Back in 2023 with the release of CVE-2023-24932 (BlackLotus), the conversation around replacing Secure Boot certificates came to light. In the context of the CVE, it was to prevent use of signed and completely valid boot manager that could be exploited to bypass Secure Boot protections. Even without the CVE, those same certificates expire in mid-2026 – this year.

For the average consumer, Microsoft is managing the installation of replacement certificates. For enterprises with managed updates, we’re left to do it ourself. Neither instance addresses the revocation of the old certificates, which remains a manual step. Virtual machines add an additional complication with the KEK certificate – more on that below.

The guidance in this space has changed a few times over the last two years, but appears it may be settling down.

To that end, I’ve put together an automation script and released it onto my Github page that prompts the system to install the new certificates and revoke the old ones. For the enterprise environments that I manage, this handles the installation of the new Secure Boot certificates and the mitigation for BlackLotus. The script uses the published guidance from Microsoft to set and monitor registry keys across a few reboots to ensure the system completes the required changes.

Check it out here: Auto_MSUEFICA2023.ps1.

This script is intended to be run repeatedly and unattended. Once all actions are completed, the script does nothing as it’s able to check with the system firmware for the presence of the new certificates.

A Note Regarding Virtual Machines

Virtual Machines running both VMware vSphere and Microsoft Hyper-V appear to fail to install the updated KEK certificate. At this time, the official guidance from Broadcom for VMware 8.x environments is to power off the VM, upgrade the virtual hardware (8.0.2, so HWv21), and delete the NVRAM file for the VM from the datastore. This will reset Secure Boot certificate stores to defaults which contain the 2023 KEK certificate. A note that this resets multiple certificate stores, so the the installation of updated certificates has to be redone. I assume resolving the error in Hyper-V will be a similar process. While this does work, it’s not very enterprise friendly when scaling to 3000+ servers that are a mix of impacted.

A word of warning. Deleting the NVRAM file will reset the virtual TPM, if installed.

For VMware virtual machines, a script assisted method to replace the NVRAM files in bulk is detailed in another post.

References