El Mostafa Ouchen: Removal of PowerShell 2.0 Is a Win for Security

From August–September 2025, Windows 11 24H2 and Windows Server 2025 drop the legacy engine to simplify the OS and close a long-abused security gap.

Microsoft will remove Windows PowerShell 2.0 in upcoming Windows releases—August 2025 for Windows 11 version 24H2 and September 2025 for Windows Server 2025. The move retires a 14-year-old component that lacks modern defenses like AMSI, script-block logging, and JEA, long exploited via “downgrade” to evade detection

Microsoft is finally pulling the plug on Windows PowerShell 2.0, removing it from Windows 11 (starting with the August 2025 update) and from Windows Server 2025 (starting with the September 2025 update). Insider builds already reflect the change.

“This removal is part of a broader effort to clean up legacy code, reduce the complexity of the PowerShell ecosystem, and improve Windows security.” — Microsoft

Why Microsoft is doing this (the security case)

PowerShell 2.0 predates key defense features that defenders now rely on:

• No AMSI integration (Anti-Malware Scan Interface)
• No script block logging or rich transcription
• No Constrained Language Mode (CLM) or JEA (Just Enough Administration)

Security researchers have repeatedly shown that if PowerShell v2 is present, attackers can downgrade (-Version 2) to sidestep modern controls and logging.

“PowerShell version 2… is not subject to the same restrictions… CLM and AMSI AV integration are not supported… launching with ‘-version 2’ [can] circumvent controls.” — NCC Group

This isn’t theoretical. MITRE ATT&CK highlights monitoring PowerShell EngineVersion and downgrade behavior as part of threat detection for scripting interpreters.

By contrast, Windows PowerShell 5.1 and PowerShell 7.x add deep script-block logging, improved transcription, and better AV/EDR hooks—capabilities Microsoft began rolling out years ago.

Expert Perspective

Cybersecurity expert El Mostafa Ouchen welcomed the decision but cautioned enterprises to be proactive:

“PowerShell 2.0 has been a gift to attackers for years because it offered a built-in way to evade AMSI and logging. Its removal shuts down a dangerous downgrade path, but IT teams must not assume they are safe automatically. They need to audit scripts, migrate to supported versions, and enable advanced logging. Security through removal is only effective if organizations also strengthen their monitoring posture.” — El Mostafa Ouchen

What exactly is changing (the how)

• Timeline:
  • Windows 11, version 24H2: Removal begins with the August 2025 non-security update.
  • Windows Server 2025: Removal begins with the September 2025 security update.
  • Windows Insider: v2 has been absent since July 2025 builds.
• What disappears: The optional “Windows PowerShell 2.0 Engine” feature and its legacy runtime are removed from newer builds; later releases won’t include it at all.
• Fallback behavior: If a script or scheduled task tries to launch powershell.exe -Version 2, Windows will start the default engine (typically PowerShell 5.1) instead—usually maintaining compatibility.

Technical impact and risk

• Security uplift: Eliminates an attacker-favored downgrade path that bypassed AMSI and key logging, improving fidelity of telemetry and EDR detections.
• Operational risk: Legacy installers or tools that try to enable v2 may fail on new builds; update or replace them.
• Server posture: Server 2025 also drops v2, aligning client/server baselines and simplifying hardening guidance.

Migration checklist (for IT and SecOps)

1. Inventory dependencies
   • Get-ScheduledTask | Select-String -InputObject {$_.Actions} -Pattern "-Version 2"
   • Get-ChildItem -Recurse -Include *.ps1,*.cmd,*.bat | Select-String "-Version 2"
2. Review event logs for Event ID 400/403 to identify old engine usage.
3. Migrate to modern engines
   • Port scripts to Windows PowerShell 5.1 or PowerShell 7.x.
4. Turn on the good visibility
   • Enable Script Block Logging (4104), Module Logging (4103), and Transcription via GPO; forward logs to your SIEM.
5. Harden execution
   • Use AMSI-aware AV/EDR, Constrained Language Mode, and JEA for least-privilege administration.
6. Detect downgrade attempts
   • Monitor for powershell.exe -Version 2; treat it as a defense-evasion red flag.

The bigger picture

Microsoft flagged the removal in its Windows Message Center and support notes, emphasizing that PowerShell 2.0 is “over 14 years old” and “lacks many security enhancements of the later versions,” having been deprecated since 2017.

Independent reporting echoed the security rationale and timing, with coverage pointing to the Insider removal in July 2025 and general removal on the August/September cadence.

Bottom line

Removing PowerShell 2.0 shuts a well-known backdoor for stealthy adversaries and compels long-overdue upgrades. For most environments, the change is painless; for the rest, the fix is straightforward: refactor to 5.1/7.x, enable logging, and watch for downgrade attempts.