The short version: every piece of software has a date after which its maker stops fixing it — including security holes. That date is its end of life (EOL). The software keeps running after EOL; it just stops being defended. Any flaw found after that date stays open forever, on every system still running it.

This guide assumes zero prior knowledge. By the end you'll be able to read any vendor lifecycle page without a translator.

The life of a piece of software

Every version moves through the same phases, whatever the vendor calls them:

The crucial point: software doesn't stop working at EOL. Nothing visibly breaks, so nothing prompts action — while security holes quietly accumulate. That's exactly what makes it dangerous.

The acronym decoder

• EOL (End of Life) — the maker stops all fixes. The big one.
• EOS — usually a synonym for EOL; occasionally "end of sale." Check which a vendor means.
• EOSL (End of Service Life) — the hardware version: switches, servers, storage.
• GA (General Availability) — the official release date. The lifecycle clock starts here.
• LTS (Long-Term Support) — a version promised support for years. What you run in production.
• STS — short-term support, for early adopters. Oracle calls these "Innovation Releases."
• ELS / ESU / ELTS — vendor names for paid post-EOL support (Red Hat / Microsoft / Debian respectively). Same idea, different logos.
• CVE (Common Vulnerabilities and Exposures) — the global ID system for security flaws (CVE-2026-12345).
• CVSS — the 0–10 severity score on each CVE. 9+ is critical.
• NVD — the US government's public catalog of all CVEs. Attackers read it too.
• KEV (Known Exploited Vulnerabilities) — CISA's list of CVEs actively used in real attacks.
• SBOM (Software Bill of Materials) — the ingredient list of your software. What makes EOL auditing possible at scale.
• SCA (Software Composition Analysis) — dependency scanners. Useful, but most don't flag EOL status.

What's actually in a "stack"?

Each layer has its own EOL clock. Bottom-up:

Operating system / distribution — Windows, macOS, or a Linux distro (Ubuntu, Debian, RHEL): the kernel plus thousands of tools, versioned and supported as one product. When Debian 12 hits EOL, the whole bundle stops getting coordinated fixes.

Runtime — the engine that executes your code. JavaScript needs Node.js; Python code needs the Python interpreter; Java needs the JDK. You don't write a runtime — you write code that runs on one. High-stakes EOL items, because runtimes process untrusted input.

Framework — a pre-built application skeleton: Django, Rails, Spring Boot, Laravel. A framework rides on a runtime — a Django app needs both Django and Python in support. Two clocks; either expiring exposes you.

Library / dependency — smaller building blocks pulled in by a package manager (npm, pip, Composer). Modern apps use hundreds. Each can be abandoned by its maintainer — EOL without a press release. (The classic distinction: your code calls a library; a framework calls your code.)

Database — PostgreSQL, MySQL, MongoDB. Holds the crown jewels; EOLs on long cycles, which lulls teams into forgetting it.

Containers & base images — FROM debian:12 bakes Debian 12's EOL clock into every container you build, even brand-new deployments.

Firmware/hardware — the layer organizations track least. See EOSL above.

How version numbers work

Most software uses major.minor.patch (Python 3.11.9). EOL almost always applies to the major.minor line — "Python 3.11 is EOL" means every 3.11.x, and no 3.11.10 will ever ship. Patch upgrades are routine hygiene; crossing minor/major lines is a migration. That's why teams pin versions — and why pinned versions quietly age into EOL.

Why this matters: the CVE blind spot

A zero-day is a flaw nobody knows about — scary but rare, and it gets patched once found. EOL software inverts this: the flaw is public — documented on the NVD, scored, often with exploit code on GitHub — but no patch will ever exist. Attackers don't need to discover anything; they read the CVE feed and check who's still running the EOL version.

Worse: most scanners give EOL software a clean bill of health, because they check for known unpatched CVEs — not for the fact that the patch pipeline itself is dead.

If you can't upgrade in time

Extended support keeps patches flowing past EOL. It comes from the maker (Red Hat ELS, Ubuntu Pro, Microsoft ESU) or from third parties such as TuxCare, which patch software the maker has abandoned entirely — CentOS being the canonical case, fully discontinued with no vendor program at all. Either way: it's a bridge to a planned migration, not a destination.

Where to start

Every layer of your stack has an expiry date, nothing announces itself when it passes, and the fix is knowing the dates before they arrive. Look up any of 455+ products free at endoflife.ai — or scan a whole dependency file at once with the Stack Scanner. No signup.