EOL Software and Compliance: What PCI-DSS and SOC2 Actually Require
The security case for avoiding EOL software is straightforward: unpatched CVEs accumulate indefinitely. The compliance case is equally clear but less often discussed: PCI-DSS, SOC2, and ISO 27001 all contain explicit requirements around software support status. Running EOL software in a scoped environment is not a gray area — it is a finding.
PCI-DSS 4.0 and EOL software
PCI-DSS 4.0, mandatory since March 2024, addresses unsupported software directly. Requirement 6.3.3 mandates that all system components are protected from known vulnerabilities by installing applicable security patches. Software no longer receiving vendor patches cannot satisfy this requirement by definition.
Requirement 12.3.4 requires organizations to review hardware and software technologies at least once every 12 months to confirm they continue to receive security fixes. An EOL component discovered during a QSA assessment is a direct finding — not a recommendation.
SOC2 and the Common Criteria
SOC2 Type II audits evaluate controls against AICPA Trust Services Criteria. Common Criteria CC7.1 requires detection and monitoring procedures to identify configurations that introduce new vulnerabilities. Running software past its vendor support date is precisely the scenario CC7.1 is designed to catch.
SOC2 auditors increasingly include software version reviews in evidence collection. An organization running Node.js 16 or PHP 8.1 in a SOC2-scoped environment during a Type II audit period will face questions about compensating controls.
ISO 27001:2022
ISO 27001:2022 Annex A Control 8.8 requires organizations to obtain timely information about technical vulnerabilities of systems in use and take appropriate measures. Software past its vendor EOL date represents a permanent, unfixable vulnerability exposure that cannot be addressed by any means other than upgrading.
The compensating control myth
WAF rules, network segmentation, and enhanced monitoring may satisfy an auditor temporarily but do not eliminate the underlying risk. CVEs in EOL software are specific, known, and publicly documented — attackers read the same CVE database your auditors do.
Building a compliance-aware EOL monitoring process
A defensible compliance posture requires three things: an inventory of all software components and their versions, a process for identifying when those versions approach EOL, and a documented upgrade plan. EOLCanary addresses the first two: declare your stack, get alerted at 6 months, 3 months, 1 month, and 1 week before EOL.
Start monitoring your stack on EOLCanary.