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.