PCI DSS and EOL Open Source: What Requirement 6 Demands and How QSAs Assess It

What PCI DSS v4.0 Requirement 6 actually says

Three controls in Requirement 6 bear on end-of-life components. It is worth quoting them accurately, because the specific wording is what an assessor works from.

6.3.3 — installing applicable security patches

Requirement 6.3.3 states that all system components are protected from known vulnerabilities by installing applicable security patches and updates. Under PCI DSS v4.0.1, the only active version since 31 December 2024, patches for critical vulnerabilities, identified through the risk ranking process in 6.3.1, are installed within one month of release, and all other applicable patches within a time frame the entity sets from that ranking. Version 4.0 had applied the one-month window to critical and high-security patches.

Two separate clocks, then — not a single 30-day rule, which is the most common misreading. The one-month window applies to critical findings as you have ranked them under 6.3.1, which makes your risk-ranking process part of the evidence rather than a preliminary to it.

For an end-of-life component there is no applicable security patch, because upstream does not publish one. That is the apparent impasse. In practice assessors accept two routes out: extended lifecycle patching from a third party, which satisfies 6.3.3 where the delivery timeline is contractually defined and evidenced, or formal risk acceptance with compensating controls documented to the assessor's satisfaction.

6.2.4 — bespoke and custom software

This requirement covers internally developed software and custom integrations. Assessors increasingly read its intent onto the choice of foundational components as well: an application built on an unmaintained runtime with known unpatched vulnerabilities is failing to prevent or mitigate attack, whether the flaw sits in your code or in the platform beneath it.

6.5 — vulnerabilities are identified and addressed

Requirement 6.5 asks for an established identification process and a defined, verified process for addressing what it finds. For end-of-life components the entire compliance problem lives in the gap between those two verbs. Scanning satisfies identification easily. What assessors want to see is a documented remediation path for each identified vulnerability — not an acknowledgement that one exists.

What PCI DSS Says About EOL Software

PCI DSS v4.0 Requirement 6.3 (Develop and Maintain Secure Systems and Software) contains the controlling requirement for EOL open source in payment environments. Specifically:

Requirement 6.3.3 (v4.0.1): all system components are protected from known vulnerabilities by installing applicable security patches. Patches for critical vulnerabilities, ranked under Requirement 6.3.1, are installed within one month of release; all other applicable patches within a time frame the entity sets from its risk ranking. Version 4.0 applied the one-month window to critical and high-security patches.

For EOL open source software, the phrase "installing applicable security patches/updates" is the crux of the issue. When a CVE is disclosed against an EOL version and the upstream project does not release a patch for that version, there is no "applicable security patch/update" to install — unless a third party provides one.

Running EOL PostgreSQL, RabbitMQ, Kafka, or Spring Framework with disclosed unpatched CVEs is a direct Requirement 6.3.3 finding. QSAs document it. The cardholder data environment's PCI DSS certificate is affected.

How QSAs Evaluate EOL Software

Qualified Security Assessors assess EOL software differently depending on context:

Scenario 1: EOL software with no CVEs currently disclosed

Many QSAs will allow this with appropriate compensating controls documented in the ROC (Report on Compliance), along with a remediation timeline. The key is documentation: the entity must demonstrate awareness of the EOL status, monitoring for new CVE disclosures, and a defined migration timeline.

Scenario 2: EOL software with disclosed, unpatched CVEs

This is a finding. Compensating controls may be considered but are harder to justify when an exploitable vulnerability exists in a component of the CDE. Most QSAs require either patching evidence or a very specific technical compensating control (network isolation, WAF rules, etc.) that demonstrably addresses the specific vulnerability.

Scenario 3: EOL software with third-party patches applied

Third-party patches from a vendor like OSSeva, with documented CVE attestation letters and CVSS evidence, are generally accepted by QSAs as satisfying Requirement 6.3.3 for the specific CVEs addressed. The assessor looks for: patch source verification, build signing (OSSeva provides GPG-signed artifacts), regression testing evidence, and documentation of what was patched and when.

What Documentation Does OSSeva Provide for PCI Audits?

OSSeva Assure provides a PCI DSS-specific compliance package with each patch cycle:

• CVE attestation letters: Per-CVE documentation identifying the vulnerability ID, CVSS score, affected version, patch delivery date, patch source, and OSSeva's attestation that the vulnerability has been remediated in the delivered build.
• Patch cadence evidence: A log of all patch deliveries with dates, satisfying QSA questions about whether the entity's own patch SLA was met.
• Build provenance: GPG-signed artifacts with SHA-256 checksums, enabling QSAs to independently verify that deployed builds match the OSSeva-provided patched build.
• Requirement 6.3 mapping matrix: A table mapping each CVE addressed to the specific PCI DSS Requirement 6.3 sub-requirement, formatted for direct submission to QSA teams.

The one-month window — and what it actually covers

Since v4.0.1, PCI DSS Requirement 6.3.3 sets the one-month window for critical vulnerabilities specifically, as ranked under 6.3.1 — not for every security patch. For EOL open source, OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High-severity CVEs within 7 days. Both sit inside a one-month window with margin, and OSSeva provides timestamped delivery records for QSA review.

Compensating Controls for EOL Software

If an immediate patch is not available, PCI DSS Appendix B provides a compensating controls framework. The compensating control must meet the intent of the original requirement and provide an equivalent level of defense. For EOL software, common compensating controls include:

• Network isolation of the system from other CDE components
• WAF or IDS rules specifically blocking exploitation attempts for the disclosed CVE
• Increased logging and monitoring focused on indicators of exploitation
• Expedited migration timeline with board-level approval

Note that compensating controls are evaluated per-CVE by the QSA. A WAF rule that blocks the specific exploit for CVE-XXXX-YYYY may satisfy a compensating control for that specific CVE, but it does not satisfy the requirement broadly — the next disclosed CVE would require a new compensating control analysis. Extended lifecycle support with active patching is typically a more sustainable approach.

A Note on Self-Assessment vs. QSA-Assisted Assessment

Merchants completing SAQ (Self-Assessment Questionnaire) are sometimes more lenient with themselves on EOL software findings than QSAs would be in a formal assessment. If your organization is moving from SAQ to QSA-assisted assessment — common as companies grow or as payment volume increases — previously tolerated EOL software will become formal findings. It's worth addressing proactively.