DEV Community: endoflife-ai

MySQL 8.0 is now end-of-life — here's the version map you actually need

endoflife-ai — Thu, 18 Jun 2026 19:30:52 +0000

MySQL 8.0 reached end of life on April 30, 2026. That's the one that matters: 8.0 has been the default MySQL since 2018, so a huge share of production databases just stopped getting security patches from Oracle. If mysql:8.0 is anywhere in your stack, you're now running unsupported software.

Here's the version map, with EOL Risk Scores (0–100) from endoflife.ai:

Version	Type	EOL	Status	Risk
MySQL 5.5	Legacy	Dec 31, 2018	EOL	90
MySQL 5.6	Legacy	Feb 28, 2021	EOL	90
MySQL 5.7	Legacy	Oct 31, 2023	EOL	90
MySQL 8.0	Series	Apr 30, 2026	EOL	75
MySQL 8.4	LTS	Apr 30, 2032	Current LTS	50

The Innovation-vs-LTS trap

This is the part that catches people. In 2023 Oracle split MySQL into two release tracks, and the version number no longer tells you how long a release is supported.

LTS releases (currently 8.4) get ~8 years of support. This is what you run in production.
Innovation releases (8.1, 8.2, 8.3, and the entire 9.x series) ship quarterly and are supported only until the next release lands — roughly three months each.

So MySQL 9.2 looks newer than 8.4, but 8.4 is supported into 2032 while 9.2 went EOL within months. MySQL 9.0 reached EOL back in October 2024. If you adopted a 9.x release and aren't upgrading every single quarter, you're already on an EOL build with a Critical-tier risk profile.

Rule of thumb: unless quarterly upgrades are genuinely part of your ops model, stay on the LTS (8.4) and let the new features arrive in the next LTS.

What to do

On 8.0? Upgrade to 8.4 LTS — it's the supported, in-place path Oracle designed for exactly this transition.
On 5.7? Bigger jump. Plan straight to 8.4, using 8.0 as a compatibility checkpoint, not a destination. Watch the caching_sha2_password default, SQL mode changes, and the data dictionary migration.
Run the check first: mysqlsh → util.checkForServerUpgrade() against a staging copy surfaces deprecated syntax, removed features, and collation changes before you commit.
Managed MySQL (RDS, Aurora, Azure, Cloud SQL) tracks these dates differently — some extend past Oracle's community EOL, some don't. Confirm your provider's specific dates.

Check your whole stack, not just MySQL

MySQL is one clock. Your OS, runtime, and other dependencies each have their own. You can score your full dependency file at once with the free Stack Scanner (no signup), or read the complete version-by-version breakdown here:

Full guide: MySQL End-of-Life Dates — every version

Dates and risk scores sourced from the open endoflife.date dataset; risk scoring and CISA KEV cross-reference by endoflife.ai.

Every Software EOL Date That Matters in 2026 — One Reference

endoflife-ai — Mon, 15 Jun 2026 09:22:55 +0000

We maintain a full reference of 124 versions across 44 products — here are the dates that actually deserve a calendar reminder in 2026.

Just happened

Debian 12 "Bookworm" reached end of life on June 10, 2026. Regular security support has ended; the volunteer LTS team now covers only ~230 packages. If debian:12 is in your Dockerfiles, every image you build from here on has an EOL base layer. Action guide here.

The big dates still ahead in 2026

Date	What dies	Why it hurts
Sep 18, 2026	Oracle JDK 26	Short-lived non-LTS — teams that jumped early get caught
Sep 30, 2026	Java 17 LTS (Premier)	Still one of the most-deployed JDKs in production
Oct 31, 2026	Python 3.10	One of the most-used Python versions; 3.11 follows Oct 2027
Nov 9, 2026	Windows 11 23H2 (Enterprise)	The next Windows migration wave after the Win10 cliff
Dec 31, 2026	PHP 8.2	With 8.1 already EOL, only 8.3+ survives into 2027

Already EOL — and still everywhere

These are past their dates and still show up constantly in production scans:

Node.js 18 and 20 — both EOL (Apr 2025 / Apr 2026). Node 22 LTS is the floor now.
Spring Boot 2.7 — EOL since 2023, still the most common Spring version in legacy estates.
PHP 8.1 — EOL Dec 2025.
Veeam 11 & 12.0 — backup infrastructure running unpatched is its own special category of bad.
CentOS 7/8 — fully discontinued; no vendor to buy support from (third-party extended support is the only patch path).
Ubuntu 20.04 — out of standard support; Ubuntu Pro or migration.

The pattern worth internalizing

EOL events cluster. June 2026 alone had Debian 12, Debian 11 LTS (June 30), and Kubernetes versions aging out in the same window. If your stack touches five ecosystems, you have five independent clocks — and none of them email you.

The full sortable reference (124 versions, updated at every deploy, with risk scores and add-to-calendar reminders per product): endoflife.ai/article-eol-dates-2026

Or check your whole dependency file at once with the Stack Scanner — free, no signup.

EOL, EOS, LTS, CVE — Every Software Lifecycle Term, Explained Like You're New Here

endoflife-ai — Thu, 11 Jun 2026 22:02:14 +0000

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:

Phase	What it means	What you get
Release (GA)	Declared production-ready	Features, bug fixes, security patches
Active support	The healthy middle of life	Fixes and patches
Maintenance / security-only	The wind-down	Security patches only
End of life (EOL)	The maker walks away	Nothing, ever again
Extended support	Paid overtime	Security patches past EOL, for a price

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.

Oracle Database End-of-Life Dates — Premier & Extended Support for Every Version

endoflife-ai — Tue, 09 Jun 2026 16:47:56 +0000

If you've ever tried to answer the simple question "when does my Oracle Database version go end of life?" you've probably discovered there's no single date. Oracle doesn't do "EOL" the way Linux distros or runtimes do. Instead, every release moves through three support phases — and one of them sounds supportive but quietly leaves you with zero new security patches.

Here's the whole picture in plain language.

The short version: Oracle 19c is the safe long-term release (Premier Support to Dec 31, 2029, Extended to Dec 31, 2032). 23ai (now branded 26ai) is the newest long-term release. Oracle 18c, 12c, and 11g are all past support and receive only Sustaining Support — which means no new CVE patches.

The Oracle Lifetime Support table

Release	GA Release	Premier Support Ends	Extended Support Ends	Status
23ai / 26ai (LTR)	2023–2024	Dec 31, 2031	Available	✅ Active
21c (Innovation)	Aug 13, 2021	Jul 31, 2027	None	✅ Active
19c (LTR)	Apr 25, 2019	Dec 31, 2029	Dec 31, 2032	✅ Active · Recommended
18c	Jul 23, 2018	Jun 30, 2021	None	❌ EOL
12c Release 2 (12.2)	Mar 1, 2017	Mar 31, 2022	None	❌ EOL
12c Release 1 (12.1)	Jun 25, 2013	Jul 31, 2018	Jul 31, 2022	❌ EOL
11g Release 2	Sep 1, 2009	Jan 31, 2015	Dec 31, 2020	❌ EOL

The three phases (and the one that fools people)

Premier Support — the first ~5 years for a Long-Term Release. Full coverage: bug fixes, security patches, Critical Patch Updates, new certifications. This is what you want to be on.

Extended Support — an optional paid add-on, available only for Long-Term Releases, that extends full coverage for up to 3 more years. Oracle has sometimes waived the first year's fee. Innovation Releases (like 21c) don't get this at all.

Sustaining Support — offered indefinitely, which is exactly why it's misleading. It includes no new security patches, no bug fixes, no error corrections, and no new certifications — just access to patches that already existed and the knowledge base.

⚠️ This is the trap: Oracle can say a release is "still supported" when it's actually on Sustaining Support — getting no new CVE fixes. If you're past your Extended Support date, you are running unpatched. Your vulnerability scanner won't necessarily flag it, because the CVE affected-version ranges often don't list your ancient release. That's the CVE blind spot.

Long-Term vs Innovation Releases

Since 19c, Oracle splits releases into two tracks:

Long-Term Releases (LTR) — e.g. 19c and 23ai. ~5 years Premier + up to 3 years Extended. Standardize production here.
Innovation Releases — e.g. 21c. ~2 years Premier, no Extended. Great for kicking the tires on new features, bad for systems you'll run for years.

What about 23ai... 23c... 26ai?

Yes, the naming is a mess. It launched as 23c, was renamed 23ai to highlight its built-in AI features (like AI Vector Search), and the release line was later rebranded 26ai — while keeping 23 as the internal version number. It's a Long-Term Release with Premier Support through December 31, 2031, and it's the target if you want the longest runway on a new deployment.

If you're on 11g, 12c, or 18c

You've been running without new security fixes for years (11g since 2020, 12c since 2022, 18c since 2021). Your options:

Upgrade to a Long-Term Release — 19c (most proven) or 23ai (newest). Oracle's AutoUpgrade tool handles most paths.
Buy Extended Support — only available for LTRs (e.g. 19c through 2032), as a paid bridge while you migrate.
Third-party / Market-Driven Support — can patch versions Oracle no longer will, but it's a stopgap, not a destination.

Check your exact version with:

SELECT BANNER_FULL FROM V$VERSION;

TL;DR

If you're on 19c, you're fine until at least 2029. If you're on 18c, 12c, or 11g, you're effectively end of life and unpatched — plan a move to 19c or 23ai now.

I keep a live, always-updated version of this — with every Oracle Database version, its support phase, and a 0–100 EOL Risk Score — here: Oracle Database EOL dates on endoflife.ai. You can also check any other product (Node, Python, PHP, RHEL, Kubernetes, 450+ more) at endoflife.ai.

Your EOL Dates Are Deadlines. Now They Live on Your Calendar.

endoflife-ai — Sat, 06 Jun 2026 11:53:07 +0000

Originally published on endoflife.ai.

An end-of-life date is a deadline. On one side of it, your software receives security patches. On the other side, it does not — permanently. Every vulnerability discovered after that date is disclosed publicly, assigned a CVE, and frequently weaponized, with no fix ever coming from the vendor. This is the CVE blind spot, and it's the single most predictable security risk in any stack: you always know the exact day it begins.

And yet EOL dates slip past almost everyone. They don't trigger a scanner alert. They don't open a ticket. They aren't on anyone's sprint board. They are, quite literally, calendar events that nobody put on the calendar.

We just fixed that last part.

Add to Calendar, on every page

Every product page and version page on endoflife.ai that has a future end-of-life date now carries an Add to Calendar button, right under the status banner. One click downloads a standard calendar file (.ics) with the EOL date and three reminders already built in — 90, 30, and 7 days before the deadline. A second button drops the same event straight into Google Calendar.

It works in Apple Calendar, Outlook, and Google Calendar. There's no account, no email signup, and nothing to install — the reminders fire from your own calendar, on your own schedule, and keep working whether or not you ever return to the site. Open Node.js, PHP, Kubernetes, or any of 455+ products, pick the version you run, and the date is on your calendar in seconds.

Why 90 / 30 / 7?
The three reminders map to how migrations actually happen. 90 days out: scope the work, pick the target version, get it into a sprint. 30 days out: the migration should be in progress and testing. 7 days out: final verification — and if you're not done, time to stand up compensating controls and document them. The lead time is the difference between a planned upgrade and an emergency.

Lead time is a security control

The cost of an EOL migration is not fixed — it depends entirely on when you start. A move from Node.js 18 to a supported release, planned during a normal cycle, costs engineering time measured in days. The same move, started the week a critical CVE drops against the now-unpatchable version, costs that plus incident response, emergency change approvals, and the very real chance that an attacker got there first.

CISA puts it bluntly. Its catalog of cybersecurity Bad Practices lists the "use of unsupported (or end-of-life) software" as "dangerous and significantly elevates risk to national security, national economic security, and national public health and safety" — calling the practice "especially egregious in technologies accessible from the Internet." When the nation's cyber defense agency files something under bad practices, alongside default passwords and single-factor admin access, that's not a nudge. That's a line.

The exploitation timeline backs it up. Once a product is past EOL, any new vulnerability that lands in CISA's Known Exploited Vulnerabilities (KEV) catalog has, for you, no patch path at all — your only remediation is replacing the software outright. The earlier you see the date coming, the cheaper that replacement is.

Why auditors care about the date itself

Here's what surprises most teams: several major frameworks don't just frown on running EOL software — they require you to track lifecycle dates and hold a documented plan to act on them. The calendar reminder you just set is, in audit terms, evidence.

PCI DSS 4.0.1 — Requirement 12.3.4

The Payment Card Industry standard added a requirement aimed squarely at this. Requirement 12.3.4 mandates that all hardware and software in scope is reviewed at least once every 12 months to confirm it still receives security fixes from the vendor, to document any vendor "end of life" announcements, and to maintain a plan approved by senior management to remediate outdated technologies. It moved from best practice to mandatory on 31 March 2025, so it is now fully assessed. Requirement 6.3.3 separately requires that components be protected from known vulnerabilities via timely patching. A lifecycle calendar with lead-time reminders is precisely the artifact a QSA wants to see behind 12.3.4.

NIST SP 800-53 & FedRAMP — SA-22

Control SA-22, "Unsupported System Components," is explicit: organizations must replace components when vendor support ends, or formally arrange alternative support. Paired with SI-2 (flaw remediation), it gives assessors a direct hook. Because FedRAMP inherits the 800-53 baseline, any cloud service serving the U.S. government carries SA-22 as well — and an unsupported component without a plan becomes a POA&M item.

ISO 27001:2022 — Annex A 8.8

Control 8.8, "Management of technical vulnerabilities," was strengthened in the 2022 revision to emphasize a proactive process: maintain an asset inventory with version numbers, obtain timely information about vulnerabilities, and act. Software for which no patch can ever exist is a structural failure of exactly that control.

SOC 2 — Trust Services Criteria CC7.1

SOC 2 names no specific technologies; it tests whether your controls fit your risks. Criterion CC7.1 covers detecting new vulnerabilities and susceptibilities. An auditor will ask how you identify them — and if your answer has no process for tracking software end-of-life, that's a gap. If EOL software is then found running, the gap becomes a finding.

HIPAA Security Rule

For ePHI, the HIPAA Security Rule requires a risk analysis (45 CFR §164.308) and technical safeguards (§164.312). NIST's implementation guide, SP 800-66 Revision 2 (February 2024), frames unsupported software as an identifiable, manageable risk. OCR's enforcement consistently ties penalty severity to whether an organization knew about a risk and failed to act — which makes knowingly running EOL software the worse position to be in.

The pattern across every framework
None of these require perfect, always-current software. They require that you know your lifecycle risks and manage them deliberately — with awareness, a plan, and a timeline. EOL software that's documented, compensated, and scheduled for remediation is a managed risk. EOL software you didn't see coming is a finding.

Framework / Body	Control	What it expects regarding EOL	Severity
PCI DSS 4.0.1	Req. 12.3.4, 6.3.3	Annual review for EOL/vendor support + senior-approved remediation plan (mandatory since Mar 2025)	Critical
NIST 800-53 / FedRAMP	SA-22, SI-2	Replace unsupported components or arrange alternative support; POA&M if not	Critical
ISO 27001:2022	Annex A 8.8	Proactive vulnerability management with versioned asset inventory	High
SOC 2	TSC CC7.1	A process to detect new vulnerabilities, including lifecycle tracking	High
HIPAA	§164.308, §164.312	Risk analysis covering unsupported software; known-and-unaddressed risk raises OCR exposure	Critical
CISA	Bad Practices · KEV · BOD 22-01	EOL software named a "bad practice"; KEV entries carry fixed remediation deadlines	Critical

The reach extends beyond U.S. frameworks. The EU's GDPR Article 32 requires security measures appropriate to "the state of the art" — a standard that running years-past-EOL software plainly undercuts. For financial entities, the EU's DORA regulation (in force since January 2025) and the NIS2 Directive both impose ICT lifecycle and vulnerability-management obligations in the same spirit.

From a date to a defensible plan

A calendar reminder is the trigger. Here's the workflow it plugs into:

Know — Inventory your stack. Use the Stack Scanner on your package.json, requirements.txt, Gemfile, or container base images to map what you actually run against current EOL dates.
Prioritize — Score the risk. The EOL Risk Score weighs EOL recency, attack surface, CISA KEV exposure, and extended-support availability so you triage the dangerous components first.
Schedule — Put the dates on the calendar. For every version you depend on, hit Add to Calendar on its page. The 90/30/7-day reminders become your standing remediation timeline — the documented plan auditors ask to see.
Automate — Scale it. The endoflife.ai API exposes EOL dates for 455+ products programmatically, so you can wire lifecycle alerts into CI/CD, SBOM tooling, or your own dashboards.

The date was never the hard part. EOL dates are published years in advance; that's the entire premise of endoflife.date, the open dataset this site is built on. The hard part has always been not seeing it coming — letting a known deadline pass in silence until it surfaces as an incident, an audit finding, or both.

Now the deadline shows up where you'll actually see it: on your calendar, with enough warning to do something about it.

Check any of 455+ products, see its EOL Risk Score, and add the deadline to your calendar — free, no signup, at endoflife.ai.

My Software Is EOL — What Do I Do Now?

endoflife-ai — Thu, 04 Jun 2026 14:53:08 +0000

You just found out a runtime, OS, or framework you're running is end-of-life. No more patches. No more security fixes. Here's exactly what that means, how bad it is, and what your options are — in plain language.

The situation: End-of-life means the vendor has stopped issuing security patches. Every new vulnerability disclosed after that date is permanently unpatched in your version. Your scanner will likely show a clean bill of health. Attackers know your version is unpatched. You don't.

First: Don't panic. But don't ignore it either.

Finding out your software is EOL is not an emergency in the same way a breach is. Your systems aren't on fire. But you are running with an open window — and every day that passes, more vulnerabilities accumulate with no fix path.

The right response is urgency without panic. Assess quickly, decide deliberately, act.

Step one: Understand what you're actually dealing with

Not all EOL situations are equal. A Node.js version that went EOL last week is a very different risk profile from an OS that's been unpatched for three years. Before you do anything else, know your actual risk.

1. How long has it been EOL?
Days to weeks is a low-urgency window. Months to years means significant CVE accumulation with no patches. The longer past EOL, the higher the risk.

2. What attack surface does it expose?
An EOL operating system or runtime processing internet traffic is critical. An EOL internal utility with no network exposure is a much lower priority.

3. Is it in the CISA KEV catalog?
The CISA Known Exploited Vulnerabilities catalog lists software being actively exploited in the wild. If your EOL product appears there, your urgency level just went to critical.

4. What are your compliance obligations?
SOC 2, PCI DSS, HIPAA, and ISO 27001 all have controls around unsupported software. Running EOL in a compliance-relevant environment creates audit findings and potential liability.

Quick check: Look up your exact product and version on endoflife.ai. You'll see the EOL date, days past EOL, CISA KEV exposure, and a 0–100 risk score that tells you how urgently to act.

The CVE blind spot: why your scanner isn't telling you the full story

Here's what most people don't know: your vulnerability scanner is almost certainly giving you a false sense of security.

When a vulnerability is discovered, security researchers test and report it against supported versions. The CVE advisory lists affected version ranges based on supported builds. Your EOL version runs the same code — often with the identical vulnerability — but it doesn't appear in the advisory because nobody tested it.

Your scanner checks CVE affected version ranges. Your EOL version isn't listed. No alert fires. You see a green dashboard. You think you're safe. You're not.

Attackers read the same CVE advisories. They diff the patches. They test EOL builds systematically. They know your version is vulnerable before your scanner does — and they know it will stay that way.

Your four options — and when each makes sense

Option 1: Migrate to a supported version (Best long-term)

The right answer. Upgrade to the current stable release. Eliminates the risk permanently. Requires testing, potentially dependency updates, and downtime planning. This is where you want to land — the question is how fast you can get there.

Option 2: Extended lifecycle support (Fastest risk reduction)

Commercial vendors provide security patches for EOL software — same CVE coverage, no migration required. Buys you time to migrate properly while closing the patch gap. Costs money but often cheaper than an emergency migration.

Option 3: Compensating controls (Reduces exposure)

If you can't patch or migrate immediately, isolate the affected system. Restrict network access, add WAF rules, increase monitoring, segment from critical systems. Doesn't fix the vulnerability — just reduces the blast radius if something goes wrong.

Option 4: Accept and document the risk (Sometimes valid)

In some cases — low attack surface, isolated environment, very recent EOL — formal risk acceptance with a documented remediation timeline is appropriate. This is not "do nothing." It's a deliberate, recorded decision with an owner and a deadline.

The questions your team will ask — answered

How do I know if we've already been compromised?
EOL status alone doesn't tell you whether you've been breached — it tells you that you've been running with an unlocked door. Check your logs for unusual activity, review access patterns, and loop in your security team. The EOL finding is a trigger for a security review, not necessarily evidence of a breach.

Do I need to tell anyone?
If you're in a regulated environment — healthcare, finance, government — the answer is almost certainly yes. Notify your security team, your compliance officer, and potentially your legal team. Document when you discovered it and what actions you took. That paper trail matters in an audit or incident.

How long do I actually have?
There's no universal answer. A Node.js version that went EOL last month is lower urgency than a CentOS 7 server that's been unpatched since June 2024. Check the EOL Risk Score for your specific version — it factors in time since EOL, attack surface, and active exploitation history to give you a calibrated number, not just a binary warning.

Can I just leave it and see what happens?
You can. Plenty of organizations run EOL software for extended periods without incident. But you're making a bet that attackers won't target your specific version before you get around to fixing it — and that bet gets worse every day.

What's the difference between EOL and end-of-support?
Often used interchangeably, but there's a distinction. End-of-life typically means the product is fully discontinued — no patches, no support. End-of-support sometimes means the vendor will still take bug reports but won't actively develop new features. For security purposes, treat both the same way: if security patches aren't coming, you're exposed.

How to prioritize when everything is EOL

If you've just run a full audit and found multiple EOL products — which is common — prioritize by:

Internet-facing systems first — EOL software processing external HTTP traffic or exposed to the public internet is your highest priority.
CISA KEV-listed products next — confirmed exploitation is happening in the wild. These jump the queue.
Longest past EOL next — the longer a product has been unpatched, the more vulnerabilities have accumulated.
Compliance-critical systems last — systems in scope for SOC 2, PCI, HIPAA audits need to be clean before your next assessment cycle.

The conversation with your manager or board

Don't lead with the technical detail. "We're running Node.js 18 which went EOL in April 2025" means nothing to a non-technical executive.

Do lead with the analogy. "We're running software that no longer receives security patches. It's the equivalent of running a building with a lock the manufacturer has stopped making keys for — and the lock design is publicly documented." That lands.

Come with options and costs. Don't just bring a problem. Bring three options: migrate (timeline and cost), extended support (monthly cost, immediate risk reduction), or accept and document (risk in plain language). Let the decision-maker decide — but make sure they understand what they're deciding.

The bottom line: EOL software is a solvable problem. The risk is real but it's not a crisis unless you ignore it. Find out exactly what you're running, score the risk, pick your path, and move.

Check your stack

endoflife.ai — free EOL intelligence for 455+ products. Check any runtime, framework, OS, or database against its EOL date. No account required.

Apache Kafka End of Life: Kafka Versions EOL Every 4 Months — Are You Behind?

endoflife-ai — Sat, 30 May 2026 05:25:16 +0000

Apache Kafka's release cadence is fast. A new minor version ships roughly every four months. EOL dates arrive quickly — and because Kafka sits at the heart of data pipelines, teams are slower to upgrade than they are with application-layer software.

The result: a lot of production Kafka clusters running EOL versions handling compliance-critical data.

Kafka 3.6 reached end of life in April 2026. If you're on 3.5 or earlier, you're already past EOL.

Complete Kafka EOL Schedule

Version	End of Life	Status
Kafka 2.8	Oct 2023	❌ EOL
Kafka 3.0	Feb 2024	❌ EOL
Kafka 3.1	Jul 2024	❌ EOL
Kafka 3.2	Oct 2024	❌ EOL
Kafka 3.3	Feb 2025	❌ EOL
Kafka 3.4	Sep 2025	❌ EOL
Kafka 3.5	Dec 2025	❌ EOL
Kafka 3.6	Apr 2026	❌ EOL
Kafka 3.7	Sep 2026	✅ Supported
Kafka 3.8	Mar 2027	✅ Supported
Kafka 4.0	TBD	✅ Latest

The community maintains the two most recent minor versions. Everything else receives no further security patches or bug fixes.

EOL Risk Score for Kafka 2.8: 84 Critical
View → endoflife.ai/score/apache-kafka/2.8

Why Kafka EOL Risk Is Different

Kafka isn't stateless. It stores your data.

An EOL web framework is a security risk. An EOL Kafka cluster is a security risk that also has custody of every message in your topics. CVEs affecting Kafka directly impact the confidentiality, integrity, and availability of your event streams.

Historically significant Kafka CVEs include:

Authentication bypass vulnerabilities
SCRAM authentication weaknesses
Denial-of-service issues in the broker's request handling

In regulated industries — financial services, healthcare, any organization handling PII — an EOL Kafka cluster processing that data creates direct compliance exposure.

The ZooKeeper Story: The Biggest Change in Kafka's History

Kafka 4.0, released March 2025, removed ZooKeeper support entirely.

The timeline:

Kafka 2.8 — KRaft mode introduced as early access
Kafka 3.3 — KRaft mode production-ready
Kafka 3.5–3.8 — ZooKeeper deprecated, migration tooling available
Kafka 4.0 — ZooKeeper removed, KRaft required

If your cluster still uses ZooKeeper for cluster metadata, you cannot upgrade to Kafka 4.0 without first migrating to KRaft. And ZooKeeper itself has its own EOL considerations: ZooKeeper 3.6 reached EOL March 2024.

How to migrate ZooKeeper → KRaft (without downtime)

Kafka 3.7 and 3.8 support a live migration path:

# 1. Generate a new KRaft cluster ID
kafka-storage.sh random-uuid

# 2. Start the migration using the built-in migration tool
kafka-metadata-migration.sh --bootstrap-server localhost:9092   --cluster-id <your-kraft-cluster-id>

The migration runs while the cluster continues serving traffic. Once complete, the ZooKeeper ensemble can be decommissioned.

Kafka Rolling Upgrade Guide

Kafka supports rolling upgrades — upgrade brokers one at a time while the cluster continues serving traffic.

Step 1 — Control the protocol version

During a rolling upgrade, pin inter.broker.protocol.version to the previous version:

inter.broker.protocol.version=3.7

Only bump this after all brokers are on the new version. This allows mixed-version brokers to communicate safely during the upgrade window.

Step 2 — Upgrade one broker at a time

# Graceful shutdown of one broker
kafka-server-stop.sh

# Install new version, update config, restart
kafka-server-start.sh config/server.properties

Wait for the broker to rejoin and partition leadership to rebalance before proceeding to the next broker.

Step 3 — Update the protocol version

After all brokers are upgraded:

inter.broker.protocol.version=3.8  # your new version

Rolling restart to apply.

Step 4 — Check client compatibility

The Kafka protocol is backward-compatible, but broker upgrades may surface client-side issues. Update producers and consumers as part of the upgrade project, not after.

Check Your Full Data Stack

Kafka doesn't run in isolation. Check EOL status for:

Java — Kafka 4.0 requires Java 11+, recommends Java 17 or 21
Your Linux distribution — Ubuntu, RHEL, Debian all have EOL dates
ZooKeeper — if you're still on it
Kafka Connect plugins — each has its own version lifecycle

Use the EOL Checker at endoflife.ai to look up any component's EOL status.

Full article with EOL Risk Scores for every Kafka version: endoflife.ai/article-kafka-eol

Ruby on Rails End of Life: Rails 6.1 EOL, Rails 7.0 EOL — What's Still Supported in 2026

endoflife-ai — Sat, 30 May 2026 05:24:12 +0000

The Rails maintenance policy is lean by design: only the most recent minor version of the most recent two major versions receives security patches. Everything else is on its own.

That policy creates a faster EOL cadence than most teams expect. Rails 7.0 felt modern — it shipped with Hotwire, import maps, and CSS bundling. It reached end of life on April 1, 2025.

Here's the current state of the Rails lifecycle.

Rails EOL Schedule

Version	End of Life	Status
Rails 4.2	Apr 2020	❌ EOL
Rails 5.2	Jun 2022	❌ EOL
Rails 6.0	Jun 2023	❌ EOL
Rails 6.1	Jun 30, 2024	❌ EOL
Rails 7.0	Apr 1, 2025	❌ EOL
Rails 7.1	Oct 1, 2026	⚠️ Security only
Rails 7.2	Aug 1, 2027	✅ Full support
Rails 8.0	Nov 1, 2027	✅ Full support

The Compounding Ruby Problem

Rails 6.x applications typically run on Ruby 2.6, 2.7, or 3.0. All three are EOL:

Ruby 2.6 — EOL March 2022
Ruby 2.7 — EOL March 2023
Ruby 3.0 — EOL March 2024

A Rails 6.1 application on Ruby 2.7 has two compounding EOL layers. New CVEs in either the framework or the runtime will never be patched.

EOL Risk Score for Rails 6.1: 82 Critical
View → endoflife.ai/score/rails/6.1

Understanding the Rails Maintenance Policy

The Rails project publishes three maintenance states:

Full maintenance — bug fixes + security fixes (latest two minor versions)
Security maintenance only — security fixes only, no bug fixes
Unsupported — no fixes of any kind

Today:

Rails 8.0 — full maintenance
Rails 7.2 — full maintenance
Rails 7.1 — security maintenance only until October 2026
Rails 7.0 and earlier — unsupported

What's New in Rails 8

Rails 8.0 (November 2024) is a significant release focused on reducing external infrastructure dependencies:

Solid Cache — database-backed caching (replaces Redis for most use cases)
Solid Queue — database-backed background jobs (replaces Sidekiq for most use cases)
Solid Cable — database-backed WebSockets
Kamal 2 — container-based deployment built in
Thruster — HTTP asset caching and compression proxy

Rails 8 requires Ruby 3.2 or later. If you're on Ruby 3.1 or earlier, upgrade Ruby first.

Upgrade Strategy: One Minor Version at a Time

The Rails team's official guidance is to upgrade incrementally:

6.0 → 6.1 → 7.0 → 7.1 → 7.2 → 8.0

Each minor version includes deprecation warnings for APIs removed in the next version. Skipping versions means missing those warnings and hitting breaking changes blind.

Key steps for any Rails upgrade

1. Check your Ruby version first
Rails 7.2 requires Ruby 3.1+. Rails 8 requires Ruby 3.2+. Upgrade Ruby before upgrading Rails.

ruby --version

2. Use the load_defaults incremental approach
After bumping the gem version, update config/application.rb:

config.load_defaults 7.2  # or whatever your target version is

This activates new defaults gradually. Address each failure before moving to the next.

3. Follow the official upgrade guide
Every Rails version has a dedicated upgrade guide documenting every breaking change.

4. Run your test suite on the new version before deploying
Rails CI should be your gate. If it passes on the target version in CI, production follows cleanly.

Rails CVE History: Not Theoretical

Rails has had real, high-severity CVEs over its lifetime:

SQL injection through unsafe query parameter handling
CSRF vulnerabilities in earlier action controller versions
Mass assignment bypass (the Egor Homakov GitHub hack)
Regex injection in route handling

The framework's security has improved significantly since the Rails 3/4 era, but CVEs are still disclosed. On an EOL version, those CVEs are never patched.

Check Your Dependencies Too

Your Rails version isn't the only thing with an EOL date. Check:

Full article with EOL Risk Scores for every Rails version: endoflife.ai/article-rails-eol

CentOS is Dead: CentOS 7 EOL June 2024, CentOS 8 EOL Dec 2021 — Your Migration Options

endoflife-ai — Sat, 30 May 2026 05:23:43 +0000

CentOS was the backbone of enterprise Linux infrastructure for nearly two decades. Free. Stable. Binary-compatible with RHEL. The obvious choice for teams that wanted enterprise Linux without the enterprise price tag.

It's now, definitively, dead.

CentOS Linux 8 reached end of life December 31, 2021
CentOS Linux 7 reached end of life June 30, 2024

There are no supported CentOS Linux versions remaining.

The Full CentOS EOL Timeline

Version	End of Life	Status	EOL Risk Score
CentOS Linux 6	Nov 30, 2020	❌ EOL	97 Critical
CentOS Linux 7	Jun 30, 2024	❌ EOL	85 Critical
CentOS Linux 8	Dec 31, 2021	❌ EOL	89 Critical
CentOS Stream 8	May 31, 2024	❌ EOL	82 Critical
CentOS Stream 9	May 31, 2027	✅ Supported	22 Low
CentOS Stream 10	TBD	✅ Supported	10 Low

CentOS 8: The Betrayal

CentOS 8's EOL story is different from any other software EOL — and worse.

Red Hat announced in December 2020 that CentOS Linux 8 would reach end of life on December 31, 2021, cutting short what was originally a 10-year lifecycle. The announcement came less than 18 months after CentOS 8's initial release.

Teams that had migrated to CentOS 8 to modernize their infrastructure found themselves holding an EOL operating system less than two years after deploying it. Many of those servers are still running today — over four years past EOL.

EOL Risk Score for CentOS 8: 89 Critical

CentOS 7: The Compounding EOL Problem

CentOS 7 is a unique case study in layered EOL risk.

The OS itself reached EOL June 30, 2024. But look at what else is EOL inside a default CentOS 7 install:

Kernel 3.10 — EOL for years
Python 2.7 — EOL since January 2020
OpenSSL 1.0.2 — EOL since December 2019
glibc 2.17 — outdated, no upstream patches

Servers running CentOS 7 are EOL at the OS level, kernel level, runtime level, and cryptography library level simultaneously. Every new CVE in any of these components is permanently unpatched.

EOL Risk Score for CentOS 7: 85 Critical

CentOS Stream is NOT a Replacement

This is the most important clarification to make.

CentOS Stream is a rolling pre-release distribution that sits upstream of RHEL. Where CentOS Linux was a downstream rebuild of RHEL (stable, tested, binary-compatible), CentOS Stream receives updates before those updates are released in RHEL.

That means CentOS Stream may contain bugs that are later fixed before the RHEL release. It is a development preview — useful for testing, not ideal for stable production workloads that previously ran CentOS Linux.

Migration Options

AlmaLinux OS

Free, community-supported, RHEL binary-compatible rebuild maintained by the AlmaLinux OS Foundation.

AlmaLinux 8: supported through May 2029
AlmaLinux 9: supported through May 2032
Provides almalinux-deploy for in-place migration from CentOS 8

Rocky Linux

Another free RHEL-compatible rebuild, founded by one of CentOS's original creators.

Rocky Linux 8: supported through May 2029
Rocky Linux 9: supported through May 2032
Provides migrate2rocky for in-place conversion from CentOS 8

Red Hat Enterprise Linux

RHEL is available at no cost for up to 16 production servers through the Red Hat Developer Program.

RHEL 9: supported through May 2032
Extended Lifecycle Support available through 2036

In-Place vs. Fresh Provisioning

From CentOS 8: Both AlmaLinux and Rocky provide scripts that convert a running CentOS 8 installation without a full OS reinstall. This is the fastest path.

From CentOS 7: The major version jump (RHEL 7 → RHEL 9 equivalent) means most teams use a provisioning-based approach — stand up a new server, migrate the application, decommission the old one. In-place conversion across major versions is not officially supported and carries significant risk.

Full article with EOL Risk Scores and detailed migration guidance: endoflife.ai/article-centos-eol

Veeam Backup & Replication End of Life: What EOL Backup Software Means for Your Compliance Posture

endoflife-ai — Sat, 30 May 2026 05:22:34 +0000

Veeam Backup & Replication is deeply embedded in enterprise infrastructure. It's also one of those products that teams install, configure, and then don't touch for years — which is exactly how EOL versions accumulate.

Veeam 11 reached end of support on February 1, 2025. Veeam 12.0 reached end of support on February 1, 2026. Both are now unsupported.

If you open a Veeam support ticket on either version today, Veeam may require you to upgrade before providing assistance.

Veeam B&R EOL Schedule

Version	End of Support	Status
Veeam 9.5	Jan 1, 2022	❌ EOL
Veeam 10	Feb 1, 2023	❌ EOL
Veeam 11	Feb 1, 2025	❌ EOL
Veeam 12.0	Feb 1, 2026	❌ EOL
Veeam 12.1	TBD	✅ Supported

Veeam follows an N-2 support policy: only the two most recent major versions receive full technical support.

EOL Risk Score for Veeam 11: 79 Critical
View full score → endoflife.ai/score/veeam-backup-and-replication/11

The Problem Nobody Talks About: Hypervisor Compatibility

Running EOL Veeam isn't just a security concern — it's an operational risk.

Veeam regularly releases compatibility updates for:

New VMware vSphere builds
Hyper-V releases
Windows Server versions
Storage array firmware

Without these updates, your backup jobs may begin failing silently as your hypervisor or storage infrastructure is updated separately.

Veeam 11 was never updated to support VMware vSphere 8 U3 or later. If your vSphere environment has been updated since Veeam 11's EOL date, you may be operating with an officially unsupported hypervisor/backup combination — one that could fail during a restore when you need it most.

Compliance Implications

Backup software occupies a unique position in compliance frameworks:

SOC 2 — backup integrity and recovery capability are tested controls
ISO 27001 — backup procedures and their testing are explicit requirements (Annex A.8.13)
PCI DSS — backup systems are in scope for security requirements

Running EOL backup software generates findings under all three. Auditors are increasingly aware that EOL software means unpatched CVEs — and when that software controls your disaster recovery capability, the severity of the finding is elevated.

Document your Veeam version, its EOL date, and your upgrade timeline before your next audit. Auditors expect to see this tracked — not discovered during the audit.

What Changed in Veeam 12.1

Veeam 12.1 (December 2023) added:

Malware detection using inline entropy analysis and YARA rules
Expanded cloud integration (S3-compatible object storage)
Improved Linux proxy support
SureBackup improvements for automated recovery verification

This is the only fully supported release in the v12 family.

Upgrade Path: Veeam In-Place Upgrade

Veeam supports direct in-place upgrades between major versions.

Pre-upgrade checklist:

Ensure all jobs complete or are stopped
Verify SQL Server version — Veeam 12.1 requires SQL Server 2014 SP2 or later
Confirm all proxy and repository servers are online
Check OS compatibility — Windows Server 2012 R2 is not supported for the VBR server in v12.1
Run the Veeam Upgrade Checker before proceeding

After the upgrade: always run SureBackup to verify backup recoverability. A successful Veeam upgrade is not a confirmed working backup. A successful restore is.

Check What You're Protecting Too

Veeam protects your Windows Server, VMware, and Linux workloads — but those workloads have their own EOL dates. Check the EOL status of the systems in your backup scope at endoflife.ai/checker.

Full article with EOL Risk Scores for every Veeam version: endoflife.ai/article-veeam-eol

Apache Tomcat End of Life: Tomcat 9 is EOL — Migration Guide to Tomcat 10/11

endoflife-ai — Sat, 30 May 2026 05:21:04 +0000

Apache Tomcat 9 reached end of life on December 31, 2025. No more security patches. No more CVE fixes. Every vulnerability disclosed from January 1, 2026 onward is permanently unpatched on Tomcat 9.

And yet — tens of thousands of production servers are still running it today.

This isn't negligence. There's a specific technical reason teams stay stuck, and it's worth understanding before you plan your migration.

Complete Tomcat EOL Schedule

Version	Servlet Spec	End of Life	Status
Tomcat 7	3.0	Mar 31, 2021	❌ EOL
Tomcat 8.5	3.1	Mar 31, 2024	❌ EOL
Tomcat 9	4.0	Dec 31, 2025	❌ EOL
Tomcat 10.1	6.0 (Jakarta)	Dec 31, 2026	⚠️ Warning
Tomcat 11	6.1 (Jakarta)	TBD	✅ Supported

Why Tomcat 9 is the Stickiest EOL Version

Tomcat 9 was the last version to use the javax.* namespace. Tomcat 10 and later use the jakarta.* namespace — a breaking change introduced with Jakarta EE 9.

This means migrating from Tomcat 9 to Tomcat 10+ is not a drop-in upgrade. Every class in your application that imports from javax.servlet needs to be updated to jakarta.servlet. For a large application, that's potentially hundreds of files.

The Apache Tomcat project publishes an official migration tool that automates most of this — but the effort is real, and that's why Tomcat 9 outlives its EOL date in so many environments.

The CVE Risk of Running EOL Tomcat

Tomcat has a well-documented CVE history: HTTP/2 request smuggling, path traversal vulnerabilities, deserialization issues, session fixation bugs. These are high-severity, real-world exploits — not theoretical risks.

When Tomcat 9 reached EOL, the Apache project stopped backporting fixes. Any CVE disclosed after December 31, 2025 that affects Tomcat 9 will never receive an official patch.

EOL Risk Score for Tomcat 9: 82 Critical
View full score → endoflife.ai/score/tomcat/9

Should You Go to Tomcat 10.1 or Tomcat 11?

If you're migrating from Tomcat 9, migrate directly to Tomcat 11 rather than 10.1.

Here's why: the namespace change (javax.* → jakarta.*) is the same effort whether you're targeting 10.1 or 11. Tomcat 10.1 reaches EOL December 31, 2026 — less than 18 months away. Tomcat 11 has no defined EOL date. Doing the migration once to reach the longest-supported version is more efficient.

Migration Guide: Tomcat 9 → Tomcat 11

Step 1 — Run the Jakarta EE migration tool

java -jar jakartaee-migration-1.0.6-shaded.jar source.war migrated.war

This rewrites javax.* imports to jakarta.* automatically across your WAR or exploded application.

Step 2 — Update your dependencies

Spring Framework 6+, Hibernate 6+, and Jakarta EE 10-compatible libraries are required. Check each dependency's Jakarta EE compatibility before upgrading.

Step 3 — Review your web.xml

Update the XML namespace declarations in web.xml:

<!-- Old (Tomcat 9) -->
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="4.0">

<!-- New (Tomcat 10/11) -->
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" version="6.0">

Step 4 — Deploy to staging on Tomcat 11 first

Run your full integration test suite on Tomcat 11 before touching production. Pay attention to servlet filters, session listeners, and any code that directly touches HttpServletRequest or HttpServletResponse.

Step 5 — Update configuration files

Review context.xml and server.xml for deprecated settings. Tomcat 11 removed some legacy configuration options that were deprecated in earlier versions.

Check Your Full Stack

Tomcat runtime EOL is one layer. If you're running Tomcat on:

Java 8 or 11 → both are past their free-tier OpenJDK support windows
RHEL 7 or CentOS 7 → both are EOL as of June 2024
Spring Boot 2.x → EOL since November 2023

Multiple EOL layers compound the CVE exposure. Check your full stack at endoflife.ai/checker.

Full article with EOL Risk Scores for every Tomcat version: endoflife.ai/article-tomcat-eol

Cisco IOS XE End of Life Dates: Full Version EOL & EoS Guide (17.x)

endoflife-ai — Thu, 28 May 2026 04:50:28 +0000

Knowing when your Cisco IOS XE version reaches end of software maintenance is essential for network compliance and vulnerability management. This guide covers the IOS XE lifecycle model, all 17.x release train dates, and how to determine whether your version is still receiving security fixes.

Quick answer: IOS XE 17.15.x (Long-Lived) is the current recommended release. IOS XE 17.12.x (Long-Lived) is in active maintenance. IOS XE 17.9 and earlier have reached or are approaching End of Software Maintenance.

⚠️ Always verify dates against official Cisco EoL product bulletins — this guide uses Cisco's standard release cadence for approximate dates where official bulletins are not yet published.

Understanding the Cisco IOS XE Release Model

Cisco IOS XE uses a two-track release model:

Standard Maintenance (SM) Releases

Ship approximately every 6 months. Receive roughly 12 months of software maintenance. Good for environments that want latest features. Examples: 17.3, 17.6, 17.9.

Long-Lived (LL) Releases

Designated for stable production deployments. Receive approximately 36 months of software maintenance — 3× the Standard window. Recommended for enterprise production networks. Examples: 17.3 LL, 17.6 LL, 17.9 LL, 17.12 LL, 17.15 LL.

⚠️ Cisco issues separate EoL bulletins for Standard vs. Long-Lived releases within the same version train. A 17.9 Standard release has an earlier end of maintenance date than 17.9 LL.

Cisco IOS XE 17.x Release Train — EOL Overview

IOS XE Release	Type	First Released	End of SW Maintenance	End of Support	Status
17.15.x	Long-Lived	~Q3 2025	~Q3 2028	~Q3 2030	✅ Current LL
17.14.x	Standard	~Q1 2025	~Q1 2026	~Q1 2028	✅ Active
17.13.x	Standard	~Q3 2024	~Q3 2025	~Q3 2027	🟡 Maintenance
17.12.x	Long-Lived	Mar 2024	~Mar 2027	~Mar 2029	✅ LL – Active
17.11.x	Standard	~Q3 2023	~Q3 2024	~Q3 2026	❌ EOL
17.10.x	Standard	~Q1 2023	~Q1 2024	~Q1 2026	❌ EOL
17.9.x	Long-Lived	Aug 2022	Aug 2025	Aug 2027	❌ EOL
17.8.x	Standard	~Q1 2022	~Q1 2023	~Q1 2025	❌ EOL
17.7.x	Standard	~Q3 2021	~Q3 2022	~Q3 2024	❌ EOL
17.6.x	Long-Lived	Jul 2021	Jul 2024	Jul 2026	❌ EOL
17.5.x	Standard	~Q1 2021	~Q1 2022	~Q1 2024	❌ EOL
17.4.x	Standard	~Q3 2020	~Q3 2021	~Q3 2023	❌ EOL
17.3.x	Long-Lived	Oct 2020	Oct 2023	Oct 2025	❌ EOL
17.2.x	Standard	~Q1 2020	~Q1 2021	~Q1 2023	❌ EOL
17.1.x	Standard	~Q3 2019	~Q3 2020	~Q3 2022	❌ EOL

Dates marked ~ are approximate based on Cisco's standard cadence. Verify against official Cisco EoL bulletins.

Cisco IOS XE 16.x — Legacy Releases

All 16.x releases are end of life.

IOS XE 16.x Release	Type	End of SW Maintenance	Status
16.12.x (Fuji)	Long-Lived	Jan 2023	❌ EOL
16.11.x	Standard	~Apr 2021	❌ EOL
16.9.x (Fuji)	Long-Lived	Oct 2021	❌ EOL
16.6.x (Everest)	Long-Lived	Jan 2020	❌ EOL

Key Release Notes

IOS XE 17.15 — Current Long-Lived

The current recommended Long-Lived release. Expected maintenance until approximately Q3 2028. Target version for networks being upgraded in the 2025–2026 window. Full support for Catalyst 9000, ISR 4000, and ASR 1000.

IOS XE 17.12 — Stable Long-Lived

Widely deployed in enterprise production. First released Q1 2024. End of software maintenance expected approximately March 2027. Solid choice for environments that cannot yet upgrade to 17.15.

IOS XE 17.9 — End of Life (August 2025)

One of the most widely deployed enterprise versions. End of Software Maintenance: August 2025. Networks still on 17.9 should upgrade to 17.12 or 17.15.

IOS XE 17.6 — End of Life (July 2024)

End of Software Maintenance: July 2024. No longer receiving security patches.

IOS XE 17.3 — End of Life (October 2023)

End of Software Maintenance: October 2023. Fully unsupported.

Quick Reference: Common Version Queries

Version String	Train	Type	Status
17.15.x	17.15	Long-Lived	✅ In Maintenance (~2028)
17.12.x	17.12	Long-Lived	✅ In Maintenance (~2027)
17.9.x	17.9	Long-Lived	❌ EOL – Aug 2025
17.6.x	17.6	Long-Lived	❌ EOL – Jul 2024
17.3.x	17.3	Long-Lived	❌ EOL – Oct 2023
16.12.x	16.12	Long-Lived	❌ EOL – Jan 2023

Platforms Running Cisco IOS XE

Catalyst 9000 Series — 9200, 9300, 9400, 9500, 9600, 9800 (wireless)
ISR 4000 Series — 4221, 4321, 4331, 4351, 4431, 4451, 4461
ASR 1000 Series — 1001-X, 1001-HX, 1002-X, 1002-HX, 1004, 1006-X
CSR 1000V / Catalyst 8000V — virtual router platforms
Catalyst 8000 Edge — 8200, 8300, 8500

How to Check Your IOS XE Version

Router# show version
Cisco IOS XE Software, Version 17.12.04

Router# show version | include IOS XE

How to Upgrade (Catalyst 9000 Install Method)

# Download image to flash
copy tftp://server/cat9k_iosxe.17.12.04.SPA.bin flash:

# Install
install add file flash:cat9k_iosxe.17.12.04.SPA.bin
install activate
install commit

FAQ

What is IOS XE 17.12 end of life?
Long-Lived release. End of Software Maintenance approximately March 2027. Verify at cisco.com.

Is IOS XE 17.9 still supported?
No. End of Software Maintenance was August 2025. Upgrade to 17.12 or 17.15.

What is the difference between EoS and EoL for Cisco?

End of Sale (EoS): Product can no longer be purchased
End of Software Maintenance: No new software releases or patches
End of Vulnerability Support: No more CVE patches
End of Support (EoL): All support ends, including TAC

For software releases, End of Software Maintenance is the critical milestone.

What happened to Cisco IOS 15.x (Classic)?
All 15.x releases have reached end of life. Classic IOS 15.1 EOL was January 2023. Plan hardware refreshes to IOS XE-based platforms.

Live version data: endoflife.ai/cisco-ios-xe