Microsoft is about to make a significant upgrade to its Secure Boot system, and if enterprise customers have not gotten started on the upgrade, they are already behind.

Secure Boot is a Windows subsystem that verifies that each driver is signed by a trusted certificate on startup. If something doesn’t match, it gets blocked. For enterprise networking customers, Microsoft Secure Boot enhancements are important because the system defends against firmware-level attacks, bootkits, ransomware, and protect device integrity.

Secure Boot is a part of the UEFI firmware standard, which replaced the older BIOS model for modern PCs. It was added to UEFI in 2011 so only trusted, signed code could run during startup.

Microsoft has not updated the certificates to Secure Boot since it was first introduced 15 years ago. Every PC manufactured since 2012 running Windows 10, Windows 11, or the last four versions of Windows Server (2016/2019/2022/2025) has been relying on certificates from 2011.

Starting on June 27 through October, those certificates begin expiring. When these certificates expire, desktops and servers keep working, but the computer loses the ability to receive security updates for the boot process. For example:

• New protections for Windows Boot Manager won’t install.
• Updates to the Secure Boot database won’t apply.
• Revocation lists that block known malicious software won’t update.
• The system gradually loses the ability to defend itself.

For desktops, the solution is basically a Windows Update and a new UEFI firmware upgrade. Two updates do the trick. With Windows Server, the process is far more complex.

Windows Server follows a completely different update process. Whereas Windows desktop PC upgrades are almost fully automatic, Windows Server requires manual intervention. IT administrators must validate and manually roll out the certificate updates across their server infrastructure.

Microsoft’s documentation for Windows Server administrators runs dozens of pages. It involves PowerShell commands, registry key checks, firmware validation, pilot deployments, and careful monitoring for enterprises with thousands of servers.

Some devices have fundamental limitations in their hardware or firmware that prevent them from receiving the automated certificate updates. These aren’t theoretical cases. Microsoft’s own documentation acknowledges them.

Administrators will need to inventory which Windows Server systems use Secure Boot and verify the certificates are already present. Some of the newest servers contain updated certificates, but they are very recent releases. Microsoft recommends keeping servers fully patched, then applying the certificate update path for any in-scope device that still relies on the older 2011 chain.

For managed environments, the safest approach is to validate physical servers, cluster nodes, and server VMs separately, since images and firmware update behavior can differ across platforms.

For computers that are no longer being serviced or updated, or their manufacturer has gone out of business, the problem is worse and the only possible solution is replacement. Obsolescence is a way of life and technology, after all.

Microsoft is not doing this by itself. It is getting complete cooperation and coordination with the major hardware OEMs, like HPE, Dell, Lenovo, and other major PC manufacturers. The OEMs have taken it upon themselves to release new firmware updates specifically to ensure that systems can accept the new certificates.

Here are links to resources from Microsoft regarding the certificate upgrade:

• aka.ms/getsecureboot is the canonical landing page that Microsoft is keeping current with all guidance and KB articles.
• Secure Boot Playbook for client and Windows Server Secure Boot Playbook for server.
• Secure Boot status report in Windows Autopatch for fleet-scale monitoring at no additional cost for Autopatch customers.