PCI DSS v4.0.1 · Financial services
PCI DSS 4.0 and unsupported software
PCI DSS v4.0.1 does not ban end-of-life software. It asks for patches for critical vulnerabilities within one month of release (Requirement 6.3.3) and a yearly review of every technology, with a management-approved plan for outdated ones (12.3.4). On a line with no upstream patches, you need a patch source or a documented plan.
Published . Clause text checked 26 October 2026against the sources listed at the foot of the page. OSSeva's evidence supports your own assessment; it does not make you compliant.
Clauses
PCI DSS requirements that touch end-of-life software
Four requirements in PCI DSS v4.0.1 decide how an assessor treats a component whose open source project has stopped releasing fixes. They cover vulnerability management (6.3.1 to 6.3.3) and the yearly technology lifecycle review (12.3.4). Two of them, 6.3.3 and 12.3.4, are the ones most findings cite, and both need a remediation record.
| Requirement | What it asks | Why end of life puts it in play |
|---|---|---|
| 6.3.1 Vulnerability identification and ranking | Find new vulnerabilities from industry sources, give each a risk ranking, and cover third-party software such as operating systems and databases. | The ranking is yours. It decides which patches fall under the one-month rule, so a scanner score is an input, not the answer. |
| 6.3.2 Software inventory | Keep an inventory of bespoke and custom software and the third-party components inside it, to support vulnerability and patch management. Required since 31 March 2025. | An open source library inside your own code belongs on the list with its version, so its end-of-life date can be checked. |
| 6.3.3 Patching | Protect all system components from known vulnerabilities. Patches for critical vulnerabilities, as ranked under 6.3.1, are installed "within one month of release". Other applicable patches follow a time frame set by your risk assessment. | The clock starts at a patch's release. On a line the project has stopped patching, no release happens unless a supplier ships one. |
| 12.3.4 Technology review | Review hardware and software technologies at least every 12 months: prompt vendor fixes, continued support for your PCI DSS compliance, vendor end-of-life announcements, and a plan approved by senior management to remediate outdated technology. Required since 31 March 2025. | An end-of-life notice is a documented review input, and the plan has to name how and when the outdated technology is dealt with. |
Key changes: which version applies, and when
The version history matters because assessors, SAQs and older scanner reports quote different editions. The future-dated requirements in v4.0 (including 6.3.2 and 12.3.4) became mandatory on 31 March 2025. Merchants and service providers both answer 6.3.3 and 12.3.4: the clause text appears in the PCI SSC's SAQ D for merchants and in the one for service providers.
| Date | Event |
|---|---|
| 31 March 2022 | PCI SSC publishes PCI DSS v4.0. |
| 31 March 2024 | PCI DSS v3.2.1 retires. |
| 11 June 2024 | PCI SSC publishes v4.0.1, a limited revision that adds or deletes no requirements. |
| 31 December 2024 | PCI DSS v4.0 retires; v4.0.1 is the only supported version. |
| 31 March 2025 | Future-dated requirements, including 6.3.2 and 12.3.4, change from best practice to required. |
Wording note. The 6.3.3 text changed between v4.0 and v4.0.1: v4.0 puts the one-month clock on "critical or high-security" patches, while v4.0.1 puts it on patches for critical vulnerabilities and leaves other patches to a time frame you justify. This page reads v4.0.1, taken from the PCI SSC's SAQ D for service providers (revision 2, January 2025), and 12.3.4 is identical in v4.0. The standard PDF sits behind a PCI SSC download agreement, so confirm the wording in the standard with your assessor.
For financial-services buyers, the same clauses sit beside DORA and procurement questions on the financial services page.
Requirement 6.3.3
How the one-month clock behaves on an ended line
Requirement 6.3.3 counts from the release of a patch. On a supported release line the project publishes the patch and the clock starts that day. On a line that has reached end of life, the project publishes nothing, so there are only three states: a supplier ships a fix and the clock starts at that build's release date, no fix exists and 6.3.3 cannot be met as written, or you have moved to a supported line.
The SAQ's expected testing for 6.3.3 includes comparing the list of patches installed with recent vendor patch lists. For an ended line that list no longer exists upstream, so the useful record is a CVE record per release: the CVE identifier, the CVSS score, the affected versions, the patch delivery date and the build identifier.
| Assessor step | What they look for | Record that answers it | Who holds it |
|---|---|---|---|
| Examine policies and procedures (6.3.3) | A patch policy that states the one-month rule and the 6.3.1 ranking method. | Your policy and your ranking of each CVE. | You |
| Examine system components (6.3.3) | The version and build on each in-scope host. | Build identifier on the host, with the SBOM for that build. | You, with the SBOM from OSSeva |
| Compare installed patches with vendor patch lists (6.3.3) | That each critical vulnerability has a patch installed inside a month of its release. | The CVE record per release: CVE id, CVSS, affected versions, patch delivery date, build identifier. | OSSeva supplies the record; you hold the install date |
| Examine documentation (12.3.4) | The yearly review: vendor fixes, support for your compliance, end-of-life notices, and the approved plan. | The end-of-life date for the line (see the EOL tracker), the review, the plan and the approval. | You, with the date from OSSeva |
An illustration of the timing
This is an arithmetic illustration, not a customer story. Say a Critical CVE is disclosed on day 0 for a line the project no longer patches. OSSeva patches Critical CVEs within 48 hours, so a patched build is released by day 2 and its release date goes on the CVE record. Your one-month window under 6.3.3 then runs from that release date, which leaves most of a month to test and install.
A High CVE is patched within 7 days. Under v4.0.1 the one-month rule is written for critical vulnerabilities, so how fast you install a High patch is set by your own 6.3.1 ranking and your risk assessment.
Evidence
Evidence a QSA expects, item by item
A Qualified Security Assessor (QSA) works from records, not promises. For one patched build OSSeva supplies the items below; the matrix on the compliance hub lists the same evidence against every framework. Compliance documentation is part of OSSeva Assure and is delivered under NDA, and OSSeva's SOC 2 Type II report is available under NDA for vendor risk review.
| Item | What it records | Supports |
|---|---|---|
| Patched build | The build with its release date and build identifier, signed with GPG (packages and Maven artifacts) or cosign (container images) with a SHA-256 checksum. Patches apply to upstream source, with no fork. | 6.3.3 |
| CVE record and attestation letter | CVE id, CVSS, affected versions, patch delivery date and build identifier for each release. | 6.3.3, 12.3.4 |
| SBOM | The components in the patched build, in CycloneDX or SPDX. | 6.3.2 as an input |
| VEX statement per CVE | Whether the CVE is fixed in this build or does not affect it, with the reason, so a scanner finding on a version number has an answer. | 6.3.3, scanner findings |
| End-of-life date | The date the line reached end of life, from the version page, with the date you checked it. | 12.3.4 |
| Assure documentation | Evidence matrices and remediation records for the frameworks your auditors use. | Your audit file |
An SBOM or a software composition analysis scan can build the 6.3.2 inventory, but neither says whether a CVE was fixed in the build you run. That is the job of the VEX statement and the CVE record. Verify a signed build yourself with the steps on the security page. What stays with you does not change: ranking the vulnerabilities, installing the build, the yearly review, the plan and the management approval. For how assessors read this kind of evidence, see what auditors accept for end-of-life software and the longer PCI DSS audit guide.
Options
Four ways to answer an end-of-life finding
A finding that a component is past end of life is answered one of four ways. They are not exclusive: most plans combine them, and 12.3.4 wants the plan on paper.
| Option | Fits when | What the assessor sees | Watch for |
|---|---|---|---|
| Upgrade to a supported release | A supported target exists and you can schedule the change. | A version on a supported line, with the change record. | The upgrade is the plan that 12.3.4 asks for. Extended support is the bridge while it happens. |
| Extended support: a patched build from a supplier | The upgrade needs time, or the component cannot move yet. | Patched builds with release dates and CVE records, plus the dated upgrade plan. | A patch source, not a control. Your assessor decides whether a third-party patch counts as an applicable security patch, so ask early. |
| Compensating control | A legitimate, documented technological or business constraint stops you meeting the requirement as written. | A completed Compensating Controls Worksheet. | It is a last resort with six documented parts, and it must address the original objective and the added risk. |
| Reduce scope | The component can sit outside the cardholder data environment (CDE). | Network and CDE scope documentation. | Your QSA confirms scope. OSSeva does not scope your environment. |
Is extended support a compensating control?
No. A patched build from a supplier is a way to meet 6.3.3 by installing patches, so it sits in the "In Place" column if the assessor accepts the patch source. A compensating control is something different: the SAQ says only entities with a legitimate and documented technological or business constraint can use one, and the answer is "In Place with CCW".
The Compensating Controls Worksheet in the PCI SSC's SAQ D (Appendix B) asks for six things: the constraints, the definition of the compensating controls, the objective of the original control, the identified risk, how the controls were validated and tested, and the process to maintain them. If you cannot install a patch at all, that is where isolation and monitoring for the component would be written down. If you can install OSSeva's build, you do not need the worksheet for 6.3.3.
Service levels
Service levels and what drives the price
Critical CVEs are patched within 48 hours and High within 7 days, for every technology OSSeva supports. OSSeva Operate adds 24/7 coverage with a 15-minute P1 response, a 1-hour P2 and a 4-hour P3. OSSeva Assure includes 24/7 reactive support and the audit evidence. A response time is when an engineer picks up the call; the patch windows are when a fixed build is delivered.
OSSeva does not publish prices. Support is priced per cluster, not per core, per GB or per node, in three tiers (Patch, Assure and Operate). The drivers are how many clusters and which technologies and versions are in scope, and which tier you choose. A 15-minute discovery call confirms scope and sends a quote.
Not a fit for
- You want an assessor. OSSeva is not a QSA, does not certify that you comply with PCI DSS and does not file reports of compliance for you.
- The component is closed source or owned by a vendor. OSSeva patches open source lines; check yours on the supported versions page.
- You cannot install a patched build inside your own change window. The evidence shows what was patched and when; the install date is yours.
- You need a compliance guarantee. The evidence supports your assessment, and your assessor decides what it proves.
Does PCI DSS allow end-of-life software?
PCI DSS v4.0.1 does not ban it by name. Requirement 6.3.3 asks that patches for critical vulnerabilities are installed within one month of release, and 12.3.4 asks for a review at least every 12 months with a senior-management-approved plan to remediate outdated technology, including technology with an announced end of life. If no patch exists for a critical vulnerability, 6.3.3 cannot be met as written, so you need a patch source, an upgrade or a compensating control.
Is extended support a compensating control?
No. Extended support supplies patched builds, which you install to meet 6.3.3. A compensating control is documented on the Compensating Controls Worksheet and is only available where a legitimate, documented technological or business constraint stops you meeting the requirement as written. Your assessor decides whether a patch from a third party counts as an applicable security patch.
When did Requirement 12.3.4 become mandatory?
Requirement 12.3.4 was a best practice until 31 March 2025 and has been required since. PCI SSC's v4.0.1 revision, published on 11 June 2024, did not change that effective date.
Does 6.3.3 apply to open source libraries and databases?
Yes. Requirement 6.3.3 covers all system components, and 6.3.1 names third-party software such as operating systems and databases. Requirement 6.3.2 adds an inventory of the third-party components inside your own software, so a library with a known end-of-life date should be on that list.
Sources
Checked 26 October 2026. Clause numbers and wording are from the official texts below. OSSeva does not certify that you comply with any of these rules, does not act as an assessor and does not file reports for you.
Get a quote
Need PCI DSS evidence for open source you cannot upgrade yet?
Ask for a sample evidence pack. It shows what one patched build ships with: the SBOM, VEX statements, signed build and CVE record. Your assessor decides what it proves.