End-of-Life Software in Vulnerability Reports: What to Do When There's No Patch Coming

Most findings in a vulnerability report have a fix: install the update, change the setting, restart the service. End-of-life software is different. When a vendor stops supporting a product, new vulnerabilities in it are still discovered, but nobody ships a patch. The finding will be on every report from now on until the system is upgraded, replaced or removed.

That makes end-of-life (EOL) software one of the most important things a report can point out, and one of the easiest to bury in a long list.

Why EOL deserves its own section

A missing patch is a task. An unsupported system is a decision. Treating it like one more finding causes three problems:

• It looks fixable when it isn't. A ticket that says "patch Windows Server 2012 R2" can't be closed, because there is nothing left to install.
• The real risk is understated. The scanner can only flag vulnerabilities that are already known. On an unsupported product, every new one found from now on stays open for good.
• The fix needs budget. Replacing a server or a line-of-business application is a project, and the client has to approve it. They can only do that if the report says so plainly.

How to spot it in a scan

Most scanners report unsupported software directly, with findings named along the lines of "Unsupported Version Detection" or "End of Life", often at critical severity. Look for them across:

• Operating systems: Windows 10 (mainstream support ended October 14, 2025, with paid Extended Security Updates available for a limited time), Windows Server 2012 and 2012 R2 (ended October 2023), and older Linux releases past their vendor's support window
• Server software: old versions of SQL Server, Exchange, PHP, Apache, OpenSSL and Java runtimes
• Network gear: firewalls, VPN appliances and switches whose firmware line the vendor no longer updates
• Applications: older browsers, PDF readers, and line-of-business software tied to an old runtime

Credentialed scans find far more of this than network-only scans, because the installed version is read directly instead of guessed from a banner.

Explaining it to a client

Keep it concrete and short:

Then give them the options, not just the problem:

Track it as a roadmap, not a ticket

EOL items move on budget cycles, not patch cycles. A short table at the end of each report works well: system, product and version, support end date, chosen option, owner and target date. Add products whose support ends within the next twelve months too, so the client can budget before the date arrives rather than after.

Then report progress the same way each time. "Unsupported systems: 7 last quarter, 4 now, 2 scheduled for replacement in January" is a line a client can follow, and it shows the work moving even when individual findings don't.

Don't let isolation become permanent

Isolating an unsupported system is a reasonable bridge. It is not a plan. Give every isolated EOL system a review date, check that the network rules are still in place at each scan, and raise it again if anything changes, such as the system becoming reachable from the internet or one of its vulnerabilities appearing on CISA's Known Exploited Vulnerabilities list.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports with prioritized actions. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Credentialed vs non-credentialed scans · Vulnerability assessment report template