Why End of Life Is Inevitable
Software does not die because vendors are careless or greedy. It dies because the forces that create it eventually turn against it. End of life is not a failure of process. It is the natural conclusion of how software is built, maintained, secured, and funded.
Understanding why EOL is inevitable is the difference between treating it as an occasional inconvenience and treating it as a permanent operating reality. This page lays out the five forces — with real dates and real CVEs, because an argument about software lifecycles should be held to the same standard as the lifecycles themselves.
1. The economics of maintenance always win
Every line of code carries a future cost. That cost compounds.
When a product is new, the team that built it still understands it. The architecture is fresh in their heads. The dependencies are current. The security model matches the threat landscape of the time. As years pass, three things happen simultaneously:
- The original engineers leave, get promoted, or move on.
- The surrounding ecosystem — operating systems, language runtimes, libraries, cloud services — continues to evolve.
- The threat landscape changes faster than the product can be updated.
At some point the cost of keeping an older version secure and compatible exceeds the revenue or strategic value of doing so. Vendors are not evil for making this calculation. They are rational. Supporting every historical version forever would eventually consume the entire engineering organization. No company can afford that.
This is why even the most well-funded vendors draw the line, on schedule, every year. Microsoft ended support for Windows 10 on October 14, 2025 — an operating system that still ran a large share of the world's desktops on its retirement day. The PHP project ends security support for PHP 8.2 on December 31, 2026. Node.js retired Node 18 on April 30, 2025; Python retired 3.9 on October 31, 2025, and 3.10 follows this October 31. The pattern is universal because the underlying economics are universal.
2. Security is a moving target
Software security is not a state you reach. It is a continuous race.
Attackers improve. New classes of vulnerabilities are discovered. Hardware side-channels appear. Cryptographic assumptions weaken. Supply-chain techniques evolve. A version of software that was considered robust in 2018 can be dangerously exposed in 2026 even if no new bugs were introduced in that specific codebase.
Vendors eventually stop issuing patches for older versions because the engineering effort required to back-port fixes safely becomes extreme. Supporting an old release often means maintaining an entire parallel universe of dependencies, compilers, and test infrastructure. At some point the risk of introducing regressions while back-porting exceeds the benefit of keeping that version alive.
This is why "it still works" is not the same as "it is still safe." A version that no longer receives security patches becomes a permanent vulnerability amplifier: every new CVE disclosed against it has no official remediation path, forever. That is not a rhetorical flourish — it is written into vendor advisories:
| CVE | Product | What happened | The vendor's own words for EOL versions |
|---|---|---|---|
| CVE-2024-37085 | VMware ESXi 7.0 | Authentication bypass exploited by ransomware operators (Akira, Black Basta); on CISA's KEV catalog | Broadcom's advisory matrix lists ESXi 7.0 as affected with fixed version "No Patch Planned" — the fix shipped only in 8.0 U3 |
| CVE-2025-68686 | FortiOS 7.0 / 6.4 | KEV-listed persistence weakness; FortiOS 7.0 left support Sep 30, 2025, and 6.4 on Sep 30, 2024 | Fortinet's only remediation for both branches: "Migrate to a fixed release" — no fixed build exists or will be published |
| CVE-2023-22518 | Confluence (pre-LTS lines) | CVSS 9.8 (Atlassian revised to 10.0) authorization bypass, mass-exploited by ransomware since November 2023 | Fixes shipped only on supported branches; every EOL line is affected with no fixed release |
These are three of the cases documented in our Exploited & Unpatchable feed — actively exploited CVEs where an end-of-life version is named as affected and the vendor's remediation is, in effect, stop running that version. The longer a version remains in production after EOL, the larger its permanently unpatched attack surface grows.
3. The dependency graph does not stand still
Modern software is not a single artifact. It is a graph of dependencies, each with its own lifecycle.
Your application depends on a language runtime. That runtime depends on system libraries. Those libraries depend on an operating system. The operating system depends on hardware firmware and cloud provider services. Any single node in that graph reaching end of life can force the entire stack forward — or leave it stranded.
The cleanest demonstration in recent memory: when CentOS shifted to the Stream model and CentOS 7 support ended on June 30, 2024, every application, script, and compliance posture built on it inherited a forced decision — RHEL, AlmaLinux, Rocky Linux, or a migration off the family entirely. Nobody running CentOS chose that fork in the road; the layer beneath them chose it. The same cascade is playing out right now for anyone on Debian 11, whose LTS window closes August 31, 2026 — nineteen days from this page's publication.
This cascading effect is why EOL is rarely isolated. When a major runtime dies, the frameworks built on it face pressure. When a widely-used OS version loses support, the applications running on it inherit the risk. Teams that try to freeze their stack eventually discover they are fighting the entire ecosystem — and the ecosystem does not lose.
4. Talent and knowledge decay
Code that is no longer actively developed becomes harder to understand.
Documentation ages. Tribal knowledge walks out the door. Architectural decisions that once made sense become opaque. When a critical vulnerability is discovered years later, the remaining engineers often lack the deep context required to patch it safely without introducing new problems.
This knowledge decay is one of the least discussed but most powerful drivers of EOL. Vendors do not only stop supporting old versions because of cost. They stop because the people who truly understood those versions are gone. It is also why back-porting gets riskier every year an old branch survives: the fix is written by people reconstructing decisions their predecessors made under constraints nobody remembers.
5. Innovation requires letting go
There is a strategic dimension as well.
Continuing to invest heavily in old major versions slows the ability to deliver new capabilities, performance improvements, and modern security models. At some point the opportunity cost becomes too high. Resources spent maintaining the past are resources not spent building the future.
This is why major version boundaries exist. They are not arbitrary. They represent the point at which the vendor has decided that the old architecture or compatibility guarantees are holding the product back. EOL is the formal acknowledgment of that decision — and the existence of a paid extended-support market, where vendors charge multiples of standard pricing to delay the inevitable, is the market's own measurement of exactly how expensive "not letting go" really is.
The practical consequence
Because EOL is inevitable, the only rational posture is to treat it as a permanent operational concern rather than a periodic surprise.
Organizations that handle this well do three things consistently:
- They maintain accurate, current visibility into the lifecycle status of every runtime, framework, operating system, and major dependency they run. (That is what our EOL Checker and product tracker exist for — 480+ products, dates verified against vendor sources.)
- They quantify the actual risk of remaining on versions that are approaching or past end of life, rather than relying on vague feelings of "it still works." (The EOL Risk Score™ does this per version: EOL recency, attack surface, CISA KEV exposure, and extended-support availability, recalculated at every site build.)
- They plan migrations on a schedule driven by risk and support timelines instead of waiting for a security incident or compliance failure to force the issue. (The EOL Watch and 2026 EOL calendar supply the timeline; a written end-of-life policy — free, CC BY 4.0 — turns it into something an auditor can verify.)
The alternative — discovering that a critical runtime has been unsupported for months or years only after a breach or an audit — is far more expensive than systematic tracking. The CVEs in the table above were each somebody's version of that discovery.
Closing
End of life is not a vendor failure. It is the predictable result of economic reality, security dynamics, dependency complexity, knowledge decay, and the need to keep innovating. Every piece of software you run today will eventually reach a point where official support ends. Most of the software you have ever run already has.
The question is never whether EOL will arrive. The question is whether you will see it coming with enough time and clarity to act deliberately — or whether you will encounter it as an emergency.
That difference is entirely operational.
Frequently Asked Questions
Why does software reach end of life?
Because the cost of keeping an old version secure and compatible eventually exceeds its value — to the vendor and to the ecosystem. Engineers who understood the code move on, the surrounding stack keeps evolving, and the threat landscape changes faster than an old branch can safely absorb back-ported fixes. Every vendor eventually draws the line: of the 26 Node.js release lines we track, only 3 are currently supported; of 47 tracked Windows versions, 13; of 18 PHP versions, 4. The pattern is universal because the economics are universal.
Is it safe to keep running end-of-life software if it still works?
Working and safe are different properties. An end-of-life version receives no security patches, so every new CVE disclosed against it has no official fix — permanently. When CVE-2024-37085 was exploited by ransomware groups against VMware ESXi, Broadcom's own advisory listed ESXi 7.0 as affected with fixed version "No Patch Planned." When Fortinet published FG-IR-25-934, its only remediation for FortiOS 7.0 and 6.4 — both past end of support — was "migrate to a fixed release." The longer an EOL version stays in production, the larger its permanently unpatched attack surface grows. Our Exploited & Unpatchable feed documents these cases as they occur.
What should organizations do about software end of life?
Treat it as a permanent operating reality rather than a periodic surprise: maintain current visibility into the lifecycle status of everything you run, quantify the actual risk of versions at or past EOL instead of relying on "it still works," and drive migrations from support timelines instead of incidents. A written end-of-life policy with risk tiers and remediation timelines turns those practices into something an auditor can verify.
Related
- The EOL Policy Template — free, vendor-neutral, CC BY 4.0; the operational answer to everything above
- Exploited & Unpatchable — actively exploited CVEs with no patch for EOL versions
- What extended support actually costs — the market price of postponing the inevitable
- The 2026 EOL Calendar — everything reaching end of life this year
- The RHEL minor-version trap — where lifecycle complexity gets real
- How the EOL Risk Score™ works · Check your stack now