Secure Boot certificate changes and your recovery media: what physical servers need now

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Microsoft's original Secure Boot certificates from 2011 began expiring in June 2026. A Windows server that has not received the 2023 replacements still starts and still installs ordinary updates. But it can no longer receive new early-boot security fixes.

The bigger operational risk for recovery is a little different. Microsoft's related boot manager protections can stop older boot media from starting on a machine that has them applied. Those protections are permanent once applied. A server that has taken them will only start from recovery media built with recent boot files.

So check two things on each physical server: which certificates and protections it has, and whether your recovery media can still start it. This article explains both.

It draws on Microsoft's Secure Boot guidance, the boot manager revocation article KB5025885 and the event reference KB5016061. The commands are quoted from Microsoft and were not run for this article.

What Secure Boot does, briefly

Secure Boot is a feature of UEFI firmware. Microsoft describes it as checking the digital signature of pre-boot software against a set of trusted certificates stored in the device's firmware. If the boot loader is not signed by a trusted certificate, or appears on the forbidden list, the firmware will not run it.

The trust lives in a small set of firmware databases:

• Platform Key (PK). Usually owned by the hardware manufacturer. It controls changes to the KEK.
• Key Exchange Key (KEK), which Microsoft also calls the Key Enrollment Key. It authorises updates to the two signature databases.
• DB, the allowed signature database. Certificates whose signed boot software may run.
• DBX, the forbidden signature database. Certificates and hashes that must not run.

This matters for recovery because every recovery path on a UEFI server starts with firmware deciding whether to trust the boot loader. Windows installation media, a Windows Recovery Environment image, Windows PE, and a backup vendor's boot media all pass the same check.

What expired, and when

Microsoft's article KB5062710 lists the certificates and their expiry dates. It was originally published on 26 June 2025 and its table was last updated in May 2026.

Source: Windows Secure Boot certificate expiration and CA updates.

Microsoft's IT pro announcement lists the affected systems as physical and virtual machines on supported versions of Windows 10, Windows 11 and Windows Server 2012 through Windows Server 2025, including the long-term servicing channel.

What expiry does and does not do

Microsoft's FAQ is clear on the main question. Devices that have not received the 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. What they lose is the ability to receive new security protections for the early boot process. Those include updates to the Windows boot manager, the Secure Boot databases and revocation lists.

The FAQ also says the updates can still be applied after expiry. If the device can boot Windows and install updates, the updated certificates can be written to firmware by following Microsoft's deployment guidance. Some systems may need a firmware update first.

So an expired certificate on its own is not an outage. Our reading is that it becomes a recovery problem in two ways. First, through the boot manager protections described below. Second, through boot media signed only with the newer certificates, which an un-updated server will not trust.

The protections that affect boot media

A separate Microsoft programme, documented in KB5025885, protects against a Secure Boot bypass used by the BlackLotus UEFI bootkit (CVE-2023-24932). It overlaps with the certificate change because one of its steps untrusts every boot manager signed by the 2011 Windows certificate.

The mitigations are included in Windows security updates from 9 July 2024 but are not enabled by default. In outline, the steps are:

1. Update the DB to add the Windows UEFI CA 2023 certificate.
2. Install a boot manager signed with Windows UEFI CA 2023.
3. Add Windows Production PCA 2011 to the DBX. This untrusts every boot manager signed with the old certificate.
4. Apply a Secure Version Number (SVN) update to the firmware. The new boot manager compares its own SVN with the one stored in firmware and refuses to run if its number is lower.

Three statements in KB5025885 should shape any recovery plan.

It is permanent. Once the mitigation is applied, it cannot be reverted if you continue to use Secure Boot on that device. Even reformatting the disk will not remove the revocations. The revocations live in firmware, not on the disk. Restoring an older disk image does not undo them.

Existing media may not start. Microsoft warns that applying the revocation mitigations can make existing recovery or installation media unusable. Its current KB5025885 guidance also describes an SVN 5.0 compatibility issue on devices with April 2026 or later updates and PCA 2011 revocation enabled. Use the current media-update instructions and verify the resulting media on matching hardware; a remembered calendar cutoff is not a compatibility test.

Every SVN change means new media. Microsoft says that when a significant boot manager fix is released, the SVN will be incremented in both the boot manager and the firmware update, and each time the SVN is updated, any bootable media will need to be updated.

Microsoft has described an Enforcement Phase that will make the mitigations permanent, with the date to be announced. Check KB5025885 for its current status before planning around it.

Firmware resets and BitLocker

Two further risks belong in the recovery plan.

A firmware reset can leave the server unable to start. KB5025885 says that if a device has its Secure Boot settings reset to the defaults after the mitigations are applied, the device will not boot. Microsoft supplies a repair application, securebootrecovery.efi, with the July 2024 updates. Copied to a flash drive as the boot file, it reapplies the Windows UEFI CA 2023 certificate to the DB. On a physical server, a firmware reset can happen during motherboard replacement, a firmware recovery, or a technician restoring BIOS defaults. Our recommendation is to keep this repair drive with the server's recovery kit and to tell hardware engineers about it.

BitLocker may ask for its key. KB5025885 warns that some devices may go into BitLocker recovery and tells administrators to retain a copy of the recovery key before enabling the mitigations. It gives manage-bde -protectors -get %systemdrive% as the way to display the 48-digit recovery password. Microsoft's event reference also lists event 1032, logged when the Secure Boot update was not applied due to a known incompatibility with the current BitLocker configuration.

Checking a physical server

Microsoft's guidance gives event IDs and PowerShell checks. The events are logged in the System log with the source TPM-WMI. The KB5016061 event reference includes:

KB5025885 also gives two PowerShell tests, run as Administrator, that read the firmware databases:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'

The first returns True when the new Windows certificate is trusted. The second returns True when the old Windows certificate has been revoked. Following Microsoft’s event 1037 description, a server for which the second test is True will not start media built on boot managers signed only with the 2011 certificate.

Record the results for each physical server with its model and firmware version. That record tells you which recovery media each machine can use.

For TPM 2.0-based Windows Server 2012 and 2012 R2 systems, KB5025885 records a TPM-measurement compatibility block on the July 2024 and later mitigations. It says Windows updates released on and after 8 April 2026 address that issue. Check the installed update and current known-issues entry before applying the broader guidance to these older systems.

Firmware first

Microsoft's IT pro post tells administrators to check with OEMs for the latest firmware and apply it before applying the new certificates. It describes OEM firmware updates as the foundation for Windows Secure Boot updates to apply correctly. KB5025885 says Microsoft has seen devices that fail the updates, and recommends testing on one device per device class before deploying widely. Event 1795 is the sign of a firmware refusal.

For servers, the device class is usually the model plus firmware version. One test server per model is a reasonable unit.

Keeping recovery media working

The practical rule from KB5025885 is that recovery media must be built from current boot files. Microsoft describes two ways to do this:

• Windows client recovery drive. The desktop Recovery Drive applet is not a general Windows Server recovery-media procedure. Where that client tool applies, on a device where the latest security update and the DB update have been applied, use the "Create a Recovery Drive" applet.
• Updated installation media. If you maintain installation media with Microsoft's Dynamic Update guidance, follow the KB5025885 steps to produce a flash drive with boot files signed by Windows UEFI CA 2023.

For physical servers, our recommendations, which are editorial rather than Microsoft's, are:

1. Inventory every boot medium you rely on for recovery. Windows installation media, custom WinRE or Windows PE images, hardware vendor tools, and backup vendor boot media.
2. Record what each is signed with and when it was built. Ask each third-party supplier which Microsoft certificate their boot loader chains to, and whether they publish media for the 2023 certificates.
3. Test each medium on a non-production server of each model, in the same Secure Boot state as production. Start it and stop at the first screen that proves it loaded.
4. Rebuild media after each SVN change, as Microsoft advises, and after major firmware changes.
5. Keep the Secure Boot repair drive alongside the recovery media, labelled with the date it was made.
6. Keep BitLocker recovery passwords retrievable before any Secure Boot change.

Disabling Secure Boot to start an old medium can look like a quick way out during an incident. Our view is that it is a security decision, not a recovery step. It changes the boot measurements BitLocker relies on, which can trigger a recovery prompt, and it removes the protection the mitigations were applied for. If your plan depends on it, make that decision ahead of time, with your security team, and write it down.

Record what the media test actually proved

Keep a small acceptance record for each server class: the machine model, firmware revision, Windows build, Secure Boot certificate and revocation state, media identifier, and date of the controlled test. Record who observed the boot and exactly where it stopped. This is our suggested evidence format, not a Microsoft certification scheme.

Reaching the recovery screen proves that this medium started on that tested configuration. It does not prove that storage drivers can see every required disk, that a backup repository is reachable, or that the restored application will work. Assign those checks their own acceptance criteria. If a firmware or boot-file change occurs later, review the earlier result before relying on it. Keep recovery passwords out of this nonsecret record; record the approved retrieval route instead.

Risks and limits

• Microsoft's guidance changes often. KB5025885 alone has many revisions, and the Enforcement Phase date has not been announced at the time of writing. Check the current text before acting.
• Hardware vendors implement Secure Boot firmware differently, and some fail key updates. Microsoft names specific vendor issues in KB5025885, including HP Sure Start and some Arm64 devices.
• The DBX revocation and SVN update are irreversible on a device that keeps Secure Boot enabled. Microsoft advises testing on one device per class before wider use.
• The behaviour of third-party boot media after the change depends on how it is signed. Confirm with each supplier.
• None of the commands here was run for this article.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates (KB5062710), table updated May 2026.
• Microsoft Support: Frequently asked questions about the Secure Boot update process.
• Microsoft Support: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 (KB5025885).
• Microsoft Support: Secure Boot DB and DBX variable update events (KB5016061).
• Microsoft Tech Community, Windows IT Pro Blog: Act now: Secure Boot certificates expire in June 2026.

This article was originally published on 13 November 2026.