What changed in PCI DSS 4.0.1, and what didn't

By Edward Casteloes, founder of Compliance Colleague · 15 years in GRC and PCI DSS · September 21, 2026

The short version: PCI DSS v4.0.1, published by the PCI Security Standards Council in June 2024, is a limited revision. The Council was explicit that there are no new or deleted requirements. It fixed errors and clarified intent, and v4.0 was retired on December 31, 2024, so v4.0.1 is the only active version. The March 31, 2025 date that made v4.0’s future-dated requirements mandatory did not move.

“No new requirements” doesn’t mean “nothing to do”, though. Several clarifications change how requirements are scoped and assessed.

The changes that matter in practice

6.3.3: Patching, back to “critical only”. v4.0 had widened the one-month patching window to critical and high-risk vulnerabilities. v4.0.1 reverts to the v3.2.1 position: the one-month window applies to critical vulnerabilities. Everything else is patched within the timeframe your risk ranking sets. Check that your vulnerability management procedure reflects this, and doesn’t hold you to a stricter rule you no longer need.

6.4.3 and 11.6.1: Payment-page scripts. New notes clarify how these apply when a merchant embeds a third party’s payment form, for example in an iframe:

the merchant is responsible for scripts on its own page, outside the embedded form;
the service provider is responsible for scripts inside it.

11.6.1’s change- and tamper-detection is clarified to cover security-impacting HTTP headers and the script contents of payment pages.

8.4.x: MFA and phishing-resistant authentication. A note says the MFA requirement for non-console access into the CDE doesn’t apply to user accounts that authenticate only with phishing-resistant factors, such as FIDO2 passkeys. “Phishing-resistant authentication” is now a defined term in Appendix G.

Requirement 3 (3.3.x and 3.5.x): Issuers and keyed hashes. There are two clarifications:

Notes clarify that issuers, and companies supporting issuing services, may store sensitive authentication data where there is a legitimate, documented business need.
The keyed cryptographic hash guidance is clarified. It applies to PAN wherever it is stored, including non-primary locations such as logs.

12.8 and 12.9: Third-party service providers. Updated notes clarify what TPSPs must provide customers: their PCI DSS compliance status, and which requirements each party is responsible for. If your TPSP responsibility matrix is vague, this is the clause to point to.

Appendices.

The Customized Approach sample templates moved out of Appendix E to the PCI SSC website.
Appendix G gained three definitions: Legal Exception, Phishing-Resistant Authentication and Visitor.

The related change most people missed: SAQ A (January 2025)

This wasn’t part of v4.0.1 itself, but it landed in the same window. In January 2025 the Council updated SAQ A, effective March 31, 2025:

Removed from SAQ A: Requirements 6.4.3 and 11.6.1, and 12.3.1 insofar as it supported 11.6.1.
Added in their place: a new eligibility criterion. The merchant must confirm its site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).

The requirements still exist in PCI DSS v4.0.1. What changed is how an SAQ A merchant validates, and that new eligibility statement is doing a lot of work. A merchant who signs it without evidence has swapped a control for an attestation.

What’s next

In June 2026 the Council opened a Request for Comments on v4.0.1, running June 3 to July 20, 2026, to shape the next iteration of the standard. No version number or publication date has been announced.

How to use this

Update procedures where v4.0.1 relaxed or clarified requirements (6.3.3 and 8.4.x) so you aren’t assessed against stricter wording than the standard now uses.
Revisit your payment-page script inventory and TPSP responsibility matrix (6.4.3, 11.6.1, 12.8 and 12.9). These are where assessment findings cluster.
SAQ A merchants: document how you concluded your site isn’t susceptible to script attacks before you sign.

Compliance Colleague answers questions like “What does 6.4.3 require when my payment form is in an iframe?” from the text of PCI DSS itself, with the requirement cited. Try it free, no card required →

This guide summarizes the published PCI DSS v4.0.1 text and PCI SSC guidance, with sources below. Confirm against the official standard before relying on it in an assessment. Not legal advice.

Sources