Finish the Windows Secure Boot trust-chain transition from 2011 certificates

Source facts: normal startup does not prove the trust chain is current

Microsoft’s Windows Secure Boot certificate guidance says some devices still use certificates issued in 2011 with an expiration in June 2026. An affected computer may continue to start and receive ordinary Windows updates after that point, but it may be unable to receive future Secure Boot protections for the boot manager and other early-boot components. Availability alone is therefore not a reliable compliance test.

The documented transition is to the 2023 Secure Boot certificate authorities. Microsoft identifies estate-level signals for unfinished work: UEFICA2023Status is not set to Updated, System log event 1801 indicates an incomplete update, and event 1795 identifies a firmware error. Older or incompatible firmware raises the risk of validation errors, BitLocker recovery prompts or loops, startup hangs, and boot failure.

Microsoft advises organizations to identify devices still using the old certificates, update OEM firmware first, and pilot certificate servicing on a representative group. That group should span OEMs, firmware versions, and BitLocker-enabled systems. Supported deployment routes include Microsoft Intune, registry settings, Windows configuration service provider controls, and Group Policy. These are alternative control paths into a sensitive firmware-backed change; assigning one does not by itself prove that the firmware accepted it.

DSE recommendation: run the transition as hardware lifecycle work

Build one readiness record per hardware family, not one tenant-wide “deployed” flag. Include manufacturer, exact model, UEFI version, Secure Boot state, certificate status, Windows build, BitLocker protection and recovery-key escrow, management authority, update source, warranty state, and an accountable owner. Devices that cannot report the required evidence belong in an exception queue, not in the compliant total.

1. Establish a recoverable baseline. Confirm that each pilot starts cleanly, reports healthy Secure Boot, has current approved OEM firmware, and has a retrievable BitLocker recovery key. Record console or hands-on recovery options for remote devices before changing the trust database.
2. Pilot by meaningful variation. Select multiple units from every significant model and firmware branch. Include laptops with docks, desktops, remote systems, dual-boot or specialized configurations, and devices that previously required firmware exceptions. A single new laptop does not represent the estate.
3. Observe the complete restart path. Apply only the documented servicing method, perform required restarts, and verify normal boot, BitLocker behavior, Windows sign-in, device health, management check-in, and the application workflows important to that device class.
4. Prove the resulting state. Collect UEFICA2023Status, relevant System events, firmware version, last restart, and deployment result after the change. Treat event 1801, event 1795, a missing status, or a device that never checked back in as unresolved until investigated.
5. Advance in controlled rings. Expand by model only after the preceding ring meets explicit success thresholds and completes an observation period. Pause a model when recovery prompts, slow boots, firmware failures, or support contacts rise above the approved limit.
6. Close unsupported outcomes. For equipment that cannot accept compatible firmware or the new certificates, document vendor findings, business exposure, compensating controls, replacement date, and leadership acceptance. Do not leave “temporarily excluded” without an expiration.

Measure updated status by eligible device, success by model, incomplete and firmware-error events, devices missing evidence, unexpected recovery prompts, and exception age. Preserve the pre-change inventory and pilot evidence with the change record. The goal is not to force a registry value across every endpoint; it is to maintain a verifiable boot trust chain while retaining a tested way to recover devices that react badly.

The closeout packet should name devices that were powered off, loaned out, unmanaged, or awaiting repair during the rollout. Give each population a deadline and an intercept control so it cannot quietly return to production without assessment. Re-sample updated models after later firmware releases and preserve vendor escalation findings for future replacements.

Official references

• Microsoft Learn, Update Secure Boot Certificates for Windows Devices, May 1, 2026; reviewed August 11, 2026.