Why Your EOL Risk Score Is the Most Important Number in Your Security Stack

Your stack has a risk score. You just haven't been measuring it.

Every piece of software running in your production environment has an end-of-life date. The moment that date passes, the vendor stops issuing security patches. CVEs keep getting discovered. Exploits keep getting developed. Your software stops getting fixed.

That's not a hypothetical. That's a scheduled event — and it's on a calendar you can look up right now.

The EOL Risk Score™ puts a 0–100 number on that risk for every product and version tracked on endoflife.ai. This article explains what it measures, why each factor matters, how it maps directly to SOC 2, ISO 27001, and PCI DSS compliance requirements, and what the documented consequences look like for organizations that ignore it.

What the EOL Risk Score Actually Measures

The EOL Risk Score™ is a 0–100 composite score calculated for every product and version tracked on endoflife.ai. It is not a CVSS score. It answers a different question: not "how severe is this specific vulnerability" but "how much accumulated, unresolvable risk is this software carrying right now?"

Four factors combine into the final score:

Score bands:

• 76–100: 🔴 Critical
• 51–75: 🟠 High
• 26–50: 🟡 Medium
• 0–25: 🟢 Low

A score of 0 doesn't mean safe. It means low risk right now. Every supported version is accumulating risk on a known, published timeline. Node.js 22 scores 50 Medium today. On April 30, 2027 — with no change to your infrastructure — it becomes 90 Critical. The date is already on the calendar.

Why Each Factor Was Chosen

EOL Recency — 40 points

The heaviest factor, deliberately. The longer software has been past its end-of-life date, the more CVEs have been disclosed with no patch path. PHP 7.4 hit EOL in November 2022. By May 2026 that's 42 months of unpatched vulnerability accumulation. Every CVE discovered against PHP 7.4 since November 2022 will never receive an official fix. Not delayed — never.

The recency score scales with time past EOL. Attackers track EOL dates. Once a product hits end of life, the research community continues finding vulnerabilities but the vendor stops fixing them. The asymmetry grows with time.

Attack Surface — 30 points

Not all EOL software carries the same exposure. A niche internal tool on an air-gapped system carries different risk than a web-facing runtime handling public traffic.

Node.js, PHP, Python, Apache, nginx — these score 30/30 because they are the foundation of internet-facing infrastructure at scale. Same EOL date, wildly different real-world exposure.

CISA KEV Exposure — 20 points

The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalog — CVEs that have been actively exploited in the wild. Not theoretically vulnerable. Actively exploited, right now, in documented incidents.

If a product has CISA KEV entries and no patch path, attackers have already demonstrated they know how to exploit it.

Extended Support Availability — 10 points

Running past EOL doesn't have to mean running without patches. Vendors like TuxCare provide extended lifecycle support for Linux distributions and other products. If migration isn't yet possible, a mitigation can exist.

This factor also helps compliance teams document a compensating control — "we are running past EOL but under a paid extended support contract" is a defensible position with auditors. "We are running past EOL with no patches and no plan" is not.

Real Score Examples

The difference between PHP 7.4 at 90 and Go 1.24 at 20 isn't just the EOL date. It's the combination of how long it's been unsupported, how exposed it is, and whether active exploits exist in documented incidents.

The Stack Risk Problem Nobody Talks About

Your stack's risk level is set by your weakest component, not your strongest.

A team running Node.js 22 (Score: 50 Medium) on Ubuntu 20.04 (Score: 85 Critical) isn't a Medium-risk environment. They're a Critical-risk environment that happens to have a current application runtime. The OS is the foundation. If it's compromised, nothing above it matters.

The same applies throughout the stack:

• A current framework running on an EOL language runtime
• A patched application running on an EOL database
• A modern containerized workload built on an EOL base image
• A secure application deployed behind an EOL web server

The score that matters is the highest one — because that's the one your attacker will find first.

How EOL Risk Maps to Compliance Frameworks

EOL software isn't just a technical problem. It is a documented control failure in every major security framework.

SOC 2 — CC7.1 Vulnerability Management

SOC 2's mandatory Security criterion includes CC7.1, requiring organizations to detect and monitor for vulnerabilities. Running EOL software with no patch path is a vulnerability that cannot be remediated without migration or extended support.

Auditors will review your patch management program. "We are running PHP 7.4" is not a response that satisfies CC7.1 without a documented exception and remediation plan. Enough findings and your SOC 2 report comes back qualified.

Practical consequence: Enterprise procurement treats a qualified SOC 2 opinion like a failed credit check. You lose the deal.

ISO 27001 — Annex A.12.6.1 Technical Vulnerability Management

ISO 27001 Annex A control A.12.6.1 explicitly requires organizations to identify technical vulnerabilities, evaluate exposure, and take appropriate action. Running software past its vendor-published end-of-life date with no compensating control is a textbook nonconformity.

A nonconformity found during a surveillance audit can result in suspension of your certificate.

Practical consequence: Many enterprise contracts require maintaining ISO 27001 certification. A lapsed certificate can trigger breach of contract clauses.

PCI DSS — Requirement 6.3.3 Security Patch Management

PCI DSS is mandated by the card brands for any organization handling cardholder data. Requirement 6.3.3 requires all system components to be protected against known vulnerabilities by installing applicable security patches.

EOL software that is no longer receiving patches has no applicable security patches to install. It is a permanent, unresolvable violation until the software is replaced or covered by a paid extended support agreement.

Practical consequence: Fines of $5,000–$100,000 per month until compliant. Loss of ability to process card payments. Mandatory forensic investigation costs ($50,000–$200,000+) if a breach occurs while non-compliant.

Real-World Consequences — What Actually Happened

Equifax, 2017 — 147 Million Records Exposed

Root cause: Apache Struts CVE-2017-5638. The patch had been available for two months. It was never applied.

The breach ran undetected for 78 days. Total costs: $1.38 billion. FTC settlement: $575 million. The CEO, CIO, and CSO all resigned.

The vulnerability was known. The patch existed. The software was running unpatched in a public-facing system. EOL software takes this failure mode and makes it permanent — there is no patch to apply. Ever.

MOVEit Transfer, 2023 — 2,000+ Organizations Breached

A zero-day SQL injection in Progress Software's MOVEit Transfer, exploited by the Cl0p ransomware group in a coordinated global campaign. Over 2,000 organizations confirmed affected including Shell, British Airways, the BBC, and the US Department of Energy. Organizations running older unpatched versions had no remediation path.

Log4Shell, 2021 — CVSS 10.0, Exploited Within Hours

CVE-2021-44228 in Apache Log4j. CVSS score: 10.0. Actively exploited within hours of public disclosure. Organizations running EOL Java versions that could not apply the patch were fully exposed with no remediation path. Many didn't even know they were running Log4j — it was embedded in vendor products.

The pattern is the same every time. Known software. Known vulnerability. No patch applied. EOL software removes "apply the patch" from your options permanently.

Cyber Insurance — The Consequence Most Teams Miss

Underwriters now ask detailed questions about your technology stack:

• "Are any components of your production environment running past vendor end-of-life?"
• "What is your process for identifying end-of-life software?"
• "Do you have documented exceptions for any end-of-life software in production?"

Some policies now include explicit exclusions for breaches originating from software that was past vendor end-of-life at the time of the incident.

IBM's Cost of a Data Breach Report puts the average breach at $4.45 million USD. A $4.45 million breach with voided coverage because you were running PHP 7.4 is a very different conversation than one with a $4 million policy.

The EOL Risk Score is the number your underwriter is going to ask about. Know it before they do.

The Planning Framework

Check Your Stack Right Now

Every product and version on endoflife.ai has an EOL Risk Score. Free, no signup.

• Full stack scanner: endoflife.ai/scanner.html
• Individual scores: endoflife.ai/score/nodejs/18
• Score methodology: endoflife.ai/risk-score.html
• 455+ products tracked: endoflife.ai/products.html

If you find a Critical score in your stack today, you have options. If you find it during an audit or after a breach, your options narrow considerably.

Attackers track EOL dates too. The moment a version hits end of life, it becomes a permanently open target. The CVEs will keep coming. The patches will not.

Know your number.

EOL Risk Score™ is a proprietary methodology developed by endoflife.ai. This article is for informational purposes and does not constitute legal or compliance advice.