TL;DR
- Plan against PCI DSS v4.0.1. It is the only active version, and the requirements that were future-dated have been mandatory since March 31, 2025. PCI SSC has set no date for a next version.
- Expect findings in application code. MFA, hard-coded credentials, stored card data and logging are built into custom legacy applications, and a runtime patch leaves them unchanged.
- Treat Requirement 12.3.4 as a yearly planning duty. It asks for an annual review of every technology in use and a senior-management-approved plan to remediate outdated ones.
- Use compensating controls and extended support for a defined period. Compensating controls need documentation in every assessment and cannot cover a past miss. Extended support covers third-party frameworks and runtimes only.
- Write the remediation plan per application. Name a path for each one, such as upgrade, re-architecture, replacement or retirement, with dates leadership approves and assessors can track.
PCI DSS v4.0.1 Status and Mandatory Requirements in 2026
PCI DSS 4.0 compliance in 2026 means compliance with PCI DSS v4.0.1, the only active version of the standard. Its requirements have all been mandatory since March 31, 2025. For legacy applications, the hardest requirements are the ones a patch cannot satisfy, such as multi-factor authentication (MFA), hard-coded credentials and stored card data.
The PCI Security Standards Council (PCI SSC) published v4.0.1 in June 2024 as a limited revision with “no additional or deleted requirements.” It corrected wording and clarified intent. The table shows where each version and deadline stands in 2026, based on PCI SSC’s announcements:
| Item | Status in 2026 |
| Active version | PCI DSS v4.0.1, the only version assessed |
| PCI DSS v4.0 | Retired December 31, 2024 |
| PCI DSS v3.2.1 | Retired March 31, 2024 |
| The 51 requirements once future-dated | Mandatory since March 31, 2025 |
| Next version | No published date or version number |
2026 is the first full calendar year in which every assessment takes place after the March 2025 deadline.
PCI SSC ran a request for comments on v4.0.1 from June 3 to July 20, 2026, to decide whether and how to revise it. It has published no date or version number for a successor, so v4.0.1 is the standard to plan against.
Why Legacy Applications Are Harder to Keep PCI DSS 4.0 Compliant Than Infrastructure
Guidance on PCI DSS and outdated technology concentrates on servers, operating systems, network devices and open-source libraries. An outdated server can be upgraded or replaced on a schedule, and a library can move to a patched release.
A custom application holds its security behavior in its own code. The login screen, the way it stores service passwords, the format it writes card data in and what it logs were all decided by the developers who built it. A runtime patch leaves all of that as it is.
That makes custom applications in the cardholder data environment (CDE) the harder case. The CDE covers the systems that store, process or transmit card data.
The pattern holds across stacks. It covers VB6 desktop applications and ASP.NET systems facing .NET Framework 4.8 end of support. It also covers systems that need a Java EE to Spring Boot migration and Oracle Forms applications. Fixing them often means working on code with no current documentation.
Running End-of-Life Software Under PCI DSS 4.0
No PCI DSS requirement bans end-of-life software by name. Running it in the CDE puts three requirements at risk:
- 6.3.3: Critical and high-security patches must be installed within one month of release. An unsupported runtime receives none from its original vendor.
- 6.3.2: An inventory of custom software and its third-party components must be kept, which depends on knowing what the code contains.
- 12.3.4: Each technology must be reviewed at least once every 12 months for vendor support, with an approved plan for those that have lost it.
The same legacy software compliance risk appears in other regulated frameworks, with card data as the protected asset.
Where Legacy Applications Fail PCI DSS 4.0 Compliance, Requirement by Requirement
These are the v4.0.1 requirements custom legacy applications most often fail:
| Requirement | What it asks | Why legacy applications struggle | Remediation options |
| 6.3.3 | Critical and high patches within one month | Out-of-support runtimes get no patches | Runtime upgrade, extended support, re-platforming |
| 6.3.2 | Inventory of custom software and its components | Undocumented code, untracked libraries | Inventory generated from source code |
| 6.2.1, 6.2.4 | Secure development of custom software | Code predates current secure-coding practice | Code-level fixes or re-architecture |
| 8.4.2 | MFA for all access into the CDE | Built-in logins with no hook for MFA | MFA-enforcing access layer, or rebuilt authentication |
| 8.3.6 | Passwords of at least 12 characters | Fixed-length password fields. The 8-character fallback applies only where a system cannot support 12 | Rebuilt authentication module |
| 8.6.1 to 8.6.3 | Managed application accounts, no hard-coded passwords | Credentials written into code, scripts and config files | Secrets moved to a vault, code changed to read them |
| 4.2.1, 12.3.3 | Strong cryptography for card data sent over public networks, yearly cipher review | Old TLS versions built into the runtime | Runtime upgrade or a modern target stack |
| 3.5.1 | Card numbers (PAN) unreadable wherever stored | Plain card numbers in databases, flat files and logs | Tokenization, encryption, data clean-up |
| 10.2.1, 10.4.1.1 | Audit logs enabled, automated log review | Limited or no application logging | Logging added in code, or a modernized application |
Patching and extended support address the 6.3.3 row, and 4.2.1 where the runtime supplies the TLS (transport encryption) stack. The other rows depend on how the application was written, and each needs a code change or a new application.
The $0 Security Assessment maps each finding in a legacy application, from end-of-life runtimes to hard-coded secrets, to its exact code location.
+morePCI DSS Requirement 12.3.4 Explained
PCI DSS Requirement 12.3.4 requires a review of all hardware and software in use at least once every 12 months. The review checks that each technology still gets vendor security fixes and still supports PCI DSS compliance. It ends in a senior-management-approved plan to remediate outdated technology. It has been mandatory since March 31, 2025.
The v4.0.1 standard lists four elements:
- Vendor fix analysis: Whether each technology continues “to receive security fixes from vendors promptly.”
- Compliance support analysis: Whether each technology still supports the entity’s PCI DSS compliance and does not block it.
- End-of-life documentation: Industry announcements and trends, such as a vendor’s end-of-life plans for a technology.
- Approved remediation plan: A plan “approved by senior management, to remediate outdated technologies,” including those with announced end-of-life dates.
The second element applies to application code. A runtime that still receives patches can host an application whose login cannot support MFA, and the review has to record that gap.
“All hardware and software” includes the runtimes, frameworks and libraries inside custom applications. Inventories built for servers and network devices often leave these out.
Documenting those four elements produces three records:
- A dated review record for the last 12 months
- Support status for each technology, including application runtimes and frameworks
- The approved plan, with progress shown against its dates
What PCI DSS Requirement 12 Asks of Legacy Systems
PCI DSS Requirement 12 sets the governance around the technical controls in Requirements 1 to 11. Five of its sub-requirements apply directly to legacy applications:
| Requirement | Frequency | What it means for a legacy application |
| 12.3.1 | For each requirement that calls for a targeted risk analysis | A documented targeted risk analysis, for example for how often application account passwords change under 8.6.3 |
| 12.3.2 | For each requirement met with the customized approach | Applies only when an application control is assessed under the customized approach |
| 12.3.3 | Every 12 months | Review of cipher suites and protocols, including those built into old runtimes |
| 12.3.4 | Every 12 months | Technology review and approved remediation plan |
| 12.5.2 | Every 12 months, and every 6 months for service providers (12.5.2.1) | Scope confirmation covering data flows, system components and connections into the CDE |
PCI DSS offers two ways to meet a requirement. The defined approach meets it as written. The customized approach meets its stated objective with a different control, backed by a targeted risk analysis.
12.3.2 applies only to requirements an entity meets with the customized approach. A legacy application assessed under the defined approach falls under 12.3.1 for its risk analyses.
Taken together, Requirement 12 turns legacy-application risk into recurring governance work, reviewed every year and signed off by senior management.
Compensating Controls vs Extended Support vs Modernization for Legacy Applications
Three paths exist for a legacy application that cannot meet a requirement as written. They differ in what they fix and how long they last.
Compensating Controls
PCI SSC’s June 2026 guidance says compensating controls apply when “a legitimate technical or business constraint” prevents an organization from meeting a requirement as stated. They are a valid option within the defined approach, and their cost recurs in four ways:
- Documentation in each cycle: Each instance is documented separately and must satisfy the requirement’s objectives. The assessor validates them in each assessment.
- No retroactive use: PCI SSC has stated that they “cannot be used to retroactively address a requirement that was missed in the past.”
- Risk stays in place: The outdated technology remains, and no compensating control restores vendor patches that have stopped.
- A higher bar for documentation: The same guidance states that incomplete documentation can leave an assessor unable to validate the control.
Extended Support and Modernization
Extended support delivers security patches for frameworks and runtimes after the original vendor stops. Modernization changes the application through an upgrade, re-architecture or replacement. The three paths compare on fit, coverage and what each leaves open:
| Path | Fits when | Addresses | Leaves open |
| Compensating controls | A documented constraint blocks a requirement for now | The specific requirement, assessment by assessment | The outdated technology and the recurring documentation |
| Extended support | The application is maintained and meets the other requirements | Patches for covered frameworks and runtimes (6.3.3) | Custom code, MFA, hard-coded credentials, stored card data |
| Modernization | The application’s design blocks requirements | The design gaps behind the findings | Delivery time and cost |
Many programs combine the three. Extended support and compensating controls cover the application for a dated period, and modernization replaces it module by module through the strangler fig approach.
How to Build a PCI DSS 12.3.4 Remediation Plan for Legacy Applications
For a custom application, the PCI DSS 12.3.4 remediation plan is a modernization roadmap. An assessor can follow a plan that names a path and a date for every outdated technology.
A 12.3.4 remediation plan for legacy applications includes seven parts:
- Inventory: Every application in the CDE, with its language, framework, runtime versions and vendor support status.
- Requirement gaps: The requirements each application cannot meet, and the reason in its code or platform.
- Risk ranking: Applications ordered by exposure, such as internet-facing access, stored card data and missing MFA.
- Path per application: Upgrade, extended support for a set period, re-architecture, replacement or retirement.
- Timeline: Milestones per application that assessors can check progress against.
- Senior management approval: The sign-off 12.3.4 names, renewed with each annual review.
- Interim controls: Compensating controls or extended support in place until each milestone is met.
The inventory is usually the hardest part. Legacy applications often have no current documentation, so the facts about languages, frameworks, libraries and data flows have to come from the source code.
Gen AI-based code analysis can extract that inventory and show where card data and credentials appear in the code, which also feeds 6.3.2. A legacy system audit applies the same review across a wider estate.
Build the 12.3.4 inventory from the code itself
The $0 Security Assessment produces a security debt inventory, a fix approach for each finding and a modernization opportunity map for the legacy applications in your CDE.
Reducing PCI DSS Scope by Modernizing Legacy Applications
Requirement 12.5.2 asks for PCI DSS scope to be confirmed at least once every 12 months and after any significant change, and every six months for service providers. Scope covers every data flow, system component and connection tied to the CDE.
Legacy applications often spread card data widely. Card numbers sit in shared databases, batch files, reports and logs, so every system that touches them joins the CDE.
Re-architecting reduces that spread. Tokenization replaces card numbers with tokens that carry no card data. When card handling moves into a tokenization service or an isolated payment service, modules that only see tokens can leave the CDE once network segmentation is validated.
One example is an order-management application that stores full card numbers in its own database to process refunds. Processing refunds against a token from the payment processor removes those card numbers from that database. Fewer in-scope systems mean fewer requirements to evidence each cycle.
The data layer carries much of this work through database modernization. Issuers apply the same approach in card issuer software modernization.
How Legacyleap’s Gen AI Agents Modernize Legacy Applications for PCI DSS 4.0
Legacyleap is a Gen AI-powered legacy application modernization platform built on multi-agent orchestration. Its agents take a legacy application from the 12.3.4 plan to a modernized, validated release across five stages. Those stages are Assess, Comprehend, Modernize, Validate and Deploy.
The $0 Security Assessment runs first, inside the client’s environment, with findings in 3 to 5 days. It analyzes end-of-life runtimes, vulnerable dependencies, deprecated cryptography, hard-coded secrets and common web vulnerabilities such as injection. Each finding is mapped to its code location, which supplies the inventory, gaps and risk ranking in a 12.3.4 plan.
Five agents then run the modernization:
- Assessment Agent: Produces the technical debt report, dependency map, security vulnerabilities and effort estimate.
- Documentation Agent: Rebuilds architecture diagrams, data flows and a software bill of materials (SBOM) from the code, which supports 6.3.2 and scope work.
- Recommendation Agent: Sets refactor, replace or retain decisions and an ordered migration plan, the path and timeline the 12.3.4 plan needs.
- Modernization Agent: Converts the code to a modern stack as diff-based pull requests, with security modernization covering authentication, encryption and secure communication. About 70% of the work is automated.
- QA Agent: Generates unit, integration, regression and functional tests, and validates 100% functional parity before deployment.
Engineers review every pull request. The agents cannot merge, deploy or execute code, and source code never leaves the client’s environment.
The output is an evidence pack. It links each finding to its fix, records verified closure and shows functional parity, for the compliance team to take into the next assessment. Legacyleap has completed 150+ production-grade assessments.
Next Steps for PCI DSS 4.0 Compliance on Legacy Applications
PCI DSS 4.0 has turned decisions about legacy applications into a yearly obligation with a named approver. Each assessment cycle now looks at the technology review, the approved plan and the progress made against it.
The same pattern runs through the HIPAA Security Rule requirements, the GLBA Safeguards Rule and the SEC cybersecurity disclosure rules, which also put outdated systems under documented, management-level oversight.
For legacy applications in the CDE, the $0 Security Assessment produces the inventory, findings and fix approach a 12.3.4 plan starts from. It takes 3 to 5 days, costs nothing and runs inside your environment. To see how the agents run a modernization first, book a Technical Demo.
FAQs
PCI SSC has announced no v5.0 or other successor. v4.0.1 stays the assessed standard until a new version is published and v4.0.1 is formally retired.
Yes, for requirements that define a customized approach objective. The entity designs its own control, documents a targeted risk analysis under 12.3.2, and the assessor tests the control against that objective.
No. Requirement 8.3.6 allows an eight-character minimum where the system cannot support 12, and that limit belongs in the 12.3.4 review as a technology that restricts compliance.
An MFA-enforcing access layer, such as a gateway or virtual desktop, placed in front of the application can satisfy 8.4.2 for access into the CDE. The application’s own accounts and passwords stay subject to the rest of Requirement 8.
A system that handles only tokens, with no access to card numbers or the token vault, can fall out of scope once segmentation is validated. The service that performs tokenization stays in scope.
Senior management, as the requirement states. PCI DSS names no job title, so the approver is usually the executive accountable for the PCI DSS program, such as the CISO or CIO.
References
- PCI Security Standards Council, “Just Published: PCI DSS v4.0.1.”
- PCI Security Standards Council, “Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x.”
- PCI Security Standards Council, “Request for Comments: PCI Data Security Standard (PCI DSS) v4.0.1.”
- PCI Security Standards Council, “Payment Card Industry Data Security Standard, v4.0.1.”
- PCI Security Standards Council, “PCI SSC Publishes New Guidance on Compensating Controls and the Customized Approach.”
- PCI Security Standards Council, “PCI DSS v4.0: Compensating Controls vs. Customized Approach.”
