PowerShell 7.4 LTS reaches end of support on 10 November 2026. That part is not the trap. The trap is what a lot of teams did about it: they saw the deadline coming, pushed an upgrade to 7.5, and moved on. PowerShell 7.5 reaches end of support on the exact same day.
Nobody did anything wrong, technically. 7.5 is a real, newer release. It just happens to retire on the same calendar date as the version it was meant to replace, because the two versions are riding on completely different clocks underneath.
PowerShell 7.4 (LTS) and PowerShell 7.5 both reach end of support on 10 November 2026 - the same day, despite 7.5 being the newer release. That is because PowerShell inherits its support window from the .NET version it is built on: 7.4 runs on .NET 8 (a long-term support release), 7.5 runs on .NET 9 (a shorter-cycle release), and their clocks converge on the same date by coincidence, not by design. The only version with real runway past that date is PowerShell 7.6 (LTS), supported until November 2028.
The problem: "we already upgraded" doesn't mean what you think
Picture the conversation: someone flags that PowerShell 7.4 is heading out of support, a ticket gets raised, devices get moved to 7.5, the ticket gets closed. Six months later 7.5 is also out of support, on the same day 7.4 would have been, and nobody remembers closing that loop because it never felt like it needed reopening.
This isn't a version-numbering trick. 7.5 genuinely is newer than 7.4, with real fixes and features. It just was never going to outlive 7.4 by much, because Microsoft didn't build it on the same foundation.
Why it happens: PowerShell's clock is actually .NET's clock
PowerShell 7.x is a .NET application, and Microsoft's own lifecycle documentation says plainly that PowerShell follows the support lifecycle of the .NET version it's built on - it doesn't have an independent servicing clock of its own.
7.4 is built on .NET 8, which is a long-term support (LTS) release. 7.5 is built on .NET 9, which is a shorter-cycle release. Different foundations, different intended lifespans - they just happen to land on the same retirement date this time around.
| PowerShell version | Built on | End of support |
|---|---|---|
| 7.6 (LTS) | .NET 10 (LTS) | November 15, 2028 |
| 7.5 | .NET 9 | 10 November 2026 |
| 7.4 (LTS) | .NET 8 (LTS) | 10 November 2026 |
| 7.2 (LTS) | .NET 6 (LTS) | November 9, 2024 (already past) |
The pattern to notice: the LTS releases (7.2, 7.4, 7.6) are the ones built on LTS .NET versions, and they're the only ones that reliably buy you multi-year runway. Landing on a non-LTS release like 7.5 as your "stable" version is a choice that quietly resets your clock to whatever the shorter-lived .NET release underneath it is doing.
How to verify: find every version in the fleet
The version and the underlying .NET build are both visible from inside a PowerShell 7 session, on any single machine.
That output alone tells you whether a box is on the 7.4 line, the 7.5 line, or already on 7.6. Anything reading 7.4.x or 7.5.x is on the 10 November clock. Anything reading 7.3.x or earlier is already past its own end date.
The fix: move to 7.6, and test before you push it wide
- Confirm 7.6 is genuinely what you want. It's the current LTS line, built on .NET 10 (also LTS), supported until November 2028 - the longest runway available right now.
- Test script compatibility on a small pilot group first. A jump from 7.4 to 7.6 crosses two .NET major versions' worth of changes underneath, not one. Run your existing automation and any third-party modules against 7.6 before touching production.
- Deploy through whatever you already use to push software. PowerShell 7 ships as an MSI and is a normal Win32 app from Intune's point of view, or a standard application deployment through ConfigMgr - there's no special CSP or Group Policy path specific to PowerShell itself.
- Don't uninstall the old version until the new one is confirmed working on that device, since 7.x versions can coexist side by side if you need a rollback window.
$PSVersionTable.Proof it worked
Re-run the same version check after remediation. The target state is simple: nothing in the fleet still reports 7.4.x or 7.5.x, and everything on the 7.x line reports 7.6.x or later.
References
- PowerShell - Microsoft Lifecycle - the full release-by-release support table, including the 10 November 2026 date for both 7.4 and 7.5.
- PowerShell Support Lifecycle - Microsoft's own explanation of why PowerShell inherits its support window from the underlying .NET version.
- Differences between Windows PowerShell 5.1 and PowerShell 7.x - confirms the side-by-side install model referenced above.