PCI DSS v4.0: what changed and the 2025 enforcement deadlines

PCI DSS v4.0 was published in March 2022 with most new requirements treated as best practice through March 31, 2025. From that date forward, assessors test against the full v4.0 standard. Many teams that scraped through their 2024 attestation against v3.2.1 are now seeing v4.0-specific findings on their 2025 reports.

Here is what changed in v4.0, what tripped teams up in the first year of full enforcement, and the specific requirements worth checking before the next attestation.

The headline changes

1. Customized approach

The biggest structural change in v4.0. Entities can now meet a requirement using a customized approach: tailored controls supported by a targeted risk analysis, assessed against the requirement's intent rather than a prescriptive control. This is distinct from compensating controls, which remain available for legitimate constraints preventing standard implementation.

In practice, the customized approach is rarely the right answer for SaaS. The defined approach (standard controls) is faster to assess, predictable in scope, and what most QSAs prefer. Customized approach makes sense for unusual architectures where the prescriptive control does not match the risk model.

2. Targeted risk analysis

Several v4.0 requirements require a per-control targeted risk analysis to set frequencies or scope. Examples:

• Requirement 5.2.3.1: frequency of malware scans on systems not commonly affected by malware.
• Requirement 8.6.3: frequency of password changes for application and system accounts.
• Requirement 11.6.1: frequency of payment page change-detection scans.

A generic enterprise risk assessment does not satisfy these. Each targeted analysis has to address that specific control, with documented inputs and conclusion.

3. Expanded MFA scope

v3.2.1 required MFA for administrative access to the CDE and all remote access. v4.0 extends MFA to all access into the CDE, regardless of role, effective from March 31, 2025. Anti-phishing-resistant MFA (FIDO2, certificate-based) is preferred but not yet mandatory; SMS-based MFA remains technically allowed but is increasingly flagged.

4. Stronger authentication baseline

Password requirements were updated. Minimum length increased to twelve characters (or seven if the system technically cannot support twelve). Account lockout after ten failed attempts. Specific password change rules tied to MFA presence and account type.

5. Cryptographic agility

v4.0 requires entities to track cryptographic algorithm and protocol use, and to plan for retirement of weak cryptography. The intent is preparedness for post-quantum migration; the practical effect today is a documented inventory of where TLS, encryption, and signing happen.

6. Payment page integrity

Requirements 6.4.3 and 11.6.1 target Magecart-style attacks on payment pages. Inventory of all scripts loaded into payment pages, integrity verification (SRI or equivalent), and detection of unauthorized changes. New as of v4.0.

What tripped teams up in 2025

Scope creep from new MFA

Teams that had MFA on admin access often did not have it on developer access into the CDE through tooling like CI/CD systems, observability platforms, or jump hosts. The expanded scope flushed out ambient access paths that had not been thought of as “CDE access”.

Missing targeted risk analyses

First-time v4.0 assessments routinely flag missing or generic targeted risk analyses. The fix is straightforward: write a discrete one-page analysis per applicable requirement, link it to the control decision. The omission is the only common pattern.

Payment page script inventory

Many SaaS embedding tag managers, analytics, or A/B testing tools on checkout pages discovered they had no inventory of which scripts loaded. The integrity verification is technically straightforward (SRI hashes) but requires the inventory to exist first.

Cryptographic inventory

Cryptographic agility requires knowing where you use what. For most SaaS this means cataloging TLS configurations, JWT signing algorithms, database encryption, S3 SSE settings, and KMS key usage. Catalog can live in your existing risk register or separately; auditor wants to see it exists and is current.

Requirements worth checking before next attestation

• 1.4.4: system component inventory must include a cryptographic algorithm and protocol section.
• 3.4.2: keying material rotation schedule documented and followed.
• 5.4.1: anti-phishing controls in place to protect against phishing attacks.
• 6.3.3: vulnerabilities ranked by criticality; high-risk and critical addressed within risk-based timeframes.
• 6.4.3: payment page script inventory plus integrity check.
• 8.3.6: minimum twelve-character password length (or seven if system does not technically support twelve).
• 8.4.2: MFA for all access into the CDE.
• 11.6.1: change-detection mechanism for payment pages with frequency set per targeted risk analysis.
• 12.3.1: targeted risk analyses documented and reviewed annually.

Compensating controls vs customized approach

Often confused. Compensating controls remain available when an entity cannot meet a requirement due to legitimate technical or business constraints; they are documented in Appendix C and assessed annually. Customized approach is a different path: meet the requirement with controls tailored to the entity, supported by a targeted risk analysis, assessed against the requirement's intent.

For most SaaS, compensating controls handle the rare cases where standard controls cannot apply. Customized approach is overhead that pays off only when the architecture genuinely demands it.

Continuing changes through 2026

v4.0.1 was published in June 2024 with errata and clarifications, no substantive new requirements. The PCI SSC has signaled v4.x point releases will continue with additional clarifications; track them through the SSC document library if you operate against PCI DSS regularly.

Practical sequencing

For a SaaS approaching v4.0 attestation:

1. Refresh the cardholder data flow diagram. Stale flows are the most common Stage 1 issue.
2. Review CDE access paths against the expanded MFA requirement; close gaps.
3. Write the targeted risk analyses for each applicable v4.0 requirement.
4. Inventory payment page scripts; add SRI or equivalent integrity verification.
5. Create the cryptographic algorithm and protocol inventory.
6. Verify v4.0 password policy is enforced; check for residual v3.2.1 settings.

For a deeper dive on PCI DSS scoping, segmentation, and SAQ versus ROC differences, see the PCI DSS pillar. Talk to HSD if you want a v4.0 readiness assessment for your environment.