PCI-DSS 4.0 Changes and New Requirements Explained

Why PCI-DSS 4.0 Is a Material Change, Not a Refresh

Version 3.2.1 served as the standard from 2018 through March 2024. Its successor was not a cosmetic revision. The PCI Security Standards Council used version 4.0 to address threat patterns — particularly e-commerce skimming, credential-based attacks, and the operational gap between annual-assessment compliance and continuous security — that version 3.2.1 did not adequately address. Several requirements that were “best practices” under 3.2.1 became mandatory on April 1, 2025, after a twelve-month transition grace period.
Organizations that completed a 3.2.1 assessment before the March 2024 deadline and have not since conducted a 4.0 gap review carry compliance risk. PCI-DSS assessments are annual obligations; the next assessment cycle for any organization operates exclusively under version 4.0 requirements.

The Six Most Significant Changes in PCI-DSS 4.0

1. Multi-Factor Authentication Now Required for All CDE Access (Requirement 8)

Under version 3.2.1, MFA was required for remote access into the cardholder data environment (CDE). Version 4.0 extends that requirement: MFA is now required for all non-console administrative access and for all user access to systems in the CDE, regardless of whether the connection originates from inside or outside the network perimeter. This is the single change with the broadest operational impact for organizations that relied on network-boundary MFA enforcement alone.
The password minimum length requirement also increased from 8 to 12 characters (where supported by the system). Inactive account lockout is now triggered at 15 days of inactivity rather than 90. Service account passwords must be changed at least every 12 months or based on a documented targeted risk analysis. SENTRY managed detection and response continuously monitors authentication events across CDE systems, surfacing MFA bypass attempts and inactive account anomalies in real time.

2. Payment Page Script Management (Requirement 6.4)

Web skimming attacks — where adversaries inject malicious JavaScript into payment pages to capture cardholder data in transit — were not adequately addressed in version 3.2.1. Requirement 6.4 under version 4.0 requires that organizations with payment pages manage and authorize all scripts executing on those pages. Specifically, organizations must maintain an inventory of all scripts, document the business justification for each, and deploy a mechanism to ensure that unauthorized scripts cannot execute. Acceptable technical approaches include content security policy headers, sub-resource integrity hashing, or equivalent controls validated to prevent unauthorized script execution.
This requirement applies to all organizations that operate payment pages, whether the payment processing itself is outsourced or not. E-commerce merchants that assumed full payment outsourcing placed them in SAQ A should verify that their eligibility criteria are still met under 4.0; the script management requirement may change the applicable SAQ type.

3. Targeted Risk Analysis for Certain Control Frequencies (Requirement 12.3)

Version 3.2.1 prescribed specific calendar frequencies for many controls — quarterly vulnerability scans, annual penetration tests, semi-annual firewall rule reviews. Version 4.0 introduces a formal “targeted risk analysis” methodology that allows organizations to justify control frequency based on documented risk analysis rather than a fixed calendar schedule, for specific controls where the standard permits this flexibility.
The targeted risk analysis must identify the assets or controls being analyzed, document the threats the control is intended to address, assess the likelihood and potential impact of compromise if the control frequency is reduced, and document the resulting frequency determination with sign-off by senior management. This is not a blanket waiver — it applies only to specific controls enumerated in the standard, and the documentation must be defensible to a QSA. Organizations treating targeted risk analysis as a shortcut to reduce compliance burden without proper documentation create assessment risk rather than eliminating it.

4. Phishing-Resistant MFA and Security Awareness Enhancements (Requirements 5 and 8)

Version 4.0 explicitly addresses phishing as a threat vector in the security awareness training and anti-phishing controls requirements. Organizations must implement anti-phishing mechanisms for personnel with access to the CDE, and security awareness training programs must address phishing and social engineering specifically. Where technically feasible, phishing-resistant MFA (defined as authentication methods that are not susceptible to phishing, such as FIDO2/WebAuthn or hardware security keys) is required for administrative access to CDE systems.

5. Continuous Monitoring Expectations Elevated (Requirements 10 and 11)

Requirements 10 (log management) and 11 (security testing) in version 4.0 reinforce that compliance monitoring must be continuous or near-continuous for in-scope systems — not periodic. Requirement 10 introduces an expectation of automated mechanisms to detect and alert on anomalies and suspicious activity in log data in near real time. Organizations that manually review logs on a weekly or monthly basis do not satisfy this intent. Requirement 11 adds requirements for internal vulnerability scanning at least every three months and after significant changes, and requires that results be reviewed and acted upon.
SENTRY’s managed detection and response operationalizes Requirements 10 and 11 directly: logs from all CDE-scope systems are centralized, retained for 12 months (with 3 months immediately available), and monitored continuously with documented alert review. The SENTRY SOC’s daily operations produce the ongoing evidence record that satisfies both the 3.2.1 and 4.0 monitoring requirements. Learn more about overall PCI-DSS compliance management at PCI-DSS Compliance.

6. Expanded Scope for Customized Approach (All Requirements)

Version 4.0 introduced the “Customized Approach” as an alternative to the traditional “Defined Approach” for organizations that implement security objectives through controls that differ from the specific requirements described in the standard. Under the Customized Approach, an organization must demonstrate to its QSA that its control achieves the stated security objective of the requirement, rather than implementing the requirement exactly as written. This path requires a higher burden of documentation and assessor validation. It is intended for mature organizations with sophisticated security programs, not as a general flexibility mechanism. Most mid-market organizations will continue to follow the Defined Approach.

What the 4.0 Changes Mean for Mid-Market Organizations

The operational impact of PCI-DSS 4.0 concentrates in three areas for mid-market merchants and service providers. First, the expansion of MFA to all CDE access — not just remote — typically requires deploying or re-configuring identity and access management across internal systems that were previously exempt. Second, the payment page script management requirement necessitates a technical review of e-commerce infrastructure and likely implementation of content security policy or equivalent controls. Third, the continuous monitoring expectations require organizations to move from periodic log review to operational SIEM or MDR engagement.
Armorstack’s VERITY advisory team conducts PCI-DSS 4.0 gap assessments that compare current control posture against both the Defined Approach requirements and the best-practice future-dated items that became mandatory in April 2025. CORE managed IT services implements the infrastructure changes — MFA deployment, network configuration, patch management — and SENTRY operationalizes the monitoring requirements. For merchant-level context and validation requirements, see PCI-DSS merchant levels. To discuss your organization’s 4.0 readiness posture, talk to an Armorstack compliance expert or start the 90-Day Proof.