Windows Server Update Services was deprecated by Microsoft on September 20, 2024. Twenty-one months later, in June 2026, the role still ships with Windows Server 2025, still synchronises drivers from the Microsoft Update Catalog, and still backs the Configuration Manager Software Update Point. No end-of-life date has been published. The Microsoft Learn entry, last revised on March 19, 2026, reads in full: "WSUS is no longer actively developed. All the existing capabilities and content continue to be available for your deployments."
The story for a Configuration Manager shop in mid-2026 is therefore not the deprecation announcement itself. The story is what has accumulated in the interval — a driver-sync deprecation that Microsoft announced and then reversed, a server-side WSUS sync outage in July 2025, a hardening pass in September 2025 that quietly broke Extended Security Updates for legacy clients, a critical remote code execution vulnerability in October 2025 that prompted an emergency out-of-band release, and a recommended-replacement matrix that splits across three different products instead of one. This article documents the current status, the three official replacement paths, and the concrete decision profile for an SCCM-only shop facing the question "what should be done today."
The Deprecation Statement, Twenty-One Months On
Three official Microsoft surfaces define the current status, and they say the same thing in three slightly different registers.
The original Windows IT Pro Blog announcement of September 20, 2024, authored by Nir Froimovici, states the operative wording: "we are no longer investing in new capabilities, nor are we accepting new feature requests for WSUS" and "we are preserving current functionality and will continue to publish updates through the WSUS channel." The announcement contained no removal date and no migration deadline.
The Microsoft Learn page Features Removed or No Longer Developed in Windows Server, last revised on March 19, 2026, lists WSUS in the Features no longer in development table for Windows Server 2025 with a one-line explanation: "WSUS is no longer actively developed. All the existing capabilities and content continue to be available for your deployments." The same page provides Microsoft's working definition of the term: "Deprecation means that a feature, functionality, or service is no longer in active development. A deprecated feature might be removed in future releases. A deprecated component still ships in Windows Server, is supported for production deployments, and continues to receive security and quality updates per the product lifecycle."
The WSUS product overview page on Microsoft Learn carries the deprecation banner directly on the product surface: "WSUS is deprecated and is no longer adding new features. However, it continues to be supported for production deployments, and receives security and quality updates as per the product lifecycle."
Three consequences follow from this wording.
First, the absence of an end-of-life date is itself the date. WSUS inherits the Windows Server 2025 servicing lifecycle, which runs to October 9, 2029 for mainstream support and October 10, 2034 for extended support. No earlier Microsoft commitment has been published. The 2034 horizon is the only number an architect should plan against.
Second, the Configuration Manager Software Update Point is explicitly unaffected by the deprecation. Microsoft has reiterated in the announcement and in subsequent Tech Community responses that WSUS deprecation does not alter ConfigMgr's integration with WSUS. The Software Update Point role still requires WSUS to be installed locally on the same system, and the SUP remains a thin management layer over WSUS. Estates that rely on SUP for client update orchestration continue to operate without architectural change.
Third, deprecated is not frozen. Windows Server 2025 has continued to receive hardening passes that quietly remove WSUS surface area. The September 2025 cumulative update is the clearest case in point and is addressed in the next section.
What Has Actually Changed Since September 2024
The deprecation announcement is the headline. The substance of any reasonable decision in mid-2026 is the chronology of post-announcement events.
The driver synchronisation deprecation, announced and then reversed
In June 2024, Microsoft announced that driver synchronisation in WSUS would be deprecated on April 18, 2025. The plan was to route driver acquisition through the Microsoft Update Catalog rather than through WSUS synchronisation. In April 2025, Microsoft posted Continuing WSUS support for driver synchronization and indefinitely postponed the removal. The official reason cited was customer feedback on disconnected-device scenarios — air-gapped manufacturing networks, classified government environments, and ConfigMgr OSD task sequences that resolve driver-package content against on-premises WSUS infrastructure.
The implication for an SCCM-shop admin is that WSUS-based driver workflows remain valid in 2026. The implication for migration planning is that Microsoft has demonstrated a willingness to reverse a stated deprecation timeline when the disconnected-estate case is made loudly enough. Whether the same dynamic applies to WSUS as a whole is speculative.
The July 2025 synchronisation outage
On July 9, 2025, beginning around 12:30 ET, WSUS instances worldwide failed to synchronise with Microsoft Update. The Microsoft Health Advisory described the cause as "a problematic update revision in the storage layer" and confirmed that "updates cannot be deployed using WSUS or Configuration Manager" during the incident. Microsoft published no workaround. A server-side service repair on July 10, 2025 resolved the condition.
The incident was operational rather than architectural, and it has no carry-through. It belongs in the chronology because it is the public evidence that a deprecated product receives less defensive investment than an actively developed one — and that the Configuration Manager SUP shares the failure mode of WSUS, by design, because the SUP is WSUS.
The September 2025 hardening pass
Starting with the September 2025 security update — referenced in Microsoft's Hardening changes for Windows Server Update Services in Windows Server 2025 and tied to KB5067349 — WSUS running on Windows Server 2025 stopped shipping legacy binaries used by the WSUS SelfUpdate service. The hardening change is documented as "removing dependencies on old code that's no longer supported" — specifically the DLLs and EXEs that WSUS uses to update the SelfUpdate component in the Windows Update Agent on managed devices.
Windows 10, Windows 11, and current Windows Server versions are unaffected. The breaking case is Extended Security Updates for Windows Server 2012 and Windows Server 2012 R2 clients that synchronise updates from a WSUS upstream running on Server 2025. Those clients can no longer self-update their Windows Update Agent against that upstream.
Microsoft's documented workaround is to copy the SelfUpdate folder from an older supported WSUS installation (%systemdrive%\Program Files\Update Services) onto the Server 2025 WSUS install path. The procedure is explicitly framed as transitional: "To be secure in the longer term, Microsoft recommends upgrading the legacy OS versions and upgrading to Windows Server 2025."
The October 2025 remote code execution emergency
On October 23, 2025, Microsoft released an out-of-band security update to address CVE-2025-59287, a critical unauthenticated remote code execution vulnerability in the WSUS reporting web service. The CVSS score is 9.8. The flaw is a deserialisation bug in the BinaryFormatter-based handling of the AuthorizationCookie object on the ClientWebService/client.asmx endpoint. Affected versions span Windows Server 2012, 2012 R2, 2016, 2019, 2022 (including 23H2), and 2025, on any host with the WSUS role enabled.
The OOB update is documented across six per-version KB articles:
| Server version | KB |
|---|---|
| Windows Server 2012 | KB5070887 |
| Windows Server 2012 R2 | KB5070886 |
| Windows Server 2016 | KB5070882 |
| Windows Server 2019 | KB5070883 |
| Windows Server 2022 | KB5070884 |
| Windows Server 2025 | KB5070881 |
| Windows Server 23H2 | KB5070879 |
The patch is cumulative and supersedes the October Patch Tuesday content. A reboot is required.
Active exploitation began within hours of the OOB release. Eye Security's incident-response telemetry documents the first observed exploitation at 06:09:25 UTC on October 24, 2025, with the deserialisation error and embedded payload activating at 06:55:41 UTC. The attack chain is a SOAP-envelope POST to the ClientWebService/client.asmx endpoint on TCP port 8530 or 8531, a ysoserial.net-style ActivitySurrogateSelector gadget chain that instantiates a .NET executable in the w3wp.exe worker process, command execution via cmd.exe and powershell.exe, and exfiltration to attacker-controlled webhooks. Eye Security and Huntress independently reported the post-exploitation pattern as hands-on-keyboard — manual reconnaissance commands (whoami, net user /domain, ipconfig /all) spaced seconds apart — rather than automated mass-scanning. Approximately 8,000 internet-exposed WSUS instances were identified at the time. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog and mandated federal-civilian remediation by November 14, 2025.
Two consequences are load-bearing for an architecture decision in 2026.
First, exposure posture has shifted from a hygiene concern to a primary architectural variable. WSUS was not designed to face the internet directly, and the October 2025 incident is the public proof of that design assumption. Any WSUS instance reachable from outside the management network on ports 8530 / 8531 should be treated as a finding before any migration is planned.
Second, the OOB patch has a side effect that surfaces only in operations. As documented on the per-KB pages, after installing KB5070879 or later updates, WSUS does not display synchronisation error details within its error reporting. The reporting functionality was temporarily removed to address CVE-2025-59287. As of the June 2026 cumulative update, the suppression is still in effect. WSUS administrators who depended on the in-console error detail for sync-troubleshooting workflows now operate without it, and there is no documented restoration timeline.
The Server 2025 product category, manually activated
Smaller but worth recording: a freshly installed WSUS instance on Windows Server 2025 does not include Microsoft Server Operating System-24H2 in the default product subscription list. Until the category is manually activated under Options → Products and Classifications, updates targeted at Server 2025 (which Microsoft ships as the Microsoft Server Operating System-24H2 product family) are evaluated as Not Applicable on Server 2025 clients. The condition is documented across multiple Microsoft Q&A threads from late 2025 and through 2026; the fix is a single click in the WSUS console followed by a sync. It is the kind of detail that a fresh deployment hits on day one and that no migration plan needs to anticipate, but every Server-2025-era WSUS admin will encounter.
Microsoft's Recommended Replacement Paths
Microsoft's recommendation is not replace WSUS with X. It is replace each workload that WSUS currently serves with the appropriate cloud-or-cloud-adjacent product. Three products carry the load.
Intune and Windows Autopatch for Windows client updates
For Windows 10 and Windows 11 client updates, the official replacement is Microsoft Intune combined with Windows Update for Business policies and Windows Autopatch orchestration. The Microsoft Learn introduction to Windows Autopatch describes the service as "a cloud service that automates Windows, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams updates to improve security and productivity across your organization." Autopatch covers Windows quality updates, feature updates, hotpatch (since May 2026 — see the hotpatch default switch coverage), driver and firmware updates, and Microsoft 365 application updates.
Licensing is the gating concern for an SCCM-shop entering Autopatch for the first time. As of April 2025, Microsoft removed the explicit feature-activation step and made the core Autopatch capabilities available to Windows 11 Business Premium, A3 or higher, E3 or higher, and F3 licences. Submission of support requests to the Autopatch engineering team requires E3+ or F3. Devices on Windows Pro or Home are ineligible and continue to receive Microsoft Update directly.
For a brownfield SCCM estate, the practical migration path is co-management with the Windows Update workload slider moved from Configuration Manager to Intune. Once the workload is shifted, devices receive Windows Update client policies from Intune rather than from ConfigMgr Group Policy. ConfigMgr clients continue to operate; Software Update deployment is delegated to the Windows Update for Business pipeline. Dual Scan behaviour activates by default, which allows Windows 10 and 11 devices to scan both WSUS and Windows Update — a detail that requires deliberate decisions about which side owns the cumulative update at any moment.
The slider is a workload-level switch, not a per-device migration. A pilot cohort is moved first by targeting a collection; production rings follow. The mechanism is documented in Integrate Windows Update client policies on Microsoft Learn.
Azure Update Manager for server updates
For Windows Server and Linux server updates, the official replacement is Azure Update Manager (AUM). The AUM overview on Microsoft Learn, last revised on April 2, 2026, scopes the service as "a unified service to help manage and govern updates for all your machines that run a server operating system."
The boundary is explicit and worth quoting from the AUM FAQ: "Azure Automation Update Management didn't provide support for patching Windows 10 and Windows 11. The same is true for Update Manager. We recommend that you use Microsoft Intune as the solution for keeping Windows 10 and Windows 11 devices up to date." In other words, AUM is for servers; Intune is for clients. There is no single product that replaces all of WSUS in a single substitution.
Non-Azure servers must be Arc-enabled to come into AUM scope. The Arc agent installation, the connection to an Azure subscription, and the role-based access plumbing are all prerequisites. Pricing for AUM on Arc-enabled servers is USD 5 per server per month, prorated daily at approximately USD 0.16 per day per 31-day month, and only billed for days the server is connected and managed. AUM is provided at no additional charge in several scenarios: machines enabled for ESU delivery via Arc, machines under Defender for Servers Plan 2, machines with active Software Assurance, Azure Local VMs created via an Azure Arc resource bridge, and machines with Windows Server pay-as-you-go enabled by Azure Arc. For Azure-native VMs, AUM is included at no extra cost.
AUM honours machine-level update-source settings. A machine that is configured to fetch updates from a WSUS server continues to do so; AUM orchestrates patch schedules and compliance reporting on top of that. The implication for an SCCM shop that retains WSUS for ConfigMgr SUP integration is that AUM can sit alongside WSUS for the server estate without forcing a WSUS retirement.
Third-party application updates — the unchanged gap
Neither Intune nor AUM provides a native catalogue of third-party application updates equivalent to what an SCCM SUP plus WSUS plus a third-party patching add-in delivers. Microsoft has not announced one. The practical answer for third-party updates remains the same products that have served the SCCM ecosystem for years — Patch My PC, ManageEngine Patch Manager Plus, Ivanti Neurons — operating either through the SCCM SUP (the unchanged path) or through Intune's Win32 deployment surface, often with vendor-provided cloud integrations.
The implication for migration planning is that retiring WSUS for client updates does not retire the third-party-update requirement. A Configuration Manager estate that moves its first-party Windows update workload to Intune still needs a deployment surface for non-Microsoft software updates, and the third-party tooling continues to operate. The Intune-native path for third-party updates is Win32 application deployment combined with Enterprise App Management, with the third-party-update vendor providing the catalogue.
The Migration for an Existing SCCM-Only Shop
The decision tree depends on three variables: the current Intune licence position, the cloud-readiness of the workloads in scope, and the regulatory constraints that govern the estate. Three reference profiles cover most cases.
Profile A — Mature SCCM shop, no Intune licences, regulated workload
The action in mid-2026 is not a migration. It is a hardening pass on the current estate plus a strategic placeholder.
Concrete steps: confirm WSUS exposure posture (ports 8530 / 8531 should not be reachable from the public internet); confirm the October 2025 OOB patch (KB5070879 / KB5070881 / KB5070883 / KB5070884 / KB5070886 / KB5070887) is installed on every WSUS host in the hierarchy; confirm that any Server 2012 / 2012 R2 clients receiving ESU through a Server-2025-hosted WSUS upstream have the SelfUpdate-folder workaround applied per the Microsoft Support hardening KB; review WID-backed WSUS sites for migration to SQL Server before the WID deprecation horizon firms up; place Azure Update Manager on the multi-year roadmap as the server-side replacement, with no immediate execution.
The strategic placeholder is the licence question. AUM at USD 5 per server per month is a budget item that has not previously existed in a pure on-premises shop. Intune licensing for Autopatch is a larger budget item still. Both belong in the next renewal cycle's planning, not in a tactical 2026 plan.
Profile B — Already co-managed, Intune licences in place, mixed Win10/11 fleet
The action is to move the Windows Update workload slider — a concrete, reversible change with a documented migration path.
Concrete steps: pilot the slider move on a representative collection of co-managed devices; configure Update rings in Intune to mirror the existing SCCM Software Update Group cadence; observe the Dual Scan behaviour on pilot devices (the PolicyDrivenUpdateSource registry value transitions to 0 once the workload is moved); validate the Windows Update for Business reports in the Intune admin center for compliance attestation; promote to production rings; let WSUS continue to serve the ConfigMgr SUP plumbing role.
Retiring the WSUS host itself is not in this profile. The Software Update Point still requires WSUS locally. The retirement question opens only if and when ConfigMgr decouples SUP from WSUS — a step that Microsoft has not announced for any version of Configuration Manager, including the upcoming annual-cadence 2609 release (see the ConfigMgr 2603 coverage for the cadence context).
For the server estate, the same shop should evaluate Azure Update Manager for any subset of Windows or Linux servers that benefit from cloud orchestration, particularly machines already in scope of Defender for Servers Plan 2 (where AUM is free) or Azure Local clusters (where AUM is free for the cluster itself).
Profile C — Greenfield or rebuild moment
The action is to skip WSUS for clients. A new Modern Workplace estate built in mid-2026 has no architectural reason to deploy WSUS as the client update broker. The Microsoft-sanctioned baseline is Intune + Autopatch for clients, AUM for servers, and a third-party update tool operating through Intune for non-Microsoft applications.
ConfigMgr remains a defensible deployment for OS imaging, application packaging at scale, and legacy estate management. Whether the Software Update Point — and therefore WSUS — is deployed at all becomes a function of whether the estate retains a pre-Win10 cohort or otherwise needs the ConfigMgr SUP pipeline. A modern, fully Intune-managed Windows 11 fleet does not require WSUS to exist anywhere in the architecture.
Edge Cases That Do Not Have a Clean Cloud Answer
Two scenarios resist the recommended-replacement matrix and need explicit acknowledgement.
Air-gapped and disconnected estates
Azure Update Manager requires Arc connectivity. Windows Autopatch requires Intune connectivity. Both require a path to the Microsoft cloud. Manufacturing plant networks, classified government environments, regulated industrial control segments, and any estate that operates under a §BSI air-gap mandate or equivalent regulatory frame cannot use either product.
For these estates, the current answer is keep WSUS. The September 2024 deprecation announcement does not remove the product; the December 2034 Server 2025 extended-support horizon governs the planning window. The WSUSSCN2 cab file mechanism — the offline scan catalogue used for fully disconnected scanning — remains supported and is documented as continuing to be available through the WSUS channel. The third-party update vendors active in air-gapped scenarios continue to support disconnected workflows.
The risk in this profile is that deprecated products tend to lose surface area faster than they lose existence. The September 2025 hardening pass is the proof point. A disconnected-estate strategy that depends on WSUS in 2030 should include explicit monitoring of every monthly cumulative update for WSUS-affecting changes, and an internal lab for early validation.
Server 2012 and 2012 R2 under Extended Security Updates
Estates that still run Windows Server 2012 or 2012 R2 inside ESU — typically because of a vendor application that has no migration path — and that have consolidated their WSUS infrastructure to Windows Server 2025 hit the SelfUpdate hardening case described in the September 2025 hardening KB.
The documented workaround is to copy the SelfUpdate folder from %systemdrive%\Program Files\Update Services on an older supported WSUS host (Windows Server 2019 or 2022 work) to the same path on the Server 2025 WSUS, after the September 2025 cumulative update has been installed. The transitional nature of the workaround is explicit: "To be secure in the longer term, Microsoft recommends upgrading the legacy OS versions and upgrading to Windows Server 2025."
The cleaner answer for this cohort is Azure Update Manager with Arc-enabled ESU delivery. Microsoft offers Extended Security Updates for Windows Server 2012 and 2012 R2 enabled by Azure Arc, and AUM is free for those machines. The architecture decision becomes whether the legacy estate is in scope for Arc connectivity — which, for many of the estates that still run 2012 R2, is exactly the constraint that put them on WSUS in the first place.
The CVE-2025-59287 Frame
Of every event covered in this article, CVE-2025-59287 is the one that should drive the calendar in 2026.
The deprecation announcement does not mandate any timeline. The Microsoft Learn page does not mandate any timeline. The Server 2025 lifecycle horizon does not mandate any timeline. The October 2025 critical RCE does: it reframes the question from when should WSUS be replaced to where is WSUS currently reachable, who can reach it, and is every host running the October 2025 OOB patch.
The exposure-posture review is concrete and immediate. Internet-facing WSUS instances on ports 8530 and 8531 should not exist. Internal management networks should restrict WSUS endpoints to known administrative subnets. The KB-numbered OOB patches are cumulative and supersede October Patch Tuesday content; a quick inventory query for the post-OOB build numbers identifies stragglers. The known-side-effect of the patch — suppression of sync error reporting in the WSUS console — should be propagated to any internal operations runbook that depends on the in-console error detail; alternative monitoring (event log inspection, server-side WSUS log analysis) is recommended in the interim until Microsoft restores the reporting surface.
The strategic implication is harder to quote and easier to live with: in mid-2026, the burden of proof for keeping WSUS exposed to anything other than tightly scoped management traffic has shifted. CVE-2025-59287 is what shifted it. Architects asked to justify the current WSUS exposure surface in 2026 should expect the question; defensible answers exist (regulated workload, disconnected estate, ConfigMgr SUP plumbing) and they are narrower than they were before the OOB release.
Recommendation
The decision tree compresses to three cases and a rule of thumb.
For mature SCCM shops with no Intune presence and regulated workloads: no migration in 2026. The action is to harden the existing WSUS posture against CVE-2025-59287 (verified OOB patch on every WSUS host, no internet exposure on 8530 / 8531), validate any Server 2012 / 2012 R2 ESU paths against the September 2025 hardening KB, and place Azure Update Manager on the multi-year server-side roadmap. The Server 2025 lifecycle horizon of October 2034 is the planning anchor.
For already-co-managed shops with Intune licences in place: move the Windows Update workload slider. The pilot collection, the Dual Scan validation, the WUfB reports check are the concrete steps. WSUS continues to serve as ConfigMgr SUP plumbing; the host is not retired until ConfigMgr decouples SUP from WSUS, which Microsoft has not announced. For the server estate, evaluate AUM in scenarios where it is free — Defender for Servers Plan 2, Azure Local clusters, ESU enabled by Arc.
For greenfield estates or rebuild moments: skip WSUS for clients entirely. Intune + Autopatch for clients, Azure Update Manager for servers, third-party update tooling through Intune. ConfigMgr SUP — and therefore WSUS — only deploys if a specific architectural need (large legacy estate, OS imaging at scale with non-cloud sources) justifies it.
Rule of thumb. WSUS in mid-2026 is deprecated but not removed, hardened in incremental ways that quietly subtract surface area, and a known critical-exposure target as of October 2025. The decision is not whether to replace it. The decision is which workload to move to which product in which order, with the understanding that the Configuration Manager SUP and the disconnected-estate scenarios will keep WSUS in the picture for years past the headline announcement. The work in 2026 is to harden what is in production today and to budget for the licence positions that will eventually permit a full transition.
A blog author who lives in the SCCM and packaging world adds, in a single sentence: the deprecation announcement made the planning conversation possible, but it is the CVE-2025-59287 incident, not the announcement, that has actually changed how this product should be operated in 2026.
Sources: Microsoft Tech Community — Windows Server Update Services (WSUS) deprecation, Microsoft Learn — Features Removed or No Longer Developed in Windows Server, Microsoft Learn — Windows Server Update Services (WSUS) Overview, Microsoft Tech Community — Continuing WSUS support for driver synchronization, Microsoft Support — Hardening changes for WSUS in Windows Server 2025 (KB5067349), Microsoft Support — October 23, 2025 KB5070883 OOB (Server 2019), Microsoft Support — October 23, 2025 KB5070879 OOB (Server 23H2), NVD — CVE-2025-59287, Microsoft Learn — Azure Update Manager Overview, Microsoft Learn — Azure Update Manager FAQ, Microsoft Learn — What is Windows Autopatch?, Microsoft Learn — Integrate Windows Update client policies (Configuration Manager), Bleeping Computer — Microsoft officially deprecates WSUS, Bleeping Computer — Microsoft confirms WSUS sync is broken (July 2025), Help Net Security — Microsoft releases urgent fix for actively exploited WSUS vulnerability, Unit 42 — Microsoft WSUS RCE (CVE-2025-59287) Actively Exploited, Eye Security Research — WSUS Deserialization Exploit in the Wild, Huntress — Exploitation of WSUS Remote Code Execution Vulnerability, Patch My PC — WSUS Deprecation: Impact on Customers. All version, KB number, CVE, support-date, registry-value, and pricing references verified against the Microsoft Learn and Microsoft Support articles linked above. Last verified: 2026-06-08.