Secure Boot 2023 Certificate Update: June 2026 Expiration and What IT Must Do

Microsoft’s Secure Boot ecosystem faces a pivotal transition as the original 2011 certificate authority approaches its June 2026 expiration. For millions of Windows devices, this deadline isn’t a distant abstraction—it’s a ticking clock that could render systems unbootable if ignored. The company has begun rolling out 2023 replacement certificates through Windows Update, targeting all supported UEFI-based systems, but the clock is ticking for IT administrators to understand and prepare for the change.

Secure Boot, a fundamental security feature of Unified Extensible Firmware Interface (UEFI), verifies the digital signature of bootloaders, drivers, and OS components before they execute. It relies on a chain of trust anchored by certificates embedded in the firmware. The original Microsoft Corporation UEFI CA certificate, signed by Microsoft’s own root, was minted in 2011 and set to expire on a date that has now been clarified as June 2026. Without proactive action, systems still trusting only that aging certificate could refuse to boot after the expiry, even with a valid Windows bootloader.

This is not a hypothetical scenario. The 2023 replacement certificate, already being deployed via KB5025885 and related updates, must be integrated into the Secure Boot database—both the ‘db’ (allowed signatures) and possibly the ‘KEK’ (Key Exchange Key)—to maintain boot integrity. Microsoft’s phased rollout strategy began with optional updates in early 2024, with broader automatic deployment scheduled throughout 2025. By early 2026, the update will become mandatory for all Windows 10 and Windows 11 systems, along with Windows Server versions that support UEFI Secure Boot.

The Certificate Expiration: What Really Happens

When the 2011 UEFI CA certificate expires on June 13, 2026, the firmware’s Secure Boot validation will fail for any boot component that chains up to that certificate—unless the firmware also trusts the new 2023 certificate. This includes Windows boot managers, third-party bootloaders signed by Microsoft, and even hypervisors. The impact varies by UEFI implementation: some firmware may simply unenforce the signature check, effectively disabling Secure Boot, while others may prevent boot entirely, displaying a “Secure Boot Violation” or similar error. In either case, the system is left in a less secure or unbootable state.

For IT departments managing fleets of devices, the worst-case scenario is a mass boot failure after a routine reboot. Systems that are offline for extended periods, or those with manual update policies, are particularly at risk. Embedded systems, IoT devices, and virtual machines with Secure Boot enabled also fall under this umbrella. The root issue is that Secure Boot certificate updates are not purely a software patch; they require firmware-level changes. Microsoft’s solution, delivered via Windows Update, is a UEFI revocation list and certificate update tool that modifies the Secure Boot variable store—but only if the firmware allows such modifications.

How Microsoft Is Delivering the New Certificates

The primary vehicle is a series of Windows Updates that deploy the Secure Boot Forbidden Signature Database (DBX) and inject the new Microsoft Corporation UEFI CA 2023 certificate into the DB. The update process involves several stages:

• Phase 1 (Post-February 2024): Optional updates (KB5025885) introduce the new certificate and update the DBX to block vulnerable boot managers. These updates require a special command-line step (schtasks.exe /Run /TN "\Microsoft\Windows\PI\SecureBoot-Update") to actually apply the Secure Boot database changes because the firmware modification is irreversible but reversible only via a firmware reset.
• Phase 2 (Mid-2025): The update becomes recommended via Windows Update, with a clearer nudge toward execution. IT admins can still defer via update management tools.
• Phase 3 (Early 2026): The update will be automatically applied to all eligible systems, ensuring the new certificate is trusted before the expiration deadline. After this phase, manually deferring will no longer be an option.

The distinction between the Windows update and the actual firmware modification is critical. Installing KB5025885 does not automatically update the Secure Boot variables. The final step requires a deliberate trigger—either via the scheduled task or by leveraging management tools like Microsoft Intune or Configuration Manager to execute the Secure Boot configuration update. Organizations that simply deploy the KB without the trigger remain vulnerable.

What IT Administrators Must Do Now

Waiting until 2026 is not a strategy. The preparatory work for a smooth transition should begin immediately. A step-by-step action plan includes:

1. Inventory UEFI-based systems: Identify all devices in the fleet that use Secure Boot. This includes Windows 10 (version 1909 and later), Windows 11, Windows Server 2016 and later, and even older systems that received UEFI firmware updates. Virtual machines under Hyper-V, VMware, and VirtualBox with Secure Boot enabled must be included.
2. Assess firmware readiness: Not all UEFI firmware can accommodate the 2023 certificate. Some older or niche devices may have locked-down firmware that doesn’t accept updates to the Secure Boot databases. Vendors like Dell, HP, and Lenovo are releasing firmware updates to ensure compatibility. Check with hardware manufacturers for specific guidance.
3. Pilot the update: Deploy KB5025885 (and its successors) to a representative sample of devices. Execute the Secure Boot database update using the scheduled task or scripted method. Verify that the system boots correctly and that Secure Boot remains enabled (check via msinfo32.exe or PowerShell’s Confirm-SecureBootUEFI).
4. Monitor revocation events: The DBX update also revokes older, vulnerable boot managers. This may block dual-boot Linux configurations or third-party recovery media. Ensure that any essential bootable utilities are signed with valid certificates chaining to the new CA.
5. Plan for offline and locked-down systems: For air-gapped or severely restricted systems, manual updates via bootable media or firmware configuration utilities may be necessary. Microsoft provides standalone tools, but they require physical access and firmware password clearance.
6. Communicate with software vendors: Any third-party driver, bootloader, or option ROM that chains to the old Microsoft UEFI CA must be updated. Vendors must obtain new signatures from Microsoft’s UEFI signing portal, which now uses the 2023 CA.

The Technical Nuances: DB, DBX, KEK, and PK

To fully grasp the update, a quick primer on Secure Boot’s key hierarchy is helpful. The Platform Key (PK) is the top-level trust anchor, usually owned by the hardware vendor. The Key Exchange Key (KEK) sits below PK and allows authorized entities (like Microsoft) to update the db and dbx without changing PK. The db (signature database) contains certificates and hashes of allowed boot components. The dbx (forbidden signature database) lists revoked components.

Microsoft’s update primarily targets db and dbx. It pushes the 2023 CA into db, ensuring future bootloaders signed by it are trusted. Simultaneously, it adds older boot managers (like those from the BootHole vulnerability era) to dbx, enforcing stricter security. However, some firmware implementations require the 2023 certificate to also be present in KEK to validate updates to db. Microsoft has addressed this by ensuring the update process, when triggered, properly inserts the certificate where needed, but variances in firmware mean some systems may still need a vendor-provided BIOS update.

Virtual Machines and Secure Boot

Virtualized environments add another layer. Hypervisors like Hyper-V, VMware ESXi, and KVM/QEMU emulate UEFI firmware. When a VM’s Secure Boot is enabled, it must trust the 2023 certificate. For Hyper-V on Windows, the update process described above covers both the host and guest VMs, assuming the guest is a supported Windows OS. However, for Linux VMs or third-party hypervisors, admins may need to manually enroll the 2023 certificate into the VM’s NVRAM store. Tools like ‘mokutil’ on Linux can manage Machine Owner Keys (MOK) to add the Microsoft CA.

Potential Pitfalls and Breaking Changes

Several scenarios can lead to boot failures even after applying the update:

• Dual-boot with Linux using shim: Many Linux distributions rely on a pre-bootloader called shim signed by Microsoft’s old CA. If shim is not updated to a version signed by the 2023 CA, it will be rejected after the DBX update or certificate expiry. Distributions must release updated shim packages.
• Custom Windows PE environments: IT departments often use custom WinPE images for deployment and recovery. These must be re-signed or rebuilt using the latest Windows ADK which includes boot files signed by the new CA.
• Firmware restrictions: Some UEFI implementations, especially on older motherboards, do not allow the OS to modify db or KEK, regardless of the scheduled task. These systems are locked into the old certificate and will require a full firmware flash from the manufacturer—if available.
• BitLocker complications: The Secure Boot database update can trip BitLocker’s integrity checks. The expected behavior is a BitLocker recovery prompt after the database change because the PCR (Platform Configuration Register) values change. The system should boot normally after entering the recovery key, and subsequent boots will not prompt again. However, if the recovery key is unknown, data access may be lost. Ensure BitLocker recovery keys are escrowed in Active Directory or Azure AD before applying the update.

Timeline and Deadlines: A Recap

IT teams should treat the mid-2025 milestone as the latest starting point for broad enterprise deployment, with completion by Q1 2026 to leave ample buffer for recovery.

Beyond Windows: The Wider Ecosystem Impact

The 2026 expiry doesn’t only affect Windows. Any operating system or hypervisor that relies on the Microsoft UEFI CA for signing boot components faces the same cliff. Linux distributions using the Microsoft-signed shim are actively updating their packages. FreeBSD and other niche OSes that signed their bootloaders with Microsoft’s third-party UEFI signing service must re-submit for signatures with the 2023 CA. Hardware vendors producing option ROMs for network boot (PXE) or storage controllers must ensure their firmware is re-signed.

This certificate change is also a reminder that the UEFI Secure Boot infrastructure, designed to combat bootkits, requires ongoing maintenance. The 2011 CA was created when UEFI was nascent; the 2023 CA incorporates stronger cryptographic parameters (e.g., larger key sizes) and aligns with modern security standards. However, the industry still lacks a seamless, automated mechanism for rotating platform trust anchors, leaving a messy chore for system administrators.

Looking Forward: Lessons and Reforms

Microsoft’s handling of the transition, while methodical, has drawn criticism for its opacity. The original timeline was communicated via a support article (KB5025885) and Tech Community posts, but many organizations remained unaware until echoes in the press. A more proactive notification system would have helped. Furthermore, the reliance on manual steps or third-party management tools to finalize the firmware change is a friction point. Future certificate expirations could be eased with native UEFI capsule updates that don’t require OS-level triggers.

In the meantime, the June 2026 deadline is non-negotiable. The new 2023 certificates are already being distributed, and ignoring them is a recipe for a fleet-wide outage. For IT administrators, the immediate priority is to get the update into testing, understand their firmware landscape, and ensure all boot-chain components are compliant well before the clock runs out. With careful planning, the transition can be a non-event—but without it, it could be the kind of Friday afternoon crisis that no one wants.

Actionable takeaways:
- Start piloting KB5025885 and the Secure Boot trigger task now.
- Engage hardware vendors for BIOS updates supporting the 2023 CA.
- Audit all boot-critical software and media for signature currency.
- Prepare BitLocker recovery procedures.
- Set a firm completion date of March 2026 for your organization.

Secure Boot’s cage is sturdy, but only if the keys are current. Don’t let your fleet get locked out.