Home / Knowledge hub / End-of-life software
Knowledge hub
End-of-life software
Software its maker no longer supports, so new flaws stay unfixed.
What it means
End-of-life software is a product that its maker has stopped supporting. After the date, there are no more security fixes, and often no help from the vendor. Some makers call it end of support or end of service. Open-source projects publish their own schedules.
The software keeps running, which is why the problem is easy to ignore. Nothing breaks on the day. What changes is that every new flaw found from then on stays open for good, and anyone who reads the public advisory knows it.
Why it matters
Attackers watch for this. When a flaw is announced for a component that has no fix coming, every system still running it is a ready target, and automated tools find them at scale. The longer you stay, the more flaws pile up with no way to fix them.
It also hurts audits and contracts. Standards such as PCI DSS expect supported software, customers ask in security questionnaires, and insurers look for it. Replacing a core component is costly and slow, so a surprise here is expensive, and the cost lands at the worst moment.
How it shows up
It hides in dependencies more than in products. A framework version two releases behind, a language runtime past its end date, an operating system image in a container, a database nobody upgraded. Your SBOM and software composition analysis can list versions, and projects publish support dates.
Plan before the date. Track end dates in your asset inventory, budget upgrade work early, and move off in stages. If you cannot move, isolate the system, limit who can reach it, add a compensating control and set a replacement date. Some vendors sell paid extended support. That is a bridge and not a destination.
Questions people ask
End-of-life software, answered
What is the difference between end of life and end of support?
The terms are often used for the same moment. Some vendors separate them: end of life may mean the product is no longer sold, and end of support, no more fixes.
Read the vendor's own definition and dates.
Is end-of-life software always vulnerable?
It may have no known flaw today. But any flaw found later will not be fixed, and it ages quickly.
The risk is a standing one that grows with time.
Can we keep using it behind a firewall?
Network limits reduce exposure but do not remove it. Attackers who reach an inside system, or flaws reachable through your own web front end, still hit the old component.
Treat isolation as temporary.
What about open-source libraries?
Check the project's release and support policy. Many maintain only the latest versions, so an older release may get no fixes even without a formal end date.
An abandoned project is a similar risk.
How do we find what we run?
Inventory the systems, then check versions against vendor support pages. Dependency scanners flag components past their support dates.
Do it on a schedule, not once.
Sources
Where this comes from
Related
Terms that sit next to this one
Known-vulnerable component
A library or runtime with a published flaw that you are still shipping.
Patch management
The routine of tracking, testing and rolling out updates across your systems.
Dependency vulnerability
A known flaw in a library your application ships.
SBOM
A list of every component your application includes, with versions.
Asset inventory
A current list of the systems, apps and data you are responsible for.
What are you running past its date?
We test the running app, and in white-box mode we read the code and its dependencies, so an unsupported component that can actually be exploited shows up with proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.