# Your EOL Dates Are Deadlines. Now They Live on Your Calendar. > Source: > Published: 2026-06-06 11:53:07+00:00 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](https://endoflife.ai/article-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. Every [product page](https://endoflife.ai/products) 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](https://endoflife.ai/nodejs), [PHP](https://endoflife.ai/php), [Kubernetes](https://endoflife.ai/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. 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](https://www.cisa.gov/stopransomware/bad-practices). 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](https://www.cisa.gov/known-exploited-vulnerabilities-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. 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. The Payment Card Industry standard added a requirement aimed squarely at this. [Requirement 12.3.4](https://www.pcisecuritystandards.org/) 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. Control [SA-22, "Unsupported System Components,"](https://csrc.nist.gov/) 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. 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 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. For ePHI, the [HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/index.html) requires a risk analysis (45 CFR §164.308) and technical safeguards (§164.312). NIST's implementation guide, [SP 800-66 Revision 2](https://csrc.nist.gov/pubs/sp/800/66/r2/final) (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 youknowyour 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](https://gdpr-info.eu/art-32-gdpr/) 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. A calendar reminder is the trigger. Here's the workflow it plugs into: `package.json` , `requirements.txt` , Gemfile, or container base images to map what you actually run against current EOL dates.The date was never the hard part. EOL dates are published years in advance; that's the entire premise of [endoflife.date](https://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.**