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 compounds because EOL software is invisible in most security programs. Vulnerability scanners don't flag it as a CVE. SIEMs don't alert on it. It sits in your stack, accumulating risk, until an auditor asks a question you don't have a clean answer to.
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.
If you can produce the inventory and it contains end-of-life components, you're now explaining compensating controls for every flagged item. Under PCI DSS 4.0, that conversation has a specific name: a Targeted Risk Analysis. Under SOC 2, it's a gap in your Availability and Confidentiality criteria. Under HIPAA, it may constitute a violation of the Security Rule's Technical Safeguard requirements.
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 is not automatically a violation — but it requires a documented risk decision with compensating controls, reviewed annually. Most organizations haven't done this. Most QSAs will find it.
SOC 2
SOC 2 doesn't list specific technologies. It evaluates whether your controls are sufficient given the risks you face. 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. The 2022 revision strengthened this language. EOL software — software for which no patches exist — represents a structural vulnerability management failure under this control.
| Framework | Key control | EOL exposure type | 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 process | High |
| HIPAA | §164.312(a)(2)(iv) | Known risk factor in OCR breach investigations; worsens penalty exposure | 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 environments today that are past end-of-life — with their EOL Risk Score™s™:
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. Not ancient Windows XP. The thing you deployed in 2022 and haven't touched since.
The CISA KEV Connection
CISA's Known Exploited Vulnerabilities catalog is now a compliance input, not just an advisory. CISA BOD 22-01 requires federal agencies to remediate KEV entries on a fixed schedule. FedRAMP's updated baseline and NIST's framework revision both incorporate KEV status. Private-sector auditors are increasingly using KEV as a benchmark for what constitutes "known risk."
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 — which is far more expensive and disruptive than a version upgrade would have been.
What Remediation Actually Costs
The cost comparison between proactive EOL management and reactive compliance remediation is not close.
A planned migration from Node.js 18 to Node.js 22, executed during a normal sprint cycle, costs engineering time — measured in days or weeks for most applications. The same migration executed under audit pressure — with a QSA finding open, a TRA required, and a deadline attached — costs that plus legal review, compensating control documentation, potential audit delay fees, and in regulated industries, possible notification obligations.
Extended support is a middle path. Specialist vendors provide commercial extended support for Linux distributions including Ubuntu, CentOS, and RHEL past their vendor EOL dates. This can satisfy auditor requirements for compensating controls while a migration is planned — but it requires documentation and a defined end state. It is not a permanent solution.
A 30-Day Action Plan
You cannot manage what you cannot see. Use the Stack Scanner to get an immediate read on your technology stack against current EOL dates. Pull infrastructure manifests, package.json files, requirements.txt, Gemfiles, and container base images. The goal: a complete, accurate list of every software component and version in your environment.
Not all EOL software carries equal risk. Use the EOL Risk Score™ — EOL recency, attack surface, CISA KEV exposure, and extended support availability — to triage. Components scoring 76+ go to the top of the remediation queue. Components scoring below 50 with available extended support may be candidates for a compensating control strategy.
For every EOL component you cannot immediately upgrade, document compensating controls: network segmentation, enhanced monitoring, WAF rules, and a defined remediation timeline. Under PCI DSS 4.0, this is the Targeted Risk Analysis. Under SOC 2, it's evidence for your auditor. Without it, you have a finding. With it, you have a managed risk.
EOL events happen on a schedule. 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. 180 days is realistic for most organizations to plan and execute a migration.
Compliance frameworks don't require perfect software. They require that you know your risks and manage them deliberately. Running EOL software is manageable — if it's documented, compensated, and on a remediation timeline. Running it unknowingly is not.
The 30 days before an audit is the wrong time to discover that your core runtime is two years past end-of-life. The tooling to know this in advance is free. The cost of not knowing is not.
Know what your auditors will find — before they do
EOL Risk Scores™ for 455+ products. Stack scanner, version checker, and API — free, no signup required.
Scan your stack Risk Score methodology API access