Windows Deprecated Features: Track security-relevant removals and clear dependencies early

Microsoft is removing a run of legacy Windows components that attackers have relied on for years, and every removal is also a compatibility event that breaks some forgotten script, installer or line-of-business app. PowerShell 2.0 left Windows 11 version 24H2 from August 2025, NTLMv1 and DES are gone from 24H2 and Windows Server 2025, WMIC is no longer available even as a Feature on Demand, and VBScript is on a path to removal. This guide tracks the security-relevant deprecations and removals with the dates Microsoft publishes, explains what each change closes off for attackers, and gives a method to find and remove dependencies before Windows does it for you. It is for endpoint, Windows platform and security operations teams. It does not repeat the Windows Endpoint Hardening Guide; it covers the subset of hardening that Microsoft is now doing by removing code.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Deprecated is not removed. Microsoft defines a deprecated feature as no longer actively developed and possibly removed in a future update. Removal dates come later and are announced separately, so track both lists.
• Removal beats disabling. A disabled legacy component can be re-enabled by an attacker with admin rights; a removed one cannot be invoked. Get ahead of Microsoft by removing components yourself once dependencies are clear.
• PowerShell 2.0 removal closes a downgrade path. The 2.0 engine predates script block logging and AMSI. On Windows 11 24H2 and Server 2025, a request for -Version 2 now launches the default engine, PowerShell 5.1.
• Authentication protocols are on the list. NTLMv1 and DES are removed from 24H2 and Server 2025, and LANMAN, NTLMv1 and NTLMv2 are all deprecated in favour of Negotiate and Kerberos.
• Find dependencies with telemetry, not surveys. Process creation, PowerShell engine and logon events show what actually uses each component. Owners rarely know.

What is changing and why

Many components on Microsoft's deprecated list reflect older design assumptions: Microsoft itself describes Remote Mailslots as a "dated, simple, unreliable, insecure IPC method" and the Computer Browser service as "a dated and insecure device location protocol". Others are scripting and management tools that are heavily used in intrusions because they are present on every machine, such as VBScript (MITRE ATT&CK T1059.005), WMIC as a front end to Windows Management Instrumentation (T1047) and old PowerShell engines (T1059.001). Removing them shrinks the living-off-the-land toolkit described in the Living off the Land Guide.

Some removals are also about credentials. NTLMv1 responses can be cracked or relayed, and the NPLogonNotify and NPPasswordChangeNotify interfaces passed cleartext password payloads to network provider DLLs, which Microsoft now disables by default from 24H2. Where a removal touches authentication, it has an identity dimension, covered below.

Official timeline and current status

Dates below are from Microsoft's "Deprecated features for Windows client" page (last updated 23 September 2026), its "Features and functionality removed in Windows client" page (last updated 25 August 2026) and the PowerShell 2.0 removal support article, all checked on 8 November 2026. Microsoft's list states it might not include every affected feature.

Status note: removal dates apply to the Windows versions named. Windows 10 and earlier Windows Server releases keep many of these components until those products leave support; see the Operating System End of Life and Extended Support Guide. Microsoft revises these pages regularly, so recheck them before each feature update.

Who and what is affected

• Script estates: logon scripts, scheduled tasks and software deployment packages written in VBScript or calling wmic or powershell.exe -Version 2. Microsoft says scripts requesting version 2 now run under 5.1 and most keep working, but those depending on 2.0-specific behaviour may not.
• Legacy installers: Microsoft warns that older software may try to install or enable PowerShell 2.0 and that its installer may fail on Windows versions where the feature is missing.
• Old devices and appliances: NAS units, printers, scanners and line-of-business servers that authenticate with NTLMv1, use DES Kerberos keys, or only speak TLS 1.0 or 1.1.
• Remote access and isolation: organisations still using DirectAccess, Application Guard or Windows Information Protection lose a control they may have counted on in risk registers.
• Security tooling: detection rules that key on wmic.exe or wscript.exe will go quiet, which is good, but replacement activity will appear under PowerShell and needs coverage.

Where identity fits

Service accounts and machine credentials are often the last users of legacy protocols. A scanner that authenticates to a file share with NTLMv1, a backup job using a DES-enabled account, or a scheduled task running a VBScript under a domain service account will all fail after removal. Inventory these accounts as part of the migration, move them to gMSA or dMSA where possible, and retire the old ones. See the Windows Services and Service Account Security Guide.

Finding affected systems and identities

Use read-only telemetry for at least 30 days, ideally across a month-end, before deciding. The table lists the signal for each component.

Event 400 is logged in the Windows PowerShell classic event log when an engine starts and includes the engine version, which makes it the most reliable way to catch 2.0 use on systems that still have it. Correlate each hit with the host owner and the account that ran it, then tag the dependency in your CMDB.

Migration options

Small versus large estates: a small organisation can often remove components directly after a two-week audit, because the dependency list is short. A large estate should run the removal as a programme with a register of exceptions, each with an owner and an expiry date, and should not wait for a feature update to force the issue on thousands of devices at once.

Testing and rollback

1. Audit. Collect the telemetry above for 30 days or more and build the dependency register.
2. Fix or exempt. Remediate each dependency or record an exception with an owner, a compensating control and an expiry.
3. Pilot ring. Remove or disable the component on IT and security staff devices first, then a business pilot ring of 5 to 10 percent, using Intune or Group Policy so the change is centrally reversible.
4. Broad rings. Expand in rings, watching help desk tickets and the same telemetry for failures.
5. Prevent re-introduction. Use App Control for Business or AppLocker rules and configuration baselines so removed components and legacy protocols are not quietly re-enabled.

Rollback: for components you removed early, re-enable the optional feature or protocol on the affected ring only, with an expiry date. For components Microsoft has removed from 24H2 and Server 2025, rollback options are limited: for PowerShell 2.0 Microsoft documents only the temporary ps2DLC.zip reinstall, and for NTLMv1 and DES there is no supported return on those versions. That asymmetry is the reason to test before the feature update, not after.

Detection and measurement

• Hosts with PowerShell 2.0 engine starts (event 400 with engine version 2.0) in the last 30 days: target zero.
• Successful NTLMv1 logons per week across servers and domain controllers: target zero.
• Executions of wmic.exe, wscript.exe and cscript.exe per week, trending down to zero outside exceptions.
• Open exceptions in the deprecation register and the share past their expiry date.
• Devices on Windows versions where the removals apply, as a share of the estate.

Risks of doing nothing

• Forced breakage: the next feature update removes the component on Microsoft's schedule, and the broken script or device surfaces as an outage rather than a planned change.
• Attacker tooling stays available on older builds: Windows 10 and earlier server versions keep PowerShell 2.0, WMIC and VBScript, so downgrade and living-off-the-land techniques remain usable there.
• Credential exposure: NTLMv1 and DES on older systems keep credentials crackable and relayable (T1557.001, T1550.002).
• Phantom controls: risk registers that still list Application Guard or Windows Information Protection overstate protection on 24H2 devices where those features are gone.
• Detection gaps: rules tuned for old binaries miss the PowerShell and CIM equivalents attackers move to.

Common failure patterns

• Waiting for the feature update to discover dependencies, then rolling back the whole update instead of fixing one script.
• Reinstalling PowerShell 2.0 for one vendor tool across the whole estate and never removing it again.
• Disabling NTLMv1 on clients but not auditing servers and appliances that still accept it.
• Rewriting VBScript logon scripts without signing them or enforcing script control, so new PowerShell scripts are just as abusable.
• Deleting detections for WMIC and VBScript without adding equivalent coverage for PowerShell CIM activity.

Framework mapping

Practitioner checklist

• Subscribe to Microsoft's deprecated and removed features pages and review them before every Windows feature update.
• Collect PowerShell event 400, process creation and NTLM logon telemetry for at least 30 days.
• Build a deprecation register listing every dependency, its owner, its service account and an expiry date.
• Remove -Version 2 from scripts and scheduled tasks and test them on PowerShell 5.1.
• Rewrite WMIC calls with CIM cmdlets and plan VBScript replacement by owner.
• Eliminate NTLMv1 and DES use on servers and appliances, segmenting devices that cannot be fixed.
• Remove legacy components yourself in rings ahead of Microsoft, with App Control rules to stop re-introduction.
• Update risk registers that still rely on Application Guard, WIP or DirectAccess.

Standards and references

• Microsoft Learn: Deprecated features for Windows client
• Microsoft Learn: Features and functionality removed in Windows client
• Microsoft Support: PowerShell 2.0 removal from Windows
• MITRE ATT&CK: T1689 Downgrade Attack
• MITRE ATT&CK: T1059.005 Visual Basic
• MITRE ATT&CK: T1047 Windows Management Instrumentation
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · PowerShell Security Guide · NTLM Deprecation and Elimination Guide · VBScript Deprecation · Windows 11 Security Settings Guide