Secure Boot Certificate Rollover — assessment and servicing

A single, self-contained PowerShell script that assesses a Windows machine's Secure Boot certificate posture for the 2011 → 2023 rollover (CVE-2023-24932 / KB5025885) and, only when you explicitly ask it to, opts that machine in to the Microsoft servicing pipeline.

Published by Exchange Technology Services for customers and partners who manage their own endpoints.

The short version

The Secure Boot certificates Microsoft issued in 2011 are expiring and being replaced by 2023 versions.

No machine stops booting on any of these dates. Microsoft's guidance is that a device reaching expiry without the new certificates "will still start and operate normally."

What is lost is the ability to receive early-boot security updates — new Secure Boot revocations, BitLocker bypass mitigations, boot-manager fixes. That is accumulating exposure rather than an outage.

After 19 Oct 2026, a machine whose firmware never took Windows UEFI CA 2023 also stops validating newly-signed Windows boot media, which can affect recovery, install and PXE media.

The KEK is the gate. Without Microsoft Corporation KEK 2K CA 2023 in firmware, Windows Update cannot deliver the DB update at all. A machine missing it cannot be remediated until the KEK arrives via Windows Update or an OEM BIOS update. This is the most common blocker in practice, and the script reports it explicitly rather than writing a value that would do nothing.

What this script does and does not do

Running it

Windows PowerShell 5.1, as Administrator — reading the UEFI variables requires elevation.

1. Unblock the file (Windows blocks downloaded scripts):

Unblock-File .\Invoke-SecureBootCertServicing.ps1

2. Assess — safe, makes no changes:

powershell.exe -ExecutionPolicy Bypass -File .\Invoke-SecureBootCertServicing.ps1

3. Apply, only if the assessment says the machine is ready:

.\Invoke-SecureBootCertServicing.ps1 -Apply -SuspendBitLocker

Capturing the output

The report is written with Write-Host, so it renders on the console and is recorded by Start-Transcript. A plain > redirect will not capture it, and neither will piping to another command.

Start-Transcript C:\Temp\secureboot.log
.\Invoke-SecureBootCertServicing.ps1
Stop-Transcript

For a machine-readable copy, useful when collecting results across a fleet:

.\Invoke-SecureBootCertServicing.ps1 -JsonPath C:\Temp\secureboot.json

Verdicts

Two axes, deliberately not merged

The report shows servicing state and migration state separately.

• Servicing state — what Microsoft's pipeline says it is doing.
• Migration state — what is actually true of the boot path.

These genuinely disagree in the field. A machine can report UEFICA2023Status = Updated while both boot-manager binaries on disk are still 2011-signed — that happens when the firmware shipped the 2023 CA pre-enrolled, so the certificate side completed while the boot-manager side never ran. Folding the two into one field reports that machine as finished when it is half-migrated.

For the same reason the script does not derive status from WindowsUEFICA2023Capable. Microsoft's documentation says of that value, verbatim: "For reference only - do not use this key when getting status on Secure Boot updates." It is captured as a diagnostic only.

BitLocker

The servicing steps change firmware state, which can move the TPM PCRs a BitLocker protector is sealed to, which can produce a recovery-key prompt at the next boot.

• The script refuses to arm a protected volume with no recovery-password protector — there would be no way back in.
• It cannot verify that you hold a copy of that key. Confirm your escrow is healthy before running -Apply at scale.
• -SuspendBitLocker suspends protection across the next reboot so the change re-seals without prompting. BitLocker resumes automatically afterwards.
• The report states your PCR profile. A PCR 7 based profile is measured-boot safe for a certificate add. A profile including PCR 0/2/4 covers firmware and boot-manager measurements, which these steps do move — higher risk of a prompt.

BitLocker state is read three independent ways (Get-BitLockerVolume, manage-bde, and Win32_EncryptableVolume) and reconciled. If the readers disagree, or if none can read the volume, the script refuses to change firmware rather than guess.

Parameters

Virtual machines are excluded by default: the 2023 CA reaches the firmware baseline via a BIOS update, and a VM's firmware comes from its hypervisor — a guest on an un-updated host cannot complete the migration on its own.

What to expect after applying

• It will not finish on the first reboot. Windows applies the certificate update, then the boot-manager update, typically across more than one restart with a scheduled task running in between.
• Microsoft gates this per device. Setting the value queues the work; Microsoft's staged rollout decides when each machine is eligible. If nothing appears to happen, re-run and read the "Microsoft gate" line — it states the reason, for example "Under Observation - More Data Needed".
• Re-run at any time to check progress. It is safe to run repeatedly.

Validation

Tested end to end on Windows 11 (build 26200, PowerShell 5.1, running as SYSTEM), UEFI with Secure Boot enabled, BitLocker fully encrypted with TPM + RecoveryPassword protectors on a PCR 7,11 profile:

• Correctly identified a half-migrated machine — firmware trusting Windows UEFI CA 2023 while bootmgfw.efi was still signed by Microsoft Windows Production PCA 2011 — and did not report it as finished, despite that machine simultaneously reporting UEFICA2023Status = Updated and WindowsUEFICA2023Capable = 2.
• All three BitLocker readers agreed and were reconciled.
• Refusal gates verified: virtual machine (exit 2), and the 0x80 revocation bit (exit 1).
• -Apply wrote 0x5944, confirmed by an independent registry read.
• -SuspendBitLocker followed by a reboot: the machine returned with no recovery prompt and BitLocker auto-resumed.
• Start-Transcript captured the full report; the JSON output contained no recovery-key material.

Not yet observed: a machine completing the full migration to FullyMigrated. The final step is gated by Microsoft's staged per-device rollout, which is outside anyone's control. The script surfaces that gate's stated reason rather than leaving it as an unexplained no-op.

Licence

MIT — see LICENSE. Provided as-is, with no warranty. Review it before running it in your environment; it is a single readable file for exactly that reason.