Microsoft released an out‑of‑band update on August 19, 2025 — KB5066189 for Windows 11 (OS Builds 22621.5771 and 22631.5771) — to fix a high‑impact regression introduced earlier in the August security rollup that broke Reset and cloud recovery flows, while reiterating a separate, platform‑level advisory about impending Windows Secure Boot certificate expirations that begin in June 2026.
Microsoft’s August security releases (delivered in the second week of August) included combined Servicing Stack Updates (SSU) and Latest Cumulative Updates (LCU) for various Windows 11 servicing branches. Those updates introduced a regression that prevents the operating system from completing the following recovery actions on affected client builds: Settings → System → Recovery → Reset this PC, Settings → System → Recovery → Fix problems using Windows Update (cloud recovery), and RemoteWipe CSP triggered by management tools. Microsoft confirmed the regression and said an out‑of‑band (OOB) update would be issued.
Concurrently, Microsoft continues to warn administrators about a separate, multi‑quarter program to refresh Secure Boot trust anchors: several Microsoft certificates issued in 2011 are scheduled to begin expiring in June 2026 (with additional expirations in October 2026), and organizations must prepare firmware and OS‑level changes to avoid serviceability and boot‑integrity issues. Microsoft’s guidance and the technical rollout plan are being published and updated on the Secure Boot certificate guidance pages.
Key points:
At the same time, the Secure Boot certificate expiry timeline poses a broader, ongoing risk: if devices retain legacy 2011 CA certificates past their expiry windows, they may stop receiving pre‑boot security fixes and could, in some configurations, fail to validate or run new boot components signed by the replacement 2023 CAs. That could prevent distribution of critical pre‑boot fixes and impair boot‑time integrity. The certificate transition is inherently cross‑vendor — firmware readiness from OEMs is the gating factor — and therefore requires coordinated planning.
Strengths:
Conclusion
KB5066189 resolves a pressing regression that prevented Reset and cloud recovery flows for affected Windows 11 builds; installing the OOB update on impacted systems will restore those capabilities. Meanwhile, the Secure Boot certificate program — with expirations starting June 2026 — remains an enterprise‑grade project that requires firmware updates, staged testing, and vendor coordination. Treat the OOB patch as an immediate operational patch, and treat the Secure Boot certificate transition as a multi‑quarter program requiring inventory, pilot testing, and prioritized firmware remediation.
Source: Microsoft - Message Center August 19, 2025—KB5066189 (OS Builds 22621.5771 and 22631.5771) Out-of-band - Microsoft Support
Background and overview
Microsoft’s August security releases (delivered in the second week of August) included combined Servicing Stack Updates (SSU) and Latest Cumulative Updates (LCU) for various Windows 11 servicing branches. Those updates introduced a regression that prevents the operating system from completing the following recovery actions on affected client builds: Settings → System → Recovery → Reset this PC, Settings → System → Recovery → Fix problems using Windows Update (cloud recovery), and RemoteWipe CSP triggered by management tools. Microsoft confirmed the regression and said an out‑of‑band (OOB) update would be issued.Concurrently, Microsoft continues to warn administrators about a separate, multi‑quarter program to refresh Secure Boot trust anchors: several Microsoft certificates issued in 2011 are scheduled to begin expiring in June 2026 (with additional expirations in October 2026), and organizations must prepare firmware and OS‑level changes to avoid serviceability and boot‑integrity issues. Microsoft’s guidance and the technical rollout plan are being published and updated on the Secure Boot certificate guidance pages.
What KB5066189 delivers
Fixes the reset and recovery regression
KB5066189 is an optional, out‑of‑band quality update that addresses the regression introduced by the August 2025 security update (identified in earlier KBs such as KB5063874/KB5063875) that caused resets, cloud recoveries, and RemoteWipe operations to fail on affected client builds. Microsoft explicitly recommends installing the OOB update if you have observed failed recovery operations; if you never rely on the affected flows, installation is optional.Key points:
- The fix targets failures observed when initiating: Reset this PC; Fix problems using Windows Update (cloud reinstall); RemoteWipe CSP workflows.
- KB5066189 is delivered as a combined package that includes the Latest Cumulative Update and the servicing‑stack refresh where applicable; earlier bundled packages have required special uninstall procedures (see the DISM guidance below).
Servicing Stack Update included
The OOB update package also includes a servicing stack update (SSU) — KB5062686 for the 22621/22631 families — to keep the update pipeline robust. SSUs are small but critical: they update the component that installs Windows updates and are intentionally applied alongside LCUs to reduce installation failures. Note that SSUs are typically non‑removable once installed; removing only the LCU requires a DISM /Remove‑Package workflow.Why this matters: operational and security impacts
The regression targeted by KB5066189 is not a cosmetic bug. Reset and recovery flows are the last line of defense for corrupted installations, device handovers (resale, deprovisioning), and managed remote wipe workflows. When these flows fail:- Home users can be left unable to produce a clean system image or factory reset before disposing of or passing on a device.
- Enterprises and managed service providers risk incomplete remote wipes that may leave corporate data on devices intended to be sanitized, creating compliance exposure.
- IT operations face increased ticket volumes and longer repair times because technicians must fall back to offline media or manual reimage workflows.
At the same time, the Secure Boot certificate expiry timeline poses a broader, ongoing risk: if devices retain legacy 2011 CA certificates past their expiry windows, they may stop receiving pre‑boot security fixes and could, in some configurations, fail to validate or run new boot components signed by the replacement 2023 CAs. That could prevent distribution of critical pre‑boot fixes and impair boot‑time integrity. The certificate transition is inherently cross‑vendor — firmware readiness from OEMs is the gating factor — and therefore requires coordinated planning.
Technical details and verification
Affected builds and KB lineage
The regression was traced to the August cumulative updates for older Windows 11 servicing branches (the 22621/22631 families) and several Windows 10 LTSC SKUs. Specific KBs tied to the incident include the August security rollups (for example, KB5063875 for the 22621/22631 families and KB5063709 for some Windows 10 SKUs). Microsoft’s OOB update for the affected 22621/22631 builds is published as KB5066189 (OS Builds 22621.5771 and 22631.5771). Community reporting and Microsoft’s Release Health confirm this lineage.Servicing stack and uninstall behavior
Because Microsoft bundles the SSU and LCU into a combined package for reliability, administrators must be aware of uninstall constraints:- The SSU component cannot be uninstalled independently once applied.
- To remove the LCU portion, use the DISM /Remove‑Package command with the LCU package name retrieved via DISM /online /get‑packages. Running the Windows Update Standalone Installer (wusa.exe) with /uninstall on the combined package will not work because wusa cannot separate the SSU from the LCU in a single combined installer.
External confirmation
Independent coverage from security and Windows news outlets corroborated Microsoft’s advisory and remediation timeline. BleepingComputer and Windows Latest documented the regression, Microsoft’s confirmation on the release health portal, and the planned OOB fix; those reports arrived alongside Microsoft’s guidance about SSU+LCU packaging and Secure Boot certificate lifecycle advisories.The Secure Boot certificate program: what IT needs to know
The short version
- Several Microsoft CA certificates issued in 2011 — notably Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 — begin expiring in June 2026; Microsoft Windows Production PCA 2011 has a later expiry in October 2026.
- Microsoft will roll replacement certificates from the 2023 family to maintain continuity of Secure Boot trust.
- The update process involves both OS‑level updates (which can write to UEFI variables where firmware allows) and OEM firmware updates to ensure devices accept the new KEK/DB entries. Firmware readiness is the primary operational unknown.
Practical implications
- Devices that do not receive the new 2023 CA entries before the 2011 CAs expire may no longer accept updates to pre‑boot components and may be unable to validate newly signed boot components.
- Virtual machines and dual‑boot machines are not immune — VM hosts and firmware used by hypervisors matter, and Linux distributions that rely on Microsoft‑signed shims may encounter compatibility issues if firmware is not updated.
Microsoft’s recommended actions (summary)
- Prefer Microsoft‑managed rollouts where possible: for many consumer and corporate devices, Windows Update will deliver the updated certificates in a staged manner.
- For IT‑managed environments, coordinate with OEMs to confirm firmware versions that permit DB/KEK variable updates and stage firmware updates before accept‑ing OS‑level certificate updates.
- For environments that cannot enable Microsoft‑managed telemetry, follow the manual guidance (including registry opt‑in approaches and offline procedures) carefully and test extensively.
Actionable checklist — immediate‑to‑90‑day priorities
Apply this checklist in pilot, then staged rollouts. Each item is deliberately short and operational:- Inventory
- Identify devices with Secure Boot enabled (msinfo32 → Secure Boot State).
- Note OEM, model, and firmware/BIOS version for representative systems.
- Test OOB fix for reset/recovery
- Install KB5066189 on a small pilot ring of affected 22621/22631 devices.
- Validate Reset this PC (both Keep my files and Remove everything), cloud recovery, and an Intune RemoteWipe on test devices.
- Check event logs and servicing logs for errors and confirm the device exits recovery flows successfully.
- Secure Boot readiness
- Confirm firmware updates availability from OEMs for devices in scope; prioritize business‑critical assets.
- For managed fleets, consider enabling the MicrosoftUpdateManagedOptIn flow per Microsoft guidance if organizational policy permits (registry DWORD 0x5944), enabling Microsoft to manage the staged certificate updates. Test telemetry and privacy implications before wide opt‑in.
- WSUS/SCCM and image servicing
- Ensure Products = Windows 11 and Classifications = Security Updates for WSUS sync.
- Update golden images or offline images using DISM /Add‑Package methods that include the required SSU+LCU where appropriate.
- Pilot and expand
- Pilot with multiple OEMs and firmware levels.
- Expand to a larger pre‑production ring only after no regressions are observed.
- Document rollback plans, system images, and manual reimage procedures for devices that cannot be updated remotely.
Risk analysis: strengths, edge cases, and unknowns
Strengths in Microsoft’s approach
- Packaging the SSU and LCU together reduces sequencing failures and makes large deployments more robust when the OS can apply the combined payload. This approach is operationally sensible for reducing partial install states.
- The company has given multi‑quarter advance notice on Secure Boot certificate expirations, which is far preferable to a sudden enforcement deadline; this visibility enables programmatic remediation planning.
Key risks and operational unknowns
- Firmware readiness remains the single largest unknown. If OEMs do not publish UEFI firmware updates that permit the necessary KEK/DB changes, some devices could remain in a partially compatible state where OS updates cannot fully complete the Secure Boot transition. That is an OEM coordination problem, not an OS bug per se.
- Air‑gapped environments and devices under heavy regulatory constraints will require manual procedures that are inherently more error‑prone and slower. These organizations must plan remediation paths now.
- Dual‑boot and Linux users: widely used Linux distributions rely on Microsoft‑signed shims for Secure Boot compatibility. Where firmware never receives the updated Microsoft UEFI CA entries, those Linux shim signatures may be rejected or require manual intervention. This is a real‑world compatibility risk for mixed‑OS estates.
Unverifiable or evolving items (flagged)
- OEM firmware release schedules vary by model and vendor. Any specific claim about the percentage of devices that will be firmware‑ready by a given date is unverifiable without direct OEM inventories. Treat vendor timelines as advisory until validated against the actual hardware in your fleet.
Troubleshooting and recovery guidance
- If Reset or cloud recovery fails after earlier August updates but before installing KB5066189:
- Don’t repeatedly attempt the same flow at scale; instead, isolate and capture logs (Event Viewer → Applications and Services Logs → Microsoft → Windows → Servicing, and the Windows Update client logs).
- Consider manual reimaging from bootable media or using offline image servicing for immediate containment of critical devices.
- If you must remove the LCU after installing a combined SSU+LCU package:
- Run DISM /online /get‑packages and identify the LCU package name.
- Use DISM /online /Remove‑Package /PackageName:<name> to remove the LCU. Be aware the SSU will remain and cannot be removed via the combined package uninstall switch.
- For WSUS/SCCM delivery failures (0x80240069 or similar):
- Confirm WSUS sync settings and review Microsoft’s release health updates for any known delivery issues; Microsoft has previously issued Known Issue Rollbacks (KIRs) and KIRs or emergency fixes for such distribution problems. If a KIR is in place, follow Microsoft’s guidance to ensure the rollout of the KIR to your environment.
Timeline and testing cadence recommendation (practical)
- Day 0–3 (immediate): Apply KB5066189 to a lab/test ring of devices that replicate your major OEMs and firmware versions; validate Reset/Recovery/RemoteWipe flows and basic user journeys.
- Week 1–4 (pilot expansion): Expand to a small percentage of production devices, adding additional OEM models and critical LOB apps; monitor Windows Health Dashboard and device telemetry for anomalous behavior.
- Month 1–3 (broad rollout): Coordinate firmware updates with OEMs and schedule certificate rollout windows; ensure WSUS/SCCM synchronizations and image updates are complete. Maintain an exception register for devices that cannot be updated.
- By Q2 2026 (deadline window): Confirm all remaining devices either have the updated certificates or are scheduled for replacement/retirement; maintain compensating controls for any stragglers.
Final assessment and editorial verdict
KB5066189 is a necessary and targeted out‑of‑band repair: it restores critical Reset and recovery functionality that many organizations and users rely on as a last‑resort remediation tool. The update’s urgency and Microsoft’s confirmation justify its expedited distribution for affected systems. At the same time, the broader Secure Boot certificate lifecycle — a separate but related operational program — is the more consequential, long‑running platform challenge for 2025–2026. It demands cross‑vendor coordination, inventory discipline, and staged testing across firmware, virtualization platforms, and mixed‑OS environments.Strengths:
- Microsoft moved promptly to issue an OOB fix for a high‑impact regression.
- The SSU+LCU packaging model reduces installation sequencing failures in many environments.
- SSU permanence and combined packaging complicate rollback planning.
- OEM firmware readiness remains the critical unknown for the Secure Boot transition; organizations should treat firmware updates and certificate rollout as a project, not a single‑patch task.
Conclusion
KB5066189 resolves a pressing regression that prevented Reset and cloud recovery flows for affected Windows 11 builds; installing the OOB update on impacted systems will restore those capabilities. Meanwhile, the Secure Boot certificate program — with expirations starting June 2026 — remains an enterprise‑grade project that requires firmware updates, staged testing, and vendor coordination. Treat the OOB patch as an immediate operational patch, and treat the Secure Boot certificate transition as a multi‑quarter program requiring inventory, pilot testing, and prioritized firmware remediation.
Source: Microsoft - Message Center August 19, 2025—KB5066189 (OS Builds 22621.5771 and 22631.5771) Out-of-band - Microsoft Support
