PCI DSS v4.0 was published in March 2022 and became the sole active version on March 31, 2024 (when v3.2.1 was retired). But v4.0 contained an important distinction: some requirements were effective immediately upon publication, while others were "future-dated"—delayed to allow organizations time to implement. Those future-dated requirements became mandatory on March 31, 2025. As of March 2026, all organizations must be in full compliance with all v4.0 requirements, including those that were previously future-dated.
For organizations that have not yet completed migration to v4.0, or that are in the middle of v4.0 implementations, understanding the key changes is essential. v4.0 significantly altered how some critical controls are implemented, introduced new requirements not present in v3.2.1, and created optional alternatives (the Customized Approach) for some requirements.
The Philosophy Behind v4.0
Three primary goals drove the development of PCI DSS v4.0. First, the standard needed to address emerging threats and technologies that were not contemplated in v3.2.1. Second, the standard needed to evolve from a compliance-as-checklist mentality to a security-as-continuous-process mindset. And third, the validation methods themselves needed enhancement—moving beyond simple yes/no answers to more sophisticated risk-based and outcome-focused assessments.
The Customized Approach embodies this philosophy shift. Rather than a purely prescriptive standard where "do X" is the only acceptable way to meet "Objective Y," v4.0 introduced an optional framework where mature security organizations can propose alternative controls that still achieve the stated objective of a requirement. This gives large, sophisticated organizations flexibility to implement innovative controls, while still maintaining the prescriptive Defined Approach for organizations that prefer a clear path forward.
| KEY IDEA | v4.0's most significant structural change is the introduction of the "Customized Approach" — a framework that allows organizations to design controls that meet the stated security objective of a requirement in ways that differ from the prescriptive guidance. This gives mature security organizations flexibility but adds documentation and QSA testing burdens. |
The Two Approaches — Defined vs. Customized
Under the Defined Approach, an organization implements the specific controls and procedures described in each requirement, exactly as specified. This is straightforward: the requirement says "implement TLS 1.2 or higher," you implement TLS 1.2 or higher. You pass or you fail. The testing procedures are standard, and the QSA applies them uniformly.
Under the Customized Approach, an organization can propose an alternative control that achieves the same objective as the requirement but using different technology or methodology. For example, a requirement might state the objective as "ensure all user actions in the CDE are individually traceable to a person." The Defined Approach specifies implementing unique user IDs. A Customized Approach might implement biometric authentication or behavioral analytics to achieve the same objective. However, the Customized Approach requires significant additional documentation: a Controls Matrix mapping each alternative control to the objective, a risk assessment demonstrating that the alternative is equivalent to or better than the Defined Approach, and QSA-designed testing procedures specific to that control.
| Aspect | Defined Approach | Customized Approach |
|---|---|---|
| What it is | Follow the prescriptive control specified in the requirement | Design your own control meeting the stated objective |
| Documentation required | Standard control evidence | Controls Matrix, risk assessment, testing procedures |
| QSA testing | Standard testing procedures | QSA designs custom testing procedures |
| Best for | Most organizations; straightforward compliance path | Mature security teams with innovative control designs |
| Risk of failure | Clear pass/fail criteria | Higher — depends on QSA judgment of objective fulfillment |
Most organizations use the Defined Approach. The Customized Approach adds complexity and requires significant documentation and QSA engagement. However, for large organizations with sophisticated security practices, the flexibility can justify the additional effort.
Expanded MFA Requirements
One of the most impactful changes in v4.0 is the expansion of multi-factor authentication (MFA) requirements. In v3.2.1, MFA was required only for remote access to the CDE (Requirement 8.3). In v4.0, MFA is now required for: all access into the CDE from any location (local or remote), all non-console administrative access to system components in the CDE, and all remote network access from outside the CDE by any user (administrator or non-administrator).
v4.0 also defines MFA more specifically. True MFA requires a factor from at least two different categories: something you know (password, PIN), something you have (token, card, phone), or something you are (biometric). Single-factor authentication, no matter how strong, does not satisfy the requirement. Additionally, SMS-based one-time codes are declining in acceptance as MFA (due to SIM-jacking vulnerabilities), and authenticator apps, hardware tokens, or push notifications are preferred.
| IMPORTANT | Requirement 8.2.1 (MFA for CDE access) and 8.4.2 (MFA for non-console administrative access) are among the most impactful v4.0 changes. For many organizations, achieving full MFA coverage required significant infrastructure investment and remediation of legacy systems that lack built-in MFA support. |
E-Commerce and JavaScript Security (Requirement 6.4.3)
A new requirement in v4.0, Requirement 6.4.3 addresses JavaScript-based attacks on payment pages. In recent years, attacks like Magecart have compromised payment pages by injecting malicious JavaScript code. Attackers inject code that steals card data entered by customers. This requirement mandates that merchants and payment processors maintain an inventory of all JavaScript loaded on payment pages, have a method to confirm that each script is authorized (via a whitelist or code review), and have a method to assure the integrity of each script (typically via Subresource Integrity—SRI—headers or Content Security Policy).
This requirement was one of the most significant future-dated requirements, becoming mandatory in March 2025. For e-commerce merchants with complex payment pages that load analytics, chat widgets, marketing tools, and other third-party code, implementing JavaScript management often requires deploying a JavaScript security solution or performing manual code audits and SRI implementation.
The specifics: organizations must maintain a list of authorized scripts with business justification for each, implement a mechanism to verify integrity (SRI headers, code signing, CSP), have a process for authorizing new or changed scripts, and periodically verify that only authorized scripts are loaded. Many organizations discovered during compliance work that they had no idea what code was running on their payment pages—an eye-opening scoping discovery.
Anti-Phishing (Requirement 5.4.1)
A new requirement for anti-phishing mechanisms reflects the reality that phishing is the most common initial access vector for payment card breaches. Attackers send phishing emails to employees, trick them into revealing credentials or clicking malicious links, and gain access to the organization's systems. Requirement 5.4.1 mandates that organizations implement anti-phishing mechanisms including email filtering, URL filtering, and user training. Additionally, organizations must have a means to report suspected phishing to a central security team.
This is a relatively lightweight requirement compared to others, but it represents an explicit acknowledgment in PCI DSS that personnel security (protection against social engineering) is as important as technical security controls.
The Targeted Risk Analysis (TRA)
A significant new concept in v4.0 is the Targeted Risk Analysis (TRA). Certain requirements in v4.0 do not specify a fixed frequency for controls. For example, Requirement 12.3.1 requires risk assessments, but the standard does not say "perform an annual risk assessment" or "every six months." Instead, the standard says "perform risk assessments at a frequency commensurate with your risk." For requirements with this language, organizations must perform a TRA to determine the appropriate frequency.
A TRA documents the specific risks relevant to your organization and systems, the controls implemented to mitigate those risks, and the rationale for the frequency of those controls. For example, a TRA might document: "We have a system accepting 5 million card transactions daily. We have firewalls and intrusion detection systems. Given the transaction volume and the existing controls, we assess that we should perform penetration testing semi-annually rather than annually." The TRA is reviewed annually and updated if risks or controls change.
| The TRA requirement affects 13 specific sub-requirements in v4.0. Organizations that previously had a fixed annual schedule for certain activities may now need to justify that frequency through formal risk analysis. For most organizations, this means creating TRA documentation for these 13 items as a one-time task, then reviewing annually. |
Password and Authentication Enhancements
v4.0 increased the minimum password length from 7 characters (in v3.2.1) to 12 characters. Password complexity requirements also changed—the standard now allows organizations to choose between character-set complexity (uppercase, lowercase, numbers, symbols) or dictionary-based password strength. Additionally, requirements for service accounts—accounts used by applications or automated systems rather than by people—are more explicit in v4.0.
These password changes align PCI DSS with modern security practices. 7-character passwords are vulnerable to brute-force attacks; 12 characters is significantly more resistant. Interestingly, v4.0 also allows organizations to use the Customized Approach to implement passwordless authentication (such as biometrics or hardware keys) if they can demonstrate it meets or exceeds the stated objective of having strong, unique user authentication.
Future-Dated Requirements — Now Active
When PCI DSS v4.0 was published in March 2022, many requirements were marked as "effective immediately" while others were "future-dated" with an effective date of March 31, 2025. The intent was to give organizations time to implement significant changes. However, as of March 31, 2025, all v4.0 requirements are now active and mandatory. There are no more future-dated requirements; all organizations must be fully compliant with all 12 requirements and their sub-requirements.
| Mar 2022 | PCI DSS v4.0 Published | v4.0 released by PCI SSC alongside v3.2.1; some requirements future-dated |
| Mar 2024 | v3.2.1 Retired | v4.0 becomes the sole active standard for all new assessments and validations |
| Mar 2025 | Future-Dated Requirements Active | All v4.0 requirements, including those previously future-dated, are now mandatory |
What This Means for Your Compliance Program
If you have not yet fully transitioned to v4.0, now is the time. Organizations that delayed implementation hoping to extend v3.2.1 compliance beyond the transition date are now behind. All QSA assessments, all validations, all new merchant onboarding, and all renewal validations must be against v4.0. If you have completed v4.0 implementation but missed specific future-dated requirements, an audit or reassessment will expose those gaps.
The most common gaps we see in v4.0 implementations: incomplete MFA coverage (local access and non-console admin access), missing JavaScript inventory on payment pages (Requirement 6.4.3), missing TRA documentation for 13 specific sub-requirements, password policy updates not implemented across all systems, and anti-phishing mechanisms not fully deployed or tested.
| In our experience working with Indonesian payment organizations through the v4.0 transition, the three most commonly missed requirements are 6.4.3 (JavaScript on payment pages), 8.4.2 (MFA for all CDE access), and 12.3.2 (TRA for specific sub-requirements). These three are worth prioritizing in any gap assessment. |