Dev.to Security 🔐 Cybersecurity 👁 0 📖 3 min read

Is Your Old Computer Still Safe? What Unsupported Windows Versions Mean for Your Business

The Windows box in the corner that runs the legacy app. The PC wired to the lab instrument. The machine that hosts a script nobody wants to migrate because "it just works". It boots every morning. Nobody complains. And

The Windows box in the corner that runs the legacy app. The PC wired to the lab instrument. The machine that hosts a script nobody wants to migrate because "it just works".

It boots every morning. Nobody complains. And that's exactly why it's dangerous.

"It still works" and "it's still safe" are two very different statements.

What "end of support" actually means

When Microsoft ends support for a Windows version, nothing visibly happens. No shutdown, no banner, no countdown. The machine just stops receiving security patches.

Here's where the common versions stand:

Version Support ended
Windows 7 January 2020
Windows 8.1 January 2023
Windows 10 October 14, 2025

Windows 10 has a paid Extended Security Updates (ESU) programme as a bridge. It's per-device, time-limited, and gets pricier over time, so think of it as a way to buy time rather than a plan.

Why unpatched Windows is a real problem

If you've read a CVE advisory, you know how this goes:

  1. A flaw is found and patched on supported versions.
  2. The patch and advisory make the flaw public.
  3. Attackers build exploits and scan for machines that never got the fix.

Supported systems are covered after step 1. Unsupported ones stay exposed to everything from step 2 onward, forever.

And the machine doesn't have to be valuable to be dangerous. It just has to be reachable. A single unpatched endpoint is a classic foothold for ransomware to move toward file servers, credentials, and backups.

Antivirus and EDR can detect and respond. They can't patch a vulnerable OS component.

Find what you actually have

You can't secure what you don't know about. For domain-joined machines:

Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' `
  -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
  Select-Object Name, OperatingSystem, OperatingSystemVersion, LastLogonDate |
  Sort-Object OperatingSystem |
  Export-Csv .\windows-inventory.csv -NoTypeInformation

For a single machine:

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber

Then go looking for the machines AD can't see: standalone PCs, kiosks, point-of-sale terminals, and anything attached to specialized equipment. The ones with a LastLogonDate from months ago are usually the forgotten ones, and the forgotten ones are the risky ones.

Can it run Windows 11?

Windows 11 needs TPM 2.0, Secure Boot, and a supported CPU. A quick local check:

Get-Tpm | Select-Object TpmPresent, TpmReady
Confirm-SecureBootUEFI

On legacy BIOS systems, it throws an error, which tells you something on its own. For the full answer, including CPU support, use Microsoft's PC Health Check app or your endpoint tool's readiness report.

Then sort every machine into one of three buckets:

  • Upgrade: meets the requirements, so upgrade in place
  • Replace: hardware can't run Windows 11, so budget for a new device.
  • Special case: tied to a legacy app or device, so contain it and plan

Contain what you can't replace yet

Some machines genuinely can't move today. Proprietary drivers, vendor lock-in, a tool that only runs on an old OS. If that's you, shrink the blast radius:

  • Put it on an isolated VLAN with strict ACLs.
  • Block outbound internet unless there's a documented need
  • No email, no browsing on that machine
  • Remove everyday admin rights and restrict logins
  • Keep backups offline or immutable.
  • Ship its logs somewhere central and alert on weird traffic

⚠️ This reduces risk. It doesn't remove it. Treat it as a seatbelt on a car with bad brakes: better than nothing, not a long-term plan.

Don't let "temporary" become "forever".

My favourite low-tech fix is an exception register. A simple table in your repo or wiki:

Hostname OS Why it can't move Owner Controls Review date
LAB-PC-01 Windows 7 Vendor driver J. Doe VLAN 40, no internet 2027-01-31

Every exception gets an owner and a review date. Without those, "we'll fix it next quarter" quietly turns into five years.

The non-technical argument (for when you need budget)

If you're making the case to management, these usually land:

  • Compliance: PCI DSS, HIPAA, and GDPR all expect reasonable patching.
  • Insurance: cyber insurers increasingly ask about unsupported systems.
  • Support drift: browsers and business apps eventually drop old Windows versions.
  • Productivity: old hardware crashes and lags, and the lost minutes add up.

A ransomware incident costs far more than a replacement cycle spread over a few quarters.

TL;DR

  1. Inventory everything, including the forgotten machines.
  2. Sort into Upgrade / Replace / Special Case
  3. Isolate what can't move, and write down who owns it.
  4. Replace on a schedule, starting with the most exposed machines.

Unsupported machines don't fail loudly. They sit there working while the risk grows. The fix is boring, and that's a good thing.

Have you dealt with a stubborn legacy Windows dependency? How did you handle it? Let me know in the comments. 👇

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.