End of Life Software the Scanner Keeps Flagging Replace or Isolate
Month after month, the same names sit at the bottom of the report: an old Java, a forgotten Flash-era leftover, Office from another decade, maybe a whole Windows version past its end. These are not patching failures. They are decisions nobody has made yet.
By Technical AnshuManageEngine Endpoint CentralFor IT Admins
Watch the full video — ManageEngine threat detection and patching, shown live on the console
Endpoint Central's high-risk software audit exists to surface exactly this: software that is unsafe, unauthorised or no longer supported by its vendor. End-of-life (EOL) software will never receive another security fix, so leaving it in the patch queue guarantees it appears in every report forever. The way out is a decision pipeline with three exits — remove, replace, or isolate — and a date on every exception.
High Risk Software Audit — Typical Findings (examples)
Old Java runtime, needed by nothing currentRemove
Office version past end of supportReplace
Windows build past end of servicingReplace (upgrade plan)
Vendor app abandoned, business still uses itIsolate + accept in writing
Unknown toolbar / bundled junkRemove today
Example audit rows. Notice most rows end quickly — the audit looks scarier than the decisions it asks for.
1
Exit 1 — Remove What Nobody Uses (Half the List Dies Here)
The most common finding is not dangerous software the business needs. It is software nobody has opened in years, kept only because nobody ever removed it.
Sort the audit by install count and last-used reality, not by fear — the runtime installed for one project in 2021 is the classic row
Check with the machine's user and the app owners: does anything current depend on this?
Uninstall centrally and watch the next scan — if nobody complains and nothing breaks in a month, it was never needed
Every removal is permanent risk reduction: no patching, no exception, no review date, forever
2
Exit 2 — Replace What the Business Actually Uses
Supported software doing real work gets a real plan: upgrade to the vendor's current version, or move to a maintained alternative.
Price both routes honestly — upgrade licence vs migration effort — including the training grumble factor for user-facing tools
Pilot the replacement on the same machines that run the old version hardest
Set the cut-over as a project with a date, and keep the EOL version's row in the report, labelled with that date, until it closes
For Windows builds past servicing: the replacement is the feature-update project — schedule it before the date passes, not after
3
Exit 3 — Isolate What Truly Cannot Move Yet
Occasionally the honest answer is: the business runs on it, the vendor is gone, and replacement is a quarter away, not a week. Then it gets the legacy treatment.
Move the software's machines behind the isolation controls: restricted network reach, no internet unless provably required, named accounts only
Remove the software from every machine that does not strictly need it — isolate the smallest possible footprint
Write the exception: software, machines, reason, controls, owner, expiry date — reviewed quarterly, not 'someday'
Start the replacement project in parallel; isolation buys time, it does not spend it for you
4
Stop It Refilling — Control What Gets Installed
An EOL list that only shrinks is a process working. One that refills every quarter is an install free-for-all.
Keep a short approved-software list and a simple request route — people install random tools when the official route is slower than Google
Re-run the high-risk software audit monthly alongside patch reporting; new unsupported or unauthorised software gets a conversation within the month
Procurement rule for anything new: if the vendor cannot state a support lifecycle, that is the answer about buying it
Honest note: an exception register is not a hiding place. Every 'isolate and accept' entry carries an expiry date and a named owner, and expired exceptions go back to the decision table — replace or remove. End-of-life software managed this way is a shrinking, owned list. Managed any other way, it is next year's breach report with the names already printed.
Watch the Complete Process in the Video
Threat detection, vulnerability scanning and patch deployment in ManageEngine — every step shown live, in the video linked below.
Why does the scanner keep flagging software that has no available patch?
Because flagging it is correct: unsupported software carries known vulnerabilities that will never be fixed. The flag is not asking for a patch — it is asking for a decision. Remove, replace, or isolate it, and record which one you chose.
Is end-of-life software really dangerous if it still works fine?
Working fine and being safe are different properties. The software runs exactly as it always did — including the vulnerabilities discovered since support ended, which attackers also know about. The risk grows every month even though the software never changes.
What if replacing the software is genuinely too expensive this year?
Then isolate it properly and register the exception with an owner and an expiry date tied to the budget cycle — with the replacement quoted, so next year's decision is a signature, not a research project. What you cannot do is leave it unisolated, unowned and unmentioned.
This guide is based on the ManageEngine threat detection and patching video by Technical Anshu • Stuck on a step? Ask in the video comments — answers happen there.