PCI DSS v4.0 Requirement 6 and EOL Software: What the Standard Actually Requires

PCI DSS v4.0 and the EOL Software Problem

PCI DSS v4.0, which became the only active version of the standard in April 2024, introduced several changes to Requirement 6 that have direct implications for organisations running EOL open source components in their cardholder data environment (CDE) or systems connected to the CDE. The previous v3.2.1 language was sufficient to flag EOL software as a risk; v4.0 makes the connection more explicit and adds new evidence requirements that assessors are actively enforcing.

The Relevant v4.0 Controls

Requirement 6.3.3: All Software Is Protected from Known Vulnerabilities

Requirement 6.3.3 states that all system components are protected from known vulnerabilities by installing applicable security patches and updates. For the latest patches, the installation timeline is within one month of release. For critical patches, installation must occur within one month of release. For all other security patches, installation must occur within a defined timeframe appropriate to the organisation's risk-based vulnerability management process.

For EOL software components, there are no applicable security patches — the upstream project does not release them. This creates an apparent compliance impasse. In practice, assessors accept two approaches: extended lifecycle patching from a third-party provider (which satisfies 6.3.3 if the patch delivery timeline is contractually defined and documented), or formal risk acceptance with compensating controls documented to the assessor's satisfaction.

Requirement 6.2.4: Bespoke and Custom Software Protects Against Attack

This requirement applies to internally developed software and custom integrations, but assessors have increasingly applied the spirit of 6.2.4 to the choice of foundational components. An application built on an EOL runtime with known unpatched vulnerabilities is viewed as failing to implement security practices to prevent or mitigate attacks — regardless of whether the vulnerability is in the custom code or the underlying platform.

Requirement 6.5: Any Vulnerabilities in Software Are Identified and Addressed

Requirement 6.5 requires an established vulnerability identification process and a defined and verified process for addressing vulnerabilities. For EOL components, the gap between "vulnerability identified" and "vulnerability addressed" is the entire compliance challenge. Assessors want to see that identified vulnerabilities in EOL components have a documented remediation path — not just an acknowledgement that the component is EOL.

What Assessors Are Looking For

Based on feedback from PCI assessors reviewing CDE environments with EOL OSS components in 2024 and 2025, the evidence package that satisfies 6.3.3 and 6.5 for extended lifecycle components needs to include:

• A current inventory of all EOL software in the CDE or connected systems.
• A vulnerability scan report identifying known CVEs against each EOL component.
• For each CVE: the CVSS score, a compensating control or patch evidence, and the documented timeline to full remediation.
• Evidence that the patch (or compensating control) was implemented within the organisation's defined vulnerability management timeline.
• A roadmap to eliminating EOL components from the CDE, with target dates.

Extended Lifecycle Patching as a Compliance Tool

Third-party extended lifecycle support (from OSSeva or similar providers) is the cleanest way to satisfy PCI DSS 6.3.3 for EOL OSS components. The key is contractual patch delivery timelines: the MSA must commit to specific SLAs for critical CVE patching (OSSeva's Assure SLA is 72 hours for CVSS ≥ 9.0), and those SLAs must be documented for the assessor. Patch delivery records — which OSSeva provides with every release — serve as the evidence that patches were actually installed within the contractual timeline.

Conclusion

PCI DSS v4.0 does not prohibit EOL software in the CDE — but it creates a documentation and evidence burden that requires a systematic response. Extended lifecycle patching with documented SLAs and patch delivery records is the most straightforward path to satisfying Requirement 6 for EOL OSS components. The alternative — compensating controls without patches — is a more complex negotiation with assessors and carries more audit risk.