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.
Top comments (0)