Microsoft has confirmed that a display bug in the October 2025 servicing wave is incorrectly telling some Windows 10 PCs they’ve “reached the end of support” even when those machines remain entitled to security updates through
Extended Security Updates (ESU) or supported
LTSC channels — and it has pushed a server-side correction plus an enterprise Known Issue Rollback (KIR) to neutralize the misleading banner.
Background / Overview
Windows 10’s mainstream monthly servicing officially ended on
October 14, 2025. That lifecycle milestone meant the last broadly distributed cumulative update for mainstream consumer and most commercial SKUs was released on that date, with Extended Security Updates (ESU) and specific Long-Term Servicing Channel (LTSC) editions providing documented, time‑bound extension paths for customers that need them. Within hours and days of the October cumulative (tracked under
KB5066791, delivering build
19045.6456 for 22H2), some devices began showing a prominent red message in Settings → Windows Update that reads:
“Your version of Windows has reached the end of support.” Critically, that banner appeared not only on unenrolled systems but also on devices that were correctly enrolled in ESU and on LTSC SKUs that remain within their published servicing windows. Microsoft has characterized this as a
display/diagnostic error and not a revocation of ESU or LTSC entitlements.
What happened, in plain terms
The visible problem
- Affected machines show an alarming banner in the Windows Update settings page saying the OS has reached end of support.
- When the banner is present the Settings page may also disable or hide the Check for updates button in some configurations, creating further confusion.
Which devices were reported affected
The issue has been observed primarily in:
- Windows 10, version 22H2 — Pro, Education, and Enterprise editions that are correctly enrolled in ESU and configured with ESU product keys.
- Windows 10 Enterprise LTSC 2021.
- Windows 10 IoT Enterprise LTSC 2021.
What did Microsoft do?
Microsoft deployed a two‑track remediation:
- A server-side (cloud) configuration update intended to clear the incorrect banner automatically for devices that accept dynamic configuration/OneSettings CSP downloads and have normal Windows Update connectivity.
- A Known Issue Rollback (KIR) package (an MSI/Group Policy administrative template labeled against KB5066791 — e.g., KB5066791 251020_20401 Known Issue Rollback) that administrators can deploy in locked or air‑gapped environments where the cloud configuration cannot propagate.
Microsoft has emphasized that
security updates are still being delivered to systems that are properly entitled — the banner was cosmetic and misleading rather than a functional cutoff of ESU or LTSC servicing. Multiple vendor and community investigations confirmed that update plumbing and entitlement checks (for example, slmgr.vbs /dlv output for key-based ESU) continued to show valid activation and that cumulative updates were still being installed.
Why this happened (technical anatomy)
The Settings app’s lifecycle messaging isn’t driven solely by a single local check — it depends on a blend of signals:
- Locally installed update metadata and manifests (what’s present in the local servicing stack).
- Cloud‑delivered configuration and dynamic diagnostic flags (OneSettings CSP).
- Telemetry and entitlement endpoints that indicate ESU activation and SKU details.
- Management channel policies (Intune, WSUS, Group Policy) which can block or override cloud config.
The prevailing hypothesis — reflected in Microsoft’s release communications and community diagnostics — is that a display metadata or server‑side diagnostic flag was misapplied or misinterpreted after the October cumulative, causing the Settings UI to flip to an “end of support” state for certain SKUs even though the underlying entitlement and update delivery remained intact. In short: the problem is a presentation/diagnostic regression, not an entitlement revocation.
Caveat: the exact low‑level root cause (which internal flag or telemetry condition was the proximate trigger) is not fully public; some community threads and archived reporting speculate about other companion updates playing a part, but those theories remain unverified. Flagging speculation as such is important to avoid misdiagnosis.
Microsoft’s remediation: what administrators and users need to know
Automatic cloud fix (recommended for most environments)
If a device is online and not blocking OneSettings CSP downloads or Windows Update endpoints, it should receive the cloud configuration correction automatically and the Settings banner should clear within the propagation window (commonly 24–72 hours, though environment constraints can extend that). This is the least‑disruptive path and requires no additional local changes.
Known Issue Rollback (KIR) for locked‑down fleets
For environments that block dynamic cloud configuration (air‑gapped networks, strict WSUS-only, or policy‑locked setups), Microsoft published a KIR MSI that admins can deploy. The KIR is intended as a temporary, surgical neutralizer of the incorrect UI flag while leaving the October cumulative and its security fixes in place. Typical deployment steps include:
- Download the KIR MSI referenced by Microsoft for KB5066791 (the package name referenced in advisories is KB5066791 251020_20401 Known Issue Rollback).
- Import the administrative template into the Group Policy Central Store if desired.
- Configure the policy: Computer Configuration → Administrative Templates → set the KIR policy entry to Disabled (this disables the erroneous banner).
- Force Group Policy update (gpupdate /force) and reboot affected machines to apply the setting.
Immediate validation steps (verify entitlement — don’t trust a single banner)
Administrators should rely on authoritative evidence of ESU or LTSC entitlement rather than the Windows Update banner:
- Check the installed update history (Settings → Update & Security → View update history) to confirm KB5066791 and subsequent cumulatives are present.
- Verify ESU activation for key‑based installs with: slmgr.vbs /dlv (run in an elevated command prompt) to confirm ESU keys are active.
- For Azure-hosted VMs, validate Azure’s ESU auto‑enablement settings according to Microsoft’s lifecycle documentation and VM patching configuration.
Step‑by‑step triage checklist for help desks and admins
- Confirm exact OS edition and build: open Settings → System → About or run winver. Verify whether the device is Windows 10 22H2 (build 19045.6456) or an LTSC SKU.
- Check Update History: confirm KB5066791 and relevant cumulatives are installed. Do not uninstall the October cumulative in a panic — it contains security fixes.
- Validate ESU entitlement: run slmgr.vbs /dlv to view ESU activation status for key‑based deployments; for Azure VMs, confirm automatic ESU enablement and patch configuration.
- If devices are connected and not policy‑blocked, allow up to 48–72 hours for the server-side config to propagate. If devices are stuck behind strict firewalls or management, download and deploy the KIR as documented by Microsoft.
- Update support scripts and internal communications: instruct staff to treat the banner as a UI diagnostic issue that does not automatically indicate lost security updates for ESU/LTSC‑entitled devices.
What to avoid doing
- Do not mass‑uninstall KB5066791 without a tested rollback plan. Doing so could remove security fixes and create real exposure.
- Avoid relying on ad‑hoc community workarounds (file deletions, manual appraiser cache manipulations) in production without testing. Microsoft’s cloud fix and KIR are the supported remediation paths. Community tricks are anecdotal and may introduce side effects.
Critical analysis — strengths and weaknesses of Microsoft’s handling
Strengths
- Fast, two-track remediation. Microsoft issued a server-side correction for broadly connected devices and simultaneously provided a KIR for locked-down fleets. That split approach respects the operational reality of both consumer and enterprise environments.
- Surgical KIR tooling. Known Issue Rollback is designed to remove a single regression without rolling back the entire cumulative; that preserves October security fixes while removing only the problematic UI flag. This reduces collateral damage compared with a full uninstall.
- Transparent messaging that the issue is cosmetic. Microsoft and industry reporting repeatedly clarified that affected machines that are properly entitled continue to receive security updates — a key reassurance that reduced immediate security risk.
Weaknesses and risks
- Fragility of lifecycle messaging. Modern servicing relies on a complex mesh of cloud flags, telemetry, and local metadata. When those channels get out of sync the visible UX can be misleading, generating outsized operational churn for administrators and end users. False lifecycle signals can cascade into ticket storms, emergency audits, or unnecessary procurement decisions.
- Communication friction for locked environments. The cloud fix is fast for connected machines, but air‑gapped, WSUS‑only, or strictly policy‑controlled environments need the manual KIR route — which imposes deployment overhead and invites inconsistent patch-state behavior across an estate.
- Trust erosion. Even a brief, incorrect “end of support” banner damages confidence in vendor lifecycle messaging. Customers sensitive to compliance and audit risk may react defensively, accelerating migrations or purchasing third‑party remediation services unnecessarily.
Broader implications
This incident is a useful case study in why lifecycle notices must be treated as a starting point for triage — not the final authority. Inventory, entitlement verification, and update history remain the authoritative indicators of support status. For enterprise security teams, it’s now important to:
- Treat vendor UI lifecycle flags as triggers for validation rather than immediate action.
- Build playbooks that verify entitlement (activation checks, update history), deploy KIRs where necessary, and communicate clear guidance to users and auditors.
The episode also highlights that Microsoft’s push to transition users to Windows 11 leaves the Windows 10 end‑of‑mainstream date highly visible; that marketing reality increases the stakes of any incorrect “out of support” message because it feeds existing upgrade pressure and anxiety. Independent reporting noted the danger that such a message can have downstream effects on purchasing and migration decisions.
What we still don’t know (and what’s unverified)
- The exact internal flag, telemetry rule, or companion update that caused the display regression has not been fully itemized in public engineering notes. Community posts point to cross‑interactions with other update metadata, but those leads remain speculative until Microsoft publishes a detailed post‑mortem. Treat speculative causes (for example, claims tying the regression to unrelated KBs) as unverified until Microsoft confirms specifics.
Practical advice for end users (concise)
- Don’t panic. A banner alone does not mean your PC stopped receiving ESU security updates if you have valid entitlement.
- Check Settings → System → About to confirm edition/build. Look at Update history to confirm KB5066791 or later cumulative updates are installed.
- If you enrolled in ESU via key, verify activation with slmgr.vbs /dlv. If you’re an Azure VM owner, confirm Azure’s auto‑enablement of ESU per Microsoft’s guidance.
- If the banner persists and you’re in a managed environment, contact your IT team — they may need to allow OneSettings CSP downloads or deploy Microsoft’s KIR.
Conclusion
The October servicing wave produced an unfortunate but — crucially — non‑catastrophic regression: a cosmetic banner claimed some Windows 10 devices had reached end of support when in fact many of those machines were legitimately covered by
Extended Security Updates or by
LTSC servicing promises. Microsoft’s dual remedy — a cloud‑delivered configuration correction for connected devices and a Known Issue Rollback for locked environments — is the correct operational response to limit disruption while preserving security patches. Administrators should treat the banner as a red flag and follow concrete verification steps (build checks, ESU activation commands, update history) rather than reacting to the UI alone.
This incident should prompt IT teams to update playbooks to verify lifecycle state with authoritative checks, improve communication scripts for help desks, and reinforce the principle that vendor UI messages are the start of triage, not the final verdict. The underlying lesson is broader: as desktop OS servicing becomes more dependent on cloud flags and dynamic telemetry, organizations must adapt processes to validate those signals quickly and avoid costly, reactive decisions.
Source: Windows Central
Microsoft admits that Windows 10 is wrongly telling users they're out of support — here's the fix