What PCI DSS 4.0.1 Clarified (and What It Didn't)

The PCI Security Standards Council (PCI SSC) published PCI DSS v4.0.1 on June 11, 2024. It's a limited revision. It corrects formatting and typographical errors and clarifies the intent of some requirements and guidance, but it adds no new requirements and deletes none. You can still use v4.0 until it retires on December 31, 2024, and the March 31, 2025 effective date for future-dated requirements hasn't moved. The clarifications that matter most cover patching timelines, payment page scripts, MFA, issuers' storage of sensitive authentication data, targeted risk analysis and third-party service provider relationships.

What is PCI DSS 4.0.1?

Version 4.0.1 is a cleanup of v4.0, not a new standard. The Council's announcement says plainly that, as a limited revision, it contains no new or deleted requirements.

The accompanying Summary of Changes from v4.0 to v4.0.1 labels each change as either "Clarification or Guidance" or "Structure or Format." Nothing is categorized as an "Evolving Requirement," the label used for changes that alter what entities must do. Some clarifications still have practical effects, though, so they're worth reading closely.

What are the key dates?

What did PCI DSS 4.0.1 clarify?

Patching timelines (6.3.3)

This is the change with the most day-to-day impact. Version 4.0 required both critical and high-security patches to be installed within one month of release. Version 4.0.1 reverts to the v3.2.1 language: the one-month window applies to patches for critical vulnerabilities, as ranked under your 6.3.1 process.

All other applicable patches are installed within a timeframe based on your own assessment of the criticality of the risk. The "within three months" example moved out of the requirement text and into the examples, and the guidance now recommends a targeted risk analysis to set those timeframes. If you tightened high-risk patching for v4.0, you don't have to loosen it. Whatever you decide, document why.

Payment page scripts and tamper detection (6.4.3 and 11.6.1)

Both requirements remain future-dated to March 31, 2025, and both gained three applicability notes explaining how they apply when your page embeds a third-party service provider's or payment processor's payment form, for example in an iframe. In short, scripts on your own page are yours to manage, while scripts inside the provider's embedded form are the provider's responsibility. The guidance adds that you should expect the provider to give you evidence it meets the requirement.

Requirement 6.4.3 also now says the script inventory needs a written "business or technical justification" for each script. It includes guidance for cases where authorizing a script before it changes isn't practical. Requirement 11.6.1 now refers to "security-impacting HTTP headers and the script contents of payment pages," and "weekly" replaces "once every seven days."

Multi-factor authentication (8.4.x and 8.5.1)

• 8.4.2 now says "non-console" access into the CDE, making the intended scope explicit. A new applicability note says the requirement doesn't apply to user accounts that authenticate only with the class of strong, attack-resistant factors the standard defines in its glossary (FIDO2 security keys are the usual example).
• 8.4.3 uses "remote access" instead of "remote network access," moves the list of covered access types into an applicability note, and adds third parties to the testing procedure.
• 8.4.1 moves the statement that MFA is a best practice for non-console administrative access to in-scope systems outside the CDE from an applicability note into Good Practice.
• 8.5.1 adds a definition of a replay attack and examples of ways to protect against one.
• 8.3.9 clarifies that it doesn't apply to in-scope system components where MFA is used.

Stored sensitive authentication data and hashing (3.3.x and 3.5.1.x)

For issuers and companies that support issuing services, the notes to 3.3.1, 3.3.2 and 3.3.3 now tie any storage of sensitive authentication data to "a legitimate and documented business need" and describe what that means. Requirement 3.3.1 and its sub-requirements now say "stored" rather than "retained," for consistency.

Requirement 3.5.1.1, on keyed cryptographic hashes, gained a customized approach objective. A new note says it will replace the one-way hash bullet in 3.5.1 once its effective date is reached, and another covers systems that generate keyed hashes of a PAN for comparison by another system. Requirement 3.5.1.2, on disk-level and partition-level encryption, gained a customized approach objective and notes on encryption types and issuers.

Targeted risk analysis (12.3.1)

Requirement 12.3.1 now clearly applies only to PCI DSS requirements that specify completing a targeted risk analysis. It also clarifies that the analysis must determine and justify how your chosen frequency or process minimizes the likelihood or impact of the threat. A new Further Information section points to the Council's targeted risk analysis guidance and sample templates.

Third-party service providers (12.8.2, 12.9.1 and 12.9.2)

• The notes now separate an "agreement" from an "acknowledgement" and state that a provider's written acknowledgment confirms it is responsible.
• Evidence that a provider meets a requirement, such as its compliance documentation, isn't the same as a written agreement.
• In 12.9.2, the duty to share PCI DSS compliance status now applies to all providers. The duty to explain which requirements are the provider's responsibility applies to providers whose services meet customers' PCI DSS requirements or can affect the security of customers' account data.

Vulnerability scanning (11.3.1.x)

Requirements 11.3.1, 11.3.1.1 and 11.3.1.3 now consistently refer to vulnerabilities that are "critical or high-risk," and to everything else as those not ranked that way. The guidance adds that scan results should feed your broader vulnerability management process, drawing on multiple sources of vulnerability information.

Other clarifications worth knowing

• A new sub-section in Section 4 covers account data received accidentally through an unintended channel. The content previously sat in a note to 4.2.1.
• Section 7 clarifies the description of significant change, and when an assessment counts as "initial" for a requirement with a defined timeframe.
• Requirement 9.2.1 notes that it doesn't apply to locations publicly accessible to consumers.
• The customized approach sample templates moved out of Appendix E and onto the PCI SSC website.
• Appendix G adds new definitions, including "Legal Exception" and "Visitor," and clarifies others such as "Entity," "Interactive Login" and "Payment Page."

What didn't PCI DSS 4.0.1 change?

Just as important is what stayed the same:

• No new requirements, and none removed. The requirement set is the one you've been planning against.
• No new deadlines. March 31, 2025 still stands for future-dated requirements. The only new date is v4.0's retirement on December 31, 2024.
• No wholesale cut to future-dated obligations. The 51 future-dated requirements in the v3.2.1-to-v4.0 Summary of Changes are still future-dated. A few notes narrow how requirements apply in specific situations, such as embedded payment forms, but nothing was withdrawn. Authenticated internal scanning, automated log reviews, the web application protection in 6.4.2 and the rest remain on the 2025 list.
• No relief for future-dated work through 6.3.3. The patching reversion adjusts a requirement that already applies. It doesn't touch anything on the 2025 list.

Should you switch to 4.0.1 now?

Version 4.0 remains valid until December 31, 2024, so there's no emergency. Agree with your QSA which version your next assessment will use, bearing in mind that the Council is targeting the third quarter for the v4.0.1 reporting templates.

Either way, revisit the areas the clarifications touch: your patching policy under 6.3.3, how 6.4.3 and 11.6.1 apply to any embedded payment forms, your 8.4.2 design, your provider agreements and acknowledgements, and the list of requirements that need a targeted risk analysis.

Frequently asked questions

Does 4.0.1 extend the March 31, 2025 deadline?

No. The Council states that the limited revision doesn't affect the effective date of the future-dated requirements.

Do we need to redo our v4.0 gap assessment?

No. Review the requirements listed in the Summary of Changes and update your plan where a clarification changes your interpretation.

Can we slow down patching for high-risk vulnerabilities?

The one-month window now applies only to critical vulnerabilities. Other patches follow timeframes you set based on risk, which should be documented and justified. A targeted risk analysis is the recommended way to do that.

Which version should our 2024 assessment use?

Either v4.0, until it retires on December 31, 2024, or v4.0.1. Agree on it with your QSA early, because it determines which reporting template they'll use.

Key takeaways

• PCI DSS 4.0.1 clarifies. It doesn't add requirements, and it doesn't move the March 31, 2025 date.
• Version 4.0 retires on December 31, 2024.
• The practical changes are patching timelines in 6.3.3, embedded payment forms under 6.4.3 and 11.6.1, MFA wording, and provider agreements.
• Keep your 2025 roadmap intact. The future-dated work is all still there.