End-of-life (EOL) software is software whose maker has stopped supporting it. After the end-of-life date, there are no more security patches, no bug fixes, and no help if something goes wrong. The software keeps running, which is the problem. It carries on doing its job while the world around it keeps finding new ways to attack it, and nobody is fixing the holes.
This guide explains what EOL means, why it is a security risk that grows over time, how it hides inside modern systems, how to find it, and how to decide what to do with each case. It does not assume any prior background. If you have ever wondered why a server nobody touches for years can suddenly become the way into your network, this is the explanation.
What “end of life” actually means
Software goes through a lifecycle. The details vary between vendors, but the stages are broadly the same:
- Active support. The vendor ships new features, bug fixes, and security patches.
- Maintenance or security-only support. No new features, but security fixes still arrive.
- End of life (EOL), also called end of support (EOS). No more updates of any kind. Any flaw discovered from this point on stays unfixed.
- Extended support (sometimes offered). Some vendors sell paid, limited security patches for software past its end date, often at a high price and for a limited period.
The same logic applies to different kinds of software:
- Operating systems. Windows, Linux distributions, and others have defined support windows.
- Programming language runtimes. Old versions of Node.js, Python, Java, PHP, and similar eventually stop getting fixes.
- Frameworks and libraries. The packages your application depends on can go end of life, or simply be abandoned.
- Databases and middleware. Database engines, web servers, message brokers.
- Container base images and Kubernetes versions. An image built on an unsupported operating system carries that unsupported system into every container made from it.
- Hardware and firmware. Network devices and appliances whose firmware is no longer updated.
- Open source projects. Here “end of life” is often less formal. A project may be archived, declared unmaintained, or retired by its owner. Maintainers can simply walk away. The code remains public, but nobody is on call for its security.
A site such as endoflife.date tracks published end-of-life dates for many common products, and it is a handy reference when checking what you run.
Why EOL software is a security risk
New flaws keep being found, and none get fixed
Software is not a finished object. Researchers and attackers keep discovering vulnerabilities in code long after it is released, including in code that has been around for years. For supported software, each discovery leads to a patch. For EOL software, each discovery leads to a permanent hole. The longer the software stays in service past its end date, the more of these unfixed flaws pile up. The risk grows every month, even though nothing about your system has changed.
Attackers read the patches for supported versions
When a vendor releases a fix for a currently supported version, the fix reveals where the flaw was. Attackers compare the patched and unpatched code to understand the flaw. If your EOL version shares that code, as older versions usually do, the flaw exists in yours too, and now there is a published roadmap for exploiting it. But you will never receive the patch. This turns every fix for supported versions into a free hint against unsupported ones.
Known and exploited flaws stay exploitable
Many attacks do not rely on new discoveries at all. They use well-known flaws against systems nobody updated. The US government’s Known Exploited Vulnerabilities catalog lists flaws that are confirmed to be used in real attacks, and it includes flaws in products that are long past their end date. See what is the CISA KEV catalog. If your EOL software has an entry there, it is a matter of when, not whether, someone tries it on you.
There is no one to call
When something goes wrong with supported software, you can raise a ticket or read a security advisory. With EOL software, advisories may stop, and nobody is accountable. You are on your own for detection and fix.
It breaks compliance
Security standards and customer contracts expect you to run supported software and to patch known flaws. Running EOL systems can fail audits for frameworks such as PCI DSS and SOC 2, and fail vendor security questionnaires.
OWASP lists this problem as “Vulnerable and Outdated Components” in its Top 10, which is a good reference for how widespread it is.
EOL risk is multiplied by where the software sits
An EOL system on its own is a weakness. What turns it into a breach is what surrounds it. Three questions determine how serious a given case is:
- Is it reachable from the internet? An unsupported system on a private network is hard to attack from outside. The same system exposed publicly can be found by automated scanners within hours.
- Does it require authentication? Some old software, and some tools deployed quickly for testing, ship with no login or weak defaults. An exposed system with no login means anyone can use it.
- What can it reach once compromised? If the server holds powerful cloud credentials, has network access to databases, or stores secrets for other systems, the attacker inherits all of it. This is the blast radius.
The combination of exposed + unpatched + powerful is what you should look for first. It is the profile of a typical breach through an old system. For an example of how the third factor plays out, see how attackers use a compromised server to read cloud metadata credentials.
A recent illustration is the abandoned AI agent platform: an open source tool that its owner retired, left running on public servers by people who did not notice that support had ended, and then targeted by an exploit campaign. We cover it in how an abandoned AI agent server becomes a door to your cloud credentials. The software did not change. Its maintainers stopped looking after it, and attackers noticed before the users did.
Where EOL software hides
Most organizations do not knowingly run EOL software on purpose. They find it because it was never on a list. Typical hiding places:
- Forgotten servers and virtual machines. Set up for a project years ago, never decommissioned.
- Container images. An application image built once on an old base image and never rebuilt. The application code may be current while the operating system inside is not.
- Runtimes inside applications. A service still on an old language version because upgrading is “risky”.
- Transitive dependencies. A library your code uses depends on another library that depends on another. One of those may be abandoned. You never chose it, but you run it. A software bill of materials makes these visible. See what is SBOM and software composition analysis.
- Developer and AI tooling. Internal tools, workflow builders, notebook servers, and AI agent platforms deployed by a single team for a trial and left running. See shadow AI.
- Managed services with deprecation schedules. Cloud services also retire versions of databases, Kubernetes, and runtimes. These deadlines arrive whether or not you are watching.
- Third-party and vendor-supplied software. Something you did not build, installed on your infrastructure, that the vendor stopped updating.
How to find EOL software
You cannot manage what you cannot see. A practical approach has four parts.
- Build an asset inventory. Know every server, container, function, and service across your accounts. Cloud asset management is the foundation, because any EOL list begins with “what do we run?”.
- Record versions. For each asset, capture the operating system, runtime, key packages, and base image versions. Software bills of materials and image scans do this automatically.
- Compare against end-of-life dates. Match versions against published lifecycle data and flag anything past or approaching its end date. Treat “within six months” as a warning, not just “already expired”.
- Overlay exposure and permissions. Mark which flagged assets are internet-facing, unauthenticated, or attached to powerful identities. This tells you what to fix first.
Do the check regularly. EOL is a date that arrives automatically, and a system that was fine last year may be unsupported today.
What to do about it: five options
For each EOL asset you find, decide deliberately. Doing nothing is also a decision, but it should be made knowingly.
1. Upgrade
Move to a supported version. This is the real fix when it is feasible. It removes the unfixed flaws and puts you back on a patch path. Plan upgrades before the end date, not after.
2. Migrate
If the product itself is retired or abandoned, move to a supported alternative. This is more work than an upgrade but often the only path for abandoned open source tools.
3. Retire
If nothing needs the system any more, shut it down and remove it. This is the most commonly overlooked option and the best outcome. Every decommissioned system is attack surface you no longer have. Confirm that no one depends on it before switching it off.
4. Isolate and compensate
If you cannot upgrade or retire yet, reduce the risk while you plan. Compensating controls include:
- Remove it from the public internet or put it behind a VPN or authenticated gateway.
- Require authentication on anything that has none.
- Restrict network access so it can only reach what it must.
- Cut the permissions of its cloud identity to the minimum, and remove any stored credentials.
- Add monitoring for unusual behaviour from that host.
- Consider virtual patching with a web application firewall for known flaws. Treat this as a temporary measure.
This buys time. It does not make the software safe.
5. Buy extended support or formally accept the risk
Some vendors sell extended security updates. This can be reasonable for a defined period while migrating. If you accept the risk instead, record it: who accepted it, why, what controls are in place, and an expiry date for the exception. An exception without an end date becomes permanent.
Building a policy so it does not recur
- Maintain an EOL register with each asset, its end date, its owner, and its plan.
- Assign an owner to every system. Orphaned systems are the ones that go unpatched.
- Set lead times. For example, begin planning an upgrade 12 months before an end date.
- Make EOL a blocker in pipelines. Fail builds that use unsupported base images or runtimes, or at least warn loudly.
- Review new tooling before adoption. Ask whether the project is actively maintained, how fast it fixes vulnerabilities, and who backs it. Check for archived repositories and stale release histories.
- Include EOL in vulnerability management. A vulnerable component on an unsupported product cannot be fixed by patching, so it needs a different workflow. See what is vulnerability management and how to prioritize which CVEs to fix.
How EOL relates to other security topics
EOL is a source of long-lived vulnerabilities that sit inside your attack surface. It feeds software supply chain security, since dependencies you do not maintain become your risk. Prioritization tools such as EPSS help rank which flaws are likely to be exploited, which matters even more when no patch is coming.
How Cloudanix helps
Cloudanix cannot patch software that has no patch, and it cannot make an unsupported project supported again. Anyone who suggests otherwise is selling comfort. What it can do is find where EOL software lives, show how risky each case really is, and shrink the damage if it is compromised.
- Find it. The unified asset graph and cloud asset inventory show workloads across AWS, Azure and GCP in one place. Software composition analysis and SBOM generation in Code Security surface outdated and abandoned dependencies in your code, and container image scanning covers base images.
- Rank it by real risk. Vulnerabilities are correlated with internet exposure and the identity attached to the workload, and enriched with CISA KEV and EPSS data. An exploitable, exposed server with a powerful role rises above hundreds of low-risk findings. See attack path analysis.
- Reduce what it can reach. CIEM finds unused permissions on the identities attached to these workloads so they can be removed. Cloud JIT and Agentic JIT replace standing credentials with short-lived access.
- Detect misuse. Cloud detection and response and cloud UEBA flag an identity doing something it has never done, which is often the first sign a legacy host has been taken over.
The limits are straightforward. Cloudanix sees what is in the accounts and repositories you connect. A forgotten server in an account outside that scope will not appear. And the primary fix is still upgrading, migrating or retiring the software.
Frequently asked questions
What does end-of-life software mean?
It is software the vendor or maintainers no longer support. After the end date, there are no security patches or fixes, so any vulnerability discovered afterwards remains open.
What is the difference between end of life and end of support?
In practice the terms are used almost interchangeably. Some vendors use “end of support” for the date patches stop, and “end of life” for the final retirement of the product. Always read the vendor’s own lifecycle policy for the exact dates.
Why is EOL software dangerous if it still works?
Because working and being secure are different. New vulnerabilities keep being found, attackers compare patches for supported versions to learn how to attack unsupported ones, and none of the flaws get fixed in EOL software. The risk grows over time without any change on your side.
Is open source software with no recent updates the same as EOL?
Effectively, yes for security purposes. A project that is archived, unmaintained or retired may have no formal end-of-life date, but if nobody fixes vulnerabilities, it behaves like EOL software. Check commit activity, release history, and whether maintainers respond to security reports.
What should I fix first?
Start with EOL systems that are reachable from the internet, have no authentication, or are attached to powerful cloud identities. Those combine easy access with high impact.
Can I just put a firewall in front of EOL software?
A firewall or web application firewall can reduce exposure and block known attack patterns, and is a valid temporary measure. It does not remove the flaws and cannot catch everything. Treat it as buying time, with an upgrade, migration or retirement plan behind it.
How do I keep track of EOL dates?
Keep an asset and version inventory, compare it against published lifecycle dates (for example using endoflife.date and vendor policies), assign an owner to every system, and review the list on a schedule so deadlines do not surprise you.
