PCI DSS and End-of-Life Software: What Requirement 12.3.4 Asks For, and How to Show an Assessor
PCI DSS does not ban end-of-life software by name: the standard lists no product or version you must stop running. What PCI DSS v4.0.1 does require, in Requirement 12.3.4, is a review of the hardware and software technologies in use at least once every 12 months that checks whether vendors still ship security fixes promptly, documents vendor "end of life" announcements, and includes a plan approved by senior management to remediate outdated technologies. That review has been a required part of every PCI DSS assessment since March 31, 2025. The harder edge is Requirement 6.3.3, which gives you one month from release to install patches for critical vulnerabilities: software whose vendor has stopped publishing fixes leaves you nothing to install.
What the standard says, requirement by requirement
The wording below is paraphrased from PCI DSS v4.0.1 as reproduced in the PCI Security Standards Council's Self-Assessment Questionnaire D, which carries each requirement and its expected testing. The authoritative text is the standard itself in the PCI SSC Document Library.
| Requirement | What it asks for (paraphrased) | Where end-of-life software runs into it |
|---|---|---|
| 12.3.4 | Review hardware and software technologies in use at least once every 12 months. The review covers four things: whether the technologies still receive security fixes from vendors promptly; whether they still support, and do not preclude, the entity's PCI DSS compliance; documentation of industry announcements or trends, such as a vendor's end-of-life plans; and a plan, approved by senior management, to remediate outdated technologies, including those with announced end-of-life plans. | The only requirement that says "end of life" outright. It applies to products already past their end date and to products whose vendor has only announced one. |
| 6.3.3 | Protect all system components from known vulnerabilities by installing applicable security patches. Patches for critical vulnerabilities (ranked by the 6.3.1 process) go in within one month of release; all others within a time frame the entity sets from its own risk ranking. | A product with no vendor patch stream fails this the first time a critical vulnerability is published against it. The expected testing compares installed patches with the vendor's recent patch lists. |
| 6.3.1 | Identify new security vulnerabilities from industry-recognized sources and give each a risk ranking. The process covers bespoke and custom software and third-party software, for example operating systems and databases. | The vulnerabilities still arrive after end of life; the ranking still has to happen. Only the fix stops. |
| 6.3.2 | Keep an inventory of bespoke and custom software, and of the third-party software components built into it, to support vulnerability and patch management. | The frameworks and libraries built into your own payment applications belong here, with their versions; many teams list the language runtime they ship with too. |
| 12.5.1 | Maintain and keep current an inventory of the system components in scope for PCI DSS, with a description of each one's function or use. | The list the 12.3.4 review starts from. Without versions on it, there is nothing to compare against a vendor's end-of-life date. |
| 2.2.1 | Configuration standards cover all system components, address all known security vulnerabilities, follow industry-accepted hardening standards or vendor hardening recommendations, and are updated as new vulnerabilities are identified. | Vendor hardening guidance for a retired product often stops being updated, so the configuration standard can fall behind the vulnerabilities it is meant to address. |
Requirements 12.3.4 and 6.3.2 were new in PCI DSS v4.0 and were future-dated: best practices until the effective date above, required since. The one-month window in 6.3.3 is narrower in v4.0.1 than it was in v4.0. PCI DSS v4.0 applied it to critical or high-security patches; v4.0.1 applies it to patches for critical vulnerabilities, and the Council's own FAQ on vulnerability risk rankings says the same.
The words that matter
Two phrases in 12.3.4 do most of the work. The first covers announcements, not only dates already passed: the review documents industry announcements "such as when a vendor has announced 'end of life' plans for a technology" (PCI DSS v4.0.1, Requirement 12.3.4). A product that is fully supported today but has a published end date is already in scope of the review. The second is the approval: the remediation plan is approved by senior management, which turns a list of old servers into a decision someone accountable has signed.
What 12.3.4 does not say
- It does not set a deadline for replacing anything. The deadline is whatever the approved plan says, and the plan has to be credible to an assessor.
- It does not treat extended support as a pass or a fail. The first bullet asks whether technologies still receive security fixes promptly. A paid support contract that delivers fixes answers that question; an expired one does not.
- It is tested on paper. The expected testing is to examine documentation and interview personnel, so an assessor looks for the documents: the review record, the end-of-life findings, and the signed plan.
PCI SSC's 2020 information supplement PCI DSS for Large Organizations, written before v4.0 and supplementary to the standard rather than a requirement, gives the planning advice the requirement now formalizes: plan for end-of-life events well before the deadline, replace assets in stages rather than starting at the end date, and treat compensating controls adopted for an end-of-life emergency as temporary, with a clear upgrade plan as part of the control. It also advises knowing when a new system and its components are expected to reach end of life before deploying it.
What an assessor will ask to see
Put yourself in the assessor's chair. The policy says outdated technologies are reviewed every year. The natural first question is "show me." This is the evidence pack that answers it:
| Evidence | Requirement | What good looks like |
|---|---|---|
| Inventory of in-scope system components | 12.5.1 | Every server, appliance, database and operating system in scope, with product, exact version and function. Current, not last year's export. |
| Software and component inventory for your own applications | 6.3.2 | Runtimes, frameworks and libraries inside bespoke and custom software, with versions. An SBOM per application is a practical form. |
| Support status and end-of-life date per item, with its source | 12.3.4 | For each product version: supported, approaching an announced end date, or past it; the date; and where the date came from, so the assessor can check it. |
| The dated review record | 12.3.4 | Who reviewed, when, what changed since the last review, and the conclusion for each outdated technology. At least once every 12 months. |
| Remediation plan with senior management approval | 12.3.4 | Each outdated technology, the action (upgrade, replace, retire, cover with paid support), the owner, the target date, and the approval. |
| Patch evidence | 6.3.3 | Installed patches compared with the vendor's recent patch list. For a product past end of life, the paid support contract and its patch history, or a Compensating Controls Worksheet. |
When a compensating control is the honest answer
Sometimes the end-of-life system cannot move before its date: a vendor-certified platform under a card terminal estate, a mainframe interface, an application whose replacement is a year away. PCI DSS allows compensating controls only where the entity has a legitimate and documented technological or business constraint. The Compensating Controls Worksheet (Appendix B of the SAQ, with guidance in Appendices B and C of PCI DSS) records six things:
- The constraint that precludes meeting the original requirement.
- The definition of the compensating controls and how they address the original requirement's objective and any increased risk.
- The objective of the original control, and the objective the compensating control meets.
- The additional risk created by not having the original control.
- How the compensating controls were validated and tested.
- The processes and controls that keep them in place.
For an end-of-life system the measures commonly proposed are isolation (network segmentation and tightly limited access), additional monitoring of the host, and a fixed retirement date in the 12.3.4 plan. Whether they are enough is your assessor's decision, not ours. PCI SSC's own large-organization guidance is explicit that controls adopted for an end-of-life emergency are not a long-term state.
A worked example: four rows from a typical financial estate
Here is how real products look in a 12.3.4 review. The dates in this table are refreshed from our lifecycle data at every build, so they stay current when a vendor moves a date.
| Component | End-of-life date | Status | What the 12.3.4 record should say |
|---|---|---|---|
| Windows Server 2012 R2 | Oct 10, 2023 | EOL | Past the end of Microsoft's extended support, and Microsoft's Extended Security Updates program for it ran to Oct 13, 2026. Record the migration target date; anything still running needs a compensating control and a near retirement date. |
| Windows Server 2016 | Jan 12, 2027 | Approaching | Still supported, but the end date is announced, which is exactly what the third bullet of 12.3.4 asks you to document. Put the upgrade, or paid Extended Security Updates, in the approved plan now. |
| Red Hat Enterprise Linux 7 | Jun 30, 2024 | EOL | Maintenance Support has ended. Red Hat's paid Extended Life Cycle Support add-on runs to May 31, 2029: with it, keep the subscription and the errata history as patch evidence; without it, there is no vendor patch source. |
| Oracle JDK 8 | Mar 31, 2022 | EOL | Premier Support has ended; Oracle lists Extended Support to Dec 31, 2030. A Java runtime inside your payment application is a third-party component for 6.3.2, so record which Java 8 build you run and whether your contract covers it. |
Three patterns show up in almost every estate. Some rows are past the end date and need a decision now. Some are supported but announced, and the plan has to cover them before they turn. And some are past the vendor's standard end date but still receive fixes under a paid program, which is a legitimate answer for the review as long as the contract is current and the product stays in the plan, because extended support has its own end date. Vendors occasionally publish a fix after end of life for an actively exploited flaw, as the PHP project did for PHP2Shell; that is a one-off, not a support commitment, and does not take a product out of the plan.
How to automate the evidence
The 12.3.4 review is annual, but end-of-life dates move between reviews: vendors extend them, shorten them and announce new ones. The evidence is most defensible when the inventory is checked against lifecycle data continuously and the yearly review signs off on a record that already exists. endoflife.ai publishes end-of-life dates for 700+ products, and every answer names the source of its date.
1. The API, with a free key
Look up any product and version and get the status, the end-of-life date, days remaining or days past, and the source URL of the date. That source field is what the assessor's "where did this date come from?" needs. Get a free API key (emailed, no credit card); the API documentation covers batch lookups and SBOM enrichment.
curl -H "X-API-Key: YOUR_KEY" https://api.endoflife.ai/v1/status/rhel/7The response includes status, eol_date, days_past_eol, eol_date_source and eol_date_source_url.
2. Zabbix, for estates already monitored there
A bank watching 500 servers in Zabbix already has the inventory 12.3.4 starts from. Our agentless Zabbix template (Zabbix 6.0 and later, merged into the community templates repository) makes one HTTP call an hour and creates an item per component with lifecycle status, days until end of life and latest release, with triggers for end of life, approaching end of life and high risk. The trigger history becomes a running record of when each technology crossed its date. See it on the integrations page.
3. Splunk, for inventory already indexed
The endoflife.ai app for Splunk adds an eollookup search command: pipe any search that has product and version fields through it and each row gains support status, end-of-life date with days remaining or past, CISA KEV exposure and the source of the date. Save the search as a scheduled report and it becomes the 12.3.4 worksheet. Details on the integrations page.
4. SBOMs, for your own payment applications
Requirement 6.3.2 asks for the third-party components inside bespoke and custom software. Upload a CycloneDX or SPDX SBOM, or a package manifest, to the scanner for a one-off report, or post it to the API for every build. How to audit an SBOM for end-of-life software explains why matching by package URL is safer than matching by name.
5. Service desk and other tools
If remediation runs through a service desk, the HaloPSA integration writes end-of-life dates and their sources onto assets and can open a ticket for each asset past end of life, so the remediation plan has an owner and a queue. Datadog, Dynatrace, Grafana, a GitHub Action and an MCP server for AI assistants are on the integrations page. For the policy itself, the free EOL policy template includes a PCI DSS mapping alongside its remediation SLAs and exception process.
The PCI DSS versions themselves
The standard has its own lifecycle, which matters when you read older guidance. PCI DSS v3.2.1 was retired on March 31, 2024. PCI DSS v4.0.1, a limited revision with no added or deleted requirements, was published on June 11, 2024, and v4.0 was retired on December 31, 2024. Every version's dates are on the PCI DSS version page. Guidance that cites v3.2.1 requirement numbers (6.2 for patching, for example) predates the current numbering.
Frequently Asked Questions
Does PCI DSS prohibit end-of-life software?
Not by name. PCI DSS v4.0.1 lists no product or version you must stop running. Requirement 12.3.4 requires a review of the hardware and software technologies in use at least once every 12 months, covering whether vendors still ship security fixes promptly, documenting vendor end-of-life announcements, and documenting a plan approved by senior management to remediate outdated technologies. Requirement 6.3.3 requires patches for critical vulnerabilities within one month of release, which software without a vendor patch source cannot meet without a paid support arrangement or a documented compensating control.
Which PCI DSS requirement covers end-of-life software?
Requirement 12.3.4 is the one that names end of life: the annual technology review must document vendor end-of-life announcements and include a senior-management-approved plan to remediate outdated technologies, including those with announced end-of-life plans. Requirements 6.3.1 (identifying and risk-ranking vulnerabilities, including in third-party software such as operating systems and databases), 6.3.3 (patch time frames), 6.3.2 (inventory of bespoke and custom software and its third-party components) and 12.5.1 (inventory of in-scope system components) are where end-of-life software shows up in practice.
When did PCI DSS Requirement 12.3.4 become mandatory?
Since March 31, 2025. Requirement 12.3.4 was one of the future-dated requirements introduced in PCI DSS v4.0: a best practice until that date, after which it must be fully considered in every PCI DSS assessment. PCI DSS v4.0.1, a limited revision, added and deleted no requirements and did not change that effective date.
Can an end-of-life system stay in the cardholder data environment with a compensating control?
Only where the entity has a legitimate and documented technological or business constraint. The Compensating Controls Worksheet records the constraint, the objective of the original requirement, the risk, the compensating controls, how they were validated, and how they are maintained. PCI SSC guidance for large organizations warns that compensating controls adopted for an end-of-life emergency should not be assumed to last, and that a clear upgrade plan should be part of the control. Your assessor decides whether a given control is acceptable.
Does paid extended support satisfy PCI DSS for an end-of-life product?
It can restore what the requirements look for: a vendor or provider that still ships security fixes, and patches you can install within the 6.3.3 time frames. Keep the contract, the coverage scope and the patch history as evidence, and keep the product in the 12.3.4 remediation plan, because extended support has its own end date. Whether a particular third-party patch source is acceptable is a judgement for your assessor. Options by product are on the extended support page.
How do I show PCI DSS 12.3.4 evidence to an assessor?
Bring four things: the inventory of in-scope system components with product and version; for each, the vendor support status and end-of-life date with the source it came from; the dated record of the review carried out at least once every 12 months; and the remediation plan for outdated technologies with senior management approval. The expected testing for 12.3.4 is to examine documentation and interview personnel, so the documents carry the weight.
Sources
Read at the PCI Security Standards Council for this guide:
- PCI SSC, Summary of Changes from PCI DSS Version 3.2.1 to 4.0 (Revision 1): 12.3.4 and 6.3.2 as new, future-dated requirements.
- PCI SSC, Self-Assessment Questionnaire D for Merchants, PCI DSS v4.0: requirement text and expected testing. The v4.0.1 edition of the same questionnaire, in the PCI SSC Document Library, was used for the v4.0.1 wording.
- PCI SSC blog, Just Published: PCI DSS v4.0.1.
- PCI SSC blog, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x.
- PCI SSC blog, PCI DSS v3.2.1 retirement questions and answers.
- PCI SSC FAQ 1597, on vulnerability risk rankings and resolving or addressing vulnerabilities.
- PCI SSC information supplement, PCI DSS for Large Organizations, section on end-of-life assets.
Related Resources
- PCI DSS versions and their end-of-life dates
- How to Build a Software EOL Management Program That Survives an Audit
- DORA and legacy ICT: what EU financial entities must do about end-of-life systems
- NIS2 and end-of-life software
- TLS versions and what compliance requires
- Unsupported software detection
- EOL Watch: lifecycle date changes, tracked as they happen
- Extended support options for products past end of life