Microsoft Digital, the company’s internal IT organization, says it used a pilot of roughly 35,000 devices, staged deployment rings, Intune orchestration, Windows Autopatch reporting, and Defender for Endpoint telemetry to manage the migration. It reports a 95% pilot success rate, 86% compliance after 70 days of the broader rollout, and a current failure rate below one percent.
Those numbers are Microsoft’s own account of its Customer Zero deployment, and no outside reporting independently verifies the fleet size, compliance rate, or support impact. But Microsoft Support’s public documentation confirms the underlying deadline and the operational problem: legacy Microsoft Secure Boot certificates began expiring on June 24 and June 27, 2026, while the certificate used to sign the Windows boot loader expires on October 19, 2026.
For IT administrators, the useful conclusion is straightforward: this is no longer a planning exercise. An unremediated device may still boot and continue to receive ordinary Windows updates today, but it is losing the trust foundation required for future boot-chain security updates, revocation-list changes, and mitigations for newly discovered pre-OS vulnerabilities.
Three expiring certificates became four replacements
Microsoft’s internal write-up describes replacing three legacy certificates with four new certificates. That is accurate, but the wording can obscure an important architectural change.
The Microsoft Corporation KEK CA 2011, which expired on June 24, is replaced by the Microsoft Corporation KEK 2K CA 2023. The Key Enrollment Key, or KEK, authorizes changes to the Secure Boot allow and deny databases held in UEFI firmware. Without an updated Microsoft KEK, a PC cannot receive future Microsoft-signed changes to the trusted DB database or the revoked DBX database.
The Microsoft UEFI CA 2011, which expired on June 27, is being split into two trust anchors: Microsoft UEFI CA 2023 for third-party boot loaders and EFI applications, plus Microsoft Option ROM UEFI CA 2023 for third-party option ROMs. Microsoft’s OEM guidance says the split permits more granular trust decisions. A manufacturer or administrator can permit option ROMs without automatically extending trust to every third-party UEFI boot loader covered by the broader certificate.
The final item, Microsoft Windows Production PCA 2011, expires on October 19. Its successor, Windows UEFI CA 2023, allows firmware to trust Windows Boot Manager and related Windows boot components signed under the newer chain.
This sequencing matters. The June expirations did not cause every unmanaged PC to stop starting. Microsoft Support explicitly says systems without the 2023 certificates can still boot and install standard Windows updates. The longer-term failure is serviceability: those systems can be shut out from future protections affecting Boot Manager, DB, DBX, and early-boot vulnerability mitigations. The October Windows boot-loader certificate date creates a second, more immediate operational milestone for organizations that have left the Windows UEFI CA 2023 deployment incomplete.
The difficult part is firmware, not pushing a policy
Microsoft Digital’s report correctly identifies the hard part of this work: writing certificates is not the same as proving that a diverse hardware fleet can accept them safely.
Secure Boot data resides in UEFI firmware, where implementation quality varies by OEM, model, firmware release, peripheral configuration, and boot setup. Microsoft’s public troubleshooting guidance identifies the types of failure enterprises need to plan around: Secure Boot validation errors, BitLocker recovery prompts or loops, startup hangs, and devices that fail to boot. For older hardware, Microsoft recommends firmware updates before certificate deployment because firmware compatibility is often the deciding factor.
The company says it began its validation work in 2024 with the Windows Servicing and Delivery team, testing affected models in its Client Test Lab before moving to the 35,000-device controlled firmware release pilot. That is a meaningful procedural lesson. The pilot was not merely a small deployment ring; it was an attempt to discover which combinations of firmware and boot configuration could safely process certificate updates before deployment reached business-critical endpoints.
Microsoft also says it started with lower-risk cohorts and then progressed toward models with greater failure risk. That approach is much more defensible than targeting users by department or geography alone. A deployment ring for Secure Boot should reflect hardware model, UEFI revision, BitLocker configuration, custom boot components, recovery media usage, and whether a device runs a nonstandard image.
The company’s cited use of backups and loaner machines is another reminder that a successful certificate rollout needs a recovery plan outside the device being updated. If an affected system cannot boot, the management agent and its remediation script are inaccessible. A spare system, tested recovery media, OEM firmware recovery procedures, and support escalation paths are part of the deployment—not contingency paperwork.
Old recovery media can become a deployment blocker
Microsoft’s public CVE-2023-24932 deployment guidance adds a consequence that does not receive much attention in the internal rollout account: eventually revoking the old Windows boot-manager trust chain can make existing bootable media unusable.
The Secure Boot remediation process has an order. First, the device must receive the new Windows UEFI CA 2023 certificate in its firmware DB. Next, it can accept the Windows Boot Manager signed by that certificate. Only after those pieces are safely established can an organization move toward revoking trust for vulnerable older boot managers through DBX and related protections.
Microsoft’s guidance is explicit that the sequence cannot be reversed. It also warns that when the old boot managers are untrusted, bootable ISO images, USB recovery media, PXE deployments, and HTTP boot environments using an old boot manager may no longer start.
That makes Secure Boot certificate management a joint responsibility for endpoint engineering, server teams, security operations, and whoever owns deployment infrastructure. A business may show high endpoint compliance while retaining obsolete WinPE images, offline installers, or recovery USB sticks that fail precisely when administrators need them during an outage.
Microsoft’s own reported rollout gives one indication it encountered the same complexity across specialized hardware. Its 15,000 meeting-room devices use a custom Windows 11 image and needed OEM firmware coordination. Its Cloud PCs required scheduled restarts, while servers needed Defender for Endpoint visibility to compensate for telemetry gaps. The company says meeting rooms and virtual machines remain part of its remediation long tail.
A 97% dashboard is not the finish line
At Microsoft’s reported scale, three percent represents approximately 15,000 devices if the 97% figure is measured against the full 500,000-device fleet. Microsoft has not published a breakdown of those remaining systems by hardware type, operating system, certificate status, or why they remain outstanding, so that calculation should be read as a rough scale indicator rather than a confirmed remediation count.
Still, the math explains why the final segment of a Secure Boot deployment is likely to consume disproportionate effort. The easy devices are the modern, standard-configured systems receiving current servicing and firmware updates. The last cohort tends to contain hardware with firmware limitations, custom images, irregular restart patterns, disconnected machines, virtualized workloads, special-purpose rooms, and systems whose inventory record does not reliably show whether the firmware update completed.
Microsoft’s Autopatch Secure Boot report and Windows Security status indicators are useful additions, but neither should be treated as a substitute for enterprise validation. Microsoft says Secure Boot-specific notifications are disabled by default on managed Windows 10, Windows 11, and Windows Server devices to reduce alert noise. Administrators who depend on users seeing a Windows Security warning will therefore miss much of their managed estate.
The more reliable verification path is to inventory the explicit remediation state. Microsoft’s enterprise guidance uses the UEFICA2023Status value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing; a value of Updated indicates that the necessary 2023 certificates are present in DB and KEK and the system begins with the 2023-signed boot manager. Event logs, firmware inventory, OEM model data, and management-platform reporting should be used to reconcile machines that remain NotStarted or InProgress.
What administrators should do before October 19
Organizations that have not finished their migration should treat the next two months as a time-bounded validation and remediation window, not as an opportunity for a broad untested policy push.
- Inventory devices still carrying 2011 Secure Boot certificates, and separate them by OEM, model, firmware version, operating system, and role before expanding deployment rings.
- Verify that the 2023 certificate update completed in both the firmware trust stores and the boot chain; a machine with Secure Boot enabled is not necessarily a machine with the new certificates installed.
- Update OEM firmware where available before attempting broad remediation on older models, particularly for systems with BitLocker, nonstandard boot configurations, or previous Secure Boot errors.
- Test current recovery images, PXE infrastructure, bootable USB media, and custom Windows installation media against remediated devices before deploying revocations that invalidate old boot managers.
- Maintain a separate exception workflow for servers, virtual machines, meeting-room systems, kiosks, and other devices that do not follow normal user endpoint restart and servicing patterns.
Microsoft’s internal deployment is valuable chiefly as evidence that a large Windows fleet can move the Secure Boot trust chain without a mass outage—but only with model-level testing, staged targeting, and telemetry capable of identifying exceptions. Its unfinished three percent is the more useful number. Those are the machines that will determine whether an organization can accept the next boot-level security fix when it arrives.