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 at build time for every product and version tracked on endoflife.ai. It is not a CVSS score — it is a lifecycle risk 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:

Why Each Factor Was Chosen

EOL Recency — 40 points

This is the heaviest factor and deliberately so. 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. A version that hit EOL yesterday scores differently than one that hit EOL three years ago. This reflects reality: 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 running on an air-gapped system carries different risk than a web-facing runtime handling public traffic. The attack surface factor accounts for how broadly a product is deployed, how internet-facing it typically is, and how attractive it is as an attack target.

Node.js, PHP, Python, Apache, nginx — these score 30/30 because they are the foundation of internet-facing infrastructure at scale. A proprietary internal scheduling tool might score 10/30. 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 — a curated list of CVEs that have been actively exploited in the wild. Not theoretically vulnerable. Actively exploited, right now, in documented incidents.

If a product has entries in the CISA KEV catalog, the threat is not academic. Organizations running that product with no patch path are operating with open wounds that attackers have already demonstrated they know how to exploit. The score reflects this urgency.

Extended Support Availability — 10 points

Running past EOL doesn't have to mean running without patches. Specialist vendors provide extended lifecycle support for Linux distributions and other products. If a migration isn't yet possible, a mitigation exists.

This factor rewards products where the risk can be actively managed even past EOL. It also helps compliance teams document a compensating control — "we are running past EOL but under a paid extended support contract that provides continued security patches" is a defensible position with auditors. "We are running past EOL with no patches and no plan" is not.

Real Score Examples Across the Stack

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 in typical deployments, and whether active exploits exist in documented incidents. Two products at the same EOL date can score very differently.

The Stack Risk Problem Nobody Talks About

Here's what most security tools miss: 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 logic 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 Stack Scanner at endoflife.ai evaluates your full stack, not individual components in isolation. 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

This is where the conversation changes for CISOs and compliance teams. EOL software isn't just a technical problem. It is a documented control failure in every major security framework — and auditors are trained to find it.

Real-World Consequences — What Actually Happened

These are not hypotheticals. These are documented incidents with published post-mortems, regulatory filings, and financial disclosures.

Cyber Insurance — The Consequence Most Teams Don't See Coming

The cyber insurance market has changed dramatically since 2021. Underwriters now ask detailed questions about your technology stack as part of the application process. The questions have become specific:

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

Answering these questions incorrectly — or having a breach reveal EOL software that wasn't disclosed — ranges from increased premiums to voided coverage. 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 a $4 million policy is a survivable event. A $4.45 million breach with voided coverage because you were running PHP 7.4 is a different conversation entirely.

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

The Planning Framework — What to Do at Each Stage

The EOL Risk Score gives you a number. Here is how to act on it:

• 0–25 Low
  Plan You're supported. Use this window to understand your migration path to the next version before you need it. Document dependencies. Identify breaking changes. The upgrade should be scheduled and completed before the EOL date — not after.
• 26–50 Medium
  Prepare You're either approaching EOL or running software with meaningful attack surface exposure. This is when your migration plan becomes a migration project. Assign an owner. Set a hard deadline. If EOL is within 12 months, treat this as urgent.
• 51–75 High
  Act EOL is imminent or just passed. You are accumulating unpatched CVE exposure daily. If you cannot migrate immediately, investigate extended support options. Document the risk formally with a hard remediation date. This is a compliance finding waiting to be discovered.
• 76–100 Critical
  Escalate You are running software that will never receive another security patch, has a broad attack surface, and likely has known actively exploited vulnerabilities in documented incidents. This is a board-level risk item. Every day of inaction is another day a newly discovered CVE sits permanently unpatched in your environment. If you cannot migrate, you must obtain extended support, isolate the system, monitor extensively, and document everything. Your auditors will find it regardless.

Check Your Stack Right Now

Every product and version on endoflife.ai has an EOL Risk Score. It is free. No signup required. No sales call.

If you find a Critical score in your stack today, you have options. Extended support vendors can provide continued patches while you plan a controlled migration. 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. The score is the number that makes that timeline visible before it becomes an incident.

Know your number.