Most compliance failures are not discovered in production. They're discovered in audit prep — when someone finally looks at what's actually running.
Software end-of-life is not a maintenance footnote. It is a compliance trigger. Across every major security framework — SOC 2, PCI DSS, HIPAA, ISO 27001, and FedRAMP — running unsupported software creates a direct path to audit findings, control failures, and in regulated industries, material legal exposure.
The Problem Auditors See First
When a qualified security auditor reviews your environment, one of their first requests is a software inventory with version data. Not to be thorough. To check one specific thing: whether you know what you're running, and whether what you're running is still receiving security patches.
If you can't produce that inventory cleanly, you've already failed a control — before they've found a single vulnerability.
What "end-of-life" means legally: When a vendor stops issuing security patches, they've publicly documented that known vulnerabilities will not be fixed. Running that software means you have acknowledged, documented risk with no remediation path from the vendor. Auditors treat this differently from unknown risk. You knew. You chose to run it anyway.
How Each Framework Treats EOL Software
PCI DSS 4.0
Requirement 6.3.3 mandates that all system components are protected from known vulnerabilities by installing applicable security patches. The most consequential change in PCI DSS 4.0 is Requirement 12.3.2: the Targeted Risk Analysis, which must now formally document any deviation — including running EOL software in the cardholder data environment.
Running PHP 7.4, Node.js 16, or OpenSSL 1.0 in a CDE requires a documented risk decision with compensating controls, reviewed annually. Most organizations haven't done this. Most QSAs will find it.
SOC 2
The relevant Trust Services Criteria: CC7.1 (detection of threats to system components) and CC6.1 (logical access controls). An auditor testing CC7.1 will ask: how do you identify vulnerabilities in your environment? If your answer doesn't include a process for tracking software end-of-life, that's a gap. If EOL software is found running, that gap becomes a finding.
HIPAA Security Rule
The HIPAA Security Rule (45 CFR §164.312) requires covered entities and business associates to implement technical security measures to guard against unauthorized access to ePHI. OCR's current enforcement posture ties penalty severity to whether the covered entity had documented awareness of a risk and failed to act. Running unsupported software you knew about is worse than running it unknowingly.
ISO 27001:2022
Annex A Control 8.8 (Management of technical vulnerabilities) explicitly requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. EOL software — software for which no patches exist — represents a structural vulnerability management failure under this control.
| Framework | Key control | EOL exposure | Severity |
|---|---|---|---|
| PCI DSS 4.0 | Req. 6.3.3, 12.3.2 | Requires documented TRA for each EOL component in CDE | Critical |
| SOC 2 | CC7.1, CC6.1 | Gap in threat detection and vulnerability management | High |
| HIPAA | §164.312(a)(2)(iv) | Known risk factor in OCR breach investigations | Critical |
| ISO 27001:2022 | Annex A 8.8 | Structural failure of technical vulnerability management | High |
| FedRAMP | SI-2, SA-22 | SA-22 directly addresses unsupported software; POA&M required | Critical |
What Real Exposure Looks Like
These are the technologies most commonly found in production today that are past end-of-life:
| Product | EOL Date | EOL Risk Score™ |
|---|---|---|
| PHP 7.4 | Nov 28, 2022 | 90 Critical |
| Python 3.8 | Oct 7, 2024 | 88 Critical |
| Node.js 18 | Apr 30, 2025 | 85 Critical |
| Spring Framework 5.3 | Dec 31, 2024 | 82 Critical |
| Ubuntu 20.04 | Apr 2025 | 80 Critical |
These aren't obscure legacy systems. They're the foundation of most mid-market production environments — deployed three years ago and untouched since. That's the window auditors find.
The CISA KEV Connection
CISA's Known Exploited Vulnerabilities catalog is now a compliance input, not just an advisory. EOL software creates a specific KEV problem: when a vulnerability is discovered in a product past end-of-life, the vendor will not patch it. The CVE will be assigned. If it's exploited in the wild, it enters the KEV catalog. Your only remediation path is replacing the software entirely.
A 30-Day Action Plan
Days 1–5: Build the inventory
You cannot manage what you cannot see. Use the endoflife.ai Stack Scanner to get an immediate read on your technology stack against current EOL dates.
Days 6–10: Score and prioritize
Use the EOL Risk Score™ to triage. Components scoring 76+ go to the top of the remediation queue.
Days 11–20: Document compensating controls
For every EOL component you cannot immediately upgrade, document: what the component is, why it's EOL, compensating controls in place (network segmentation, WAF, enhanced monitoring), and a defined remediation timeline. Under PCI DSS 4.0, this is the Targeted Risk Analysis.
Days 21–30: Establish ongoing monitoring
The endoflife.ai API provides programmatic access to EOL dates for 455+ products, enabling automated alerting when components in your inventory approach end-of-life. 90-day lead time is the minimum.
Compliance frameworks don't require perfect software. They require that you know your risks and manage them deliberately. The tooling to know is free. The cost of not knowing is not.
Check your stack at endoflife.ai — free, no signup required.