Microsoft has updated its guidance on Windows Secure Boot certificate expiration and CA updates. The key point is not that “the PC will stop booting when the certificate expires.” The real issue is that a set of Secure Boot certificates issued in 2011 will start expiring in June 2026, and Windows devices need to move to the new 2023 certificates to keep receiving future early-boot security protection updates.

Original article: Microsoft Support: Windows Secure Boot certificate expiration and CA updates.

What This Update Is About

Secure Boot is a security feature in UEFI firmware. Before the operating system starts, it verifies the signatures of bootloaders, UEFI drivers, Option ROMs, and other components, helping block bootkits, rootkits, and other early-boot malware.

This validation depends on several databases and keys stored in firmware:

• KEK: the key enrollment key, used to authorize updates to Secure Boot databases.
• DB: the allowed signature database, which decides which boot components can be trusted.
• DBX: the revoked signature database, used to block components that are known to be untrusted or risky.

Microsoft notes that a group of 2011 certificates used by Windows devices for many years is approaching expiration, and corresponding new certificates now exist in 2023 versions. These include the KEK certificate used to sign DB / DBX updates, the Windows UEFI CA used to sign Windows Boot Manager, and the UEFI CA used for third-party bootloaders, EFI applications, and Option ROMs.

Will It Affect Booting?

The question most users care about is: after the certificates expire in 2026, will the PC suddenly fail to boot?

Microsoft’s answer is fairly clear: devices that have not received the new 2023 certificates can still boot and run normally, and standard Windows updates will continue to install. The problem is that these devices will no longer be able to receive new protections related to the early boot process, such as Windows Boot Manager updates, Secure Boot database updates, revocation list updates, and mitigations for newly discovered boot-level vulnerabilities.

So this is more like an aging security chain than a simple “the system is immediately obsolete” problem. In the short term, the machine may keep working. In the long term, its protection against new bootkits, boot-chain vulnerabilities, and revoked components will decline.

What Ordinary Users Should Do

Ordinary users do not need to manually edit Secure Boot keys, and should not casually delete, reset, or import certificates in BIOS / UEFI.

The safer approach is:

1. Keep Windows Update enabled and install cumulative updates.
2. Install firmware, BIOS, UEFI, and driver updates from the PC manufacturer.
3. Do not keep Secure Boot disabled long term just to work around temporary compatibility issues.
4. If BitLocker is enabled, make sure the recovery key is available before firmware or Secure Boot changes.
5. Use msinfo32 to check “Secure Boot State” and confirm that Secure Boot is enabled.

For home PCs, the main risk is usually not “not knowing what to do,” but leaving firmware outdated for too long. Many Secure Boot-related changes on laptops and branded PCs ultimately still depend on OEM firmware support.

What Enterprise Admins Should Watch

In enterprise environments, the hard part is not one machine. It is the mix of device models, firmware versions, encryption policies, deployment tools, and third-party boot components.

Start with four things:

1. Inventory device models, Windows versions, Secure Boot state, firmware versions, and BitLocker state.
2. Test on representative models first, then expand deployment gradually.
3. Put Windows updates, OEM firmware updates, recovery key backup, and PXE / MDT / ConfigMgr / Intune workflows into one change plan.
4. Validate whether recovery media, imaging tools, third-party security software, and dual-boot bootloaders still boot normally.

Microsoft’s documentation also provides paths for IT-managed devices through registry settings, Group Policy, WinCS API, Intune, and monitoring examples. For enterprises, this certificate update should not be treated as an ordinary patch. It should be tested, rolled out in stages, and paired with rollback planning as a firmware-level change.

Dual-Boot and Third-Party Boot Tools Need Extra Care

If a device uses Linux dual boot, a third-party bootloader, custom-signed EFI applications, old recovery media, or offline deployment tools, this update deserves early validation.

The reason is that Microsoft has split parts of the original trust model more finely. For example, trust for third-party bootloaders and Option ROMs is no longer fully bundled together. This helps narrow the trust scope, but it also means older boot components, outdated shim / GRUB builds, old recovery media, or custom boot tools may be more likely to run into signature trust problems in the future.

The rule is simple: do not wait until after the certificates expire to discover that your recovery USB cannot boot either. Important machines should have a real recovery flow tested at least once in advance.

What Not to Do

This kind of issue looks like a “certificate expired” problem, so it is tempting to go into BIOS and manually change keys. Unless the vendor or Microsoft documentation clearly requires it, that is not recommended.

Do not leave Secure Boot disabled long term. Do not clear Secure Boot keys directly on production devices. Do not copy firmware settings from one device to a different model batch. And do not update Windows only, skip OEM firmware, and assume the issue is fully handled.

A better way to think about it is: Windows updates handle the operating system side, OEM firmware updates handle the platform side, and enterprise deployment policy handles consistency at scale. If any of the three is missing, the result may later become a hard-to-debug boot problem.

Summary

The real impact of this Windows Secure Boot certificate expiration is not that every PC suddenly stops booting on a single day in 2026. The real issue is that devices with old certificates will gradually lose the ability to receive future Secure Boot security updates.

Individual users should keep Windows and firmware updated and avoid casually disabling Secure Boot. Enterprise admins should start inventory, testing, and phased deployment as soon as possible. The closer it gets to June 2026, the less time remains for firmware compatibility testing, recovery flow validation, and bulk rollback planning.