PCI DSS 4.0.1: The Future-Dated Requirements Now in Force

If your business stores, processes, or transmits cardholder data, the PCI DSS grace period is over. Since 31 March 2025, the 51 “future-dated” requirements introduced in PCI DSS v4.0 are fully mandatory. They are no longer best practice. On any assessment against the current standard, a gap in one of these controls is now a finding that can hold up your Attestation of Compliance.

As a PCI QSA practice working across New Zealand and Australia, this is the single most common question we field: which requirements actually apply now, and where are businesses still exposed? This guide answers that precisely, grouped so you can turn it into a work list.

The timeline, in one table

PCI DSS v4.0 introduced 64 new requirements. Thirteen applied immediately when v3.2.1 retired. The other 51 were labelled “best practice until 31 March 2025” so organisations had time to implement them. That runway has now closed. Note that v4.0.1 was a limited revision: it clarified guidance and applicability notes but added and removed no requirements, and it did not move the 31 March 2025 date.

Client-side security for e-commerce: 6.4.3 and 11.6.1

These are the two requirements causing the most confusion, and the two most relevant to any business taking payments online. They exist to counter Magecart-style digital skimming, where attackers inject or alter JavaScript on a checkout page to quietly harvest card data in the shopper’s browser, invisible to server-side controls.

• Requirement 6.4.3 requires you to manage every script that loads and runs on your payment page in the consumer browser: authorise each script, assure its integrity, and keep an inventory with a written justification for each one.
• Requirement 11.6.1 requires a change-and-tamper-detection mechanism that alerts your team to unauthorised modification of the HTTP headers and the payment page content as received by the shopper’s browser. It must run at least every seven days, or at a frequency set by a Targeted Risk Analysis.

An important nuance many sources get wrong. In January 2025 the PCI SSC published a revised SAQ A that removed 6.4.3, 11.6.1 and 12.3.1. In their place it added a new eligibility criterion: the merchant must confirm its site is not susceptible to script-based attacks affecting the e-commerce system, and that every element of the payment page delivered to the customer’s browser originates only and directly from a PCI DSS compliant third party or payment processor (this covers full redirects and embedded iframes). So if you validate with SAQ A and genuinely meet that criterion, these two controls do not apply to you. For every other e-commerce channel, they are in force. If you are unsure which SAQ fits, our SAQ Selector walks you through it.

Authentication: 8.3.6, 8.4.2, 8.5.1 and the machine accounts

• 8.3.6: minimum password length of 12 characters (8 where a system genuinely cannot support 12), with alphanumeric complexity.
• 8.4.2: multi-factor authentication for all access into the cardholder data environment, not just remote or administrative access.
• 8.5.1: MFA implemented securely, so it resists replay, cannot be bypassed, and requires at least two different factor types.
• 8.6.1, 8.6.2, 8.6.3: application and system (“machine”) accounts must be governed. No hard-coded passwords in scripts, configuration or code, and their credentials must be protected, changed periodically and on any suspicion of compromise.

Targeted Risk Analysis and the annual reviews: 12.3.1 to 12.3.4

• 12.3.1: for every requirement where the standard lets you choose the frequency of a control, you must perform a Targeted Risk Analysis that documents the asset, the threat, the factors driving likelihood and impact, and a justified frequency. Each analysis is reviewed at least every 12 months.
• 12.3.2: a separate Targeted Risk Analysis is required for any requirement you meet through the Customized Approach, showing the control achieves protection equivalent to the defined approach.
• 12.3.3: review the cryptographic cipher suites and protocols in use at least every 12 months.
• 12.3.4: review your hardware and software technologies at least every 12 months, tracking anything approaching end of life or end of support.

The Targeted Risk Analysis is the connective tissue of v4.x. Several other requirements point back to 12.3.1 for their frequency, so getting your TRA methodology right is one of the highest-leverage things you can do.

Data protection: 3.4.2 and 3.5.1.1

• 3.4.2: when personnel use remote-access technologies, technical controls must prevent copying or relocating the PAN, except for those with a documented, explicit authorisation and legitimate need.
• 3.5.1.1: if you render the PAN unreadable using hashing, it must now be a keyed cryptographic hash of the entire PAN. A simple one-way hash is no longer sufficient.

Access reviews, logging and detection

• 7.2.4: review all user accounts and their access privileges at least every six months.
• 7.2.5 and 7.2.5.1: assign and manage all application and system accounts by least privilege, and review their access at a frequency set by a Targeted Risk Analysis.
• 10.4.1.1: use automated mechanisms to perform audit log reviews.
• 10.7.2 and 10.7.3: detect, alert on, and promptly respond to failures of critical security control systems. 10.7.2 now extends this obligation to all entities, not only service providers.

Malware, phishing and vulnerability management

• 5.3.3: anti-malware scans of removable electronic media while in use.
• 5.4.1: processes and automated mechanisms to detect and protect personnel from phishing attacks.
• 11.3.1.1: manage all other applicable vulnerabilities, meaning those not ranked high or critical, found in internal scans.

Awareness training and incident response

• 12.6.3.1 and 12.6.3.2: security awareness training must cover current threats such as phishing and social engineering, and the acceptable use of end-user technologies.
• 12.10.4.1: use a Targeted Risk Analysis to set the frequency of periodic incident-response training.
• 12.10.5: your incident-response plan must include monitoring and responding to alerts from security monitoring systems, explicitly including the change-and-tamper detection for payment pages from 11.6.1.

Service-provider-only requirements

Three of the newly mandatory requirements apply only to service providers:

• 11.4.7: multi-tenant service providers must support their customers’ requests for external penetration testing.
• 11.5.1.1: detect, alert or prevent, and address covert malware communication channels.
• 12.5.2.1: confirm PCI DSS scope at least every six months and on any significant change.

What this means for your next assessment

If you were assessed before 31 March 2025 and treated these as future work, your next assessment will hold you to all of them. The controls that most often trip businesses up are the client-side e-commerce requirements, MFA into the full cardholder data environment, the Targeted Risk Analyses, and the six-monthly access reviews, because they require process and evidence, not just a configuration change.

The practical path is straightforward: confirm your scope, map your current state against the list above, and close the process gaps first, since those take the longest to generate evidence for. A good QSA will tell you where you stand well before a formal assessment, so there are no surprises in the report.

How Cianaa can help

Cianaa is an independent PCI QSA practice serving businesses across New Zealand and Australia. We run readiness reviews against the current v4.0.1 requirements, help you build defensible Targeted Risk Analyses, and take you through to a clean Report on Compliance or SAQ. If you would like a straight answer on where you stand, talk to our assessors.

Your v4.0.1 readiness checklist

Use this as a fast self-check. If you cannot answer yes to each item with evidence to hand, that is where your next assessment will focus.

1. Have you confirmed and documented your PCI DSS scope within the last 12 months, and for service providers, within the last six months (12.5.2 and 12.5.2.1)?
2. Is multi-factor authentication enforced for all access into the cardholder data environment, not just remote and administrative access (8.4.2), and is it resistant to replay (8.5.1)?
3. Are your minimum passwords at least 12 characters (8.3.6), and are application and system accounts free of hard-coded credentials (8.6.2)?
4. For e-commerce, have you either confirmed eligibility for the revised SAQ A, or implemented payment page script management (6.4.3) and change-and-tamper detection (11.6.1)?
5. Have you produced a Targeted Risk Analysis for every control whose frequency you set (12.3.1), and a separate analysis for any Customized Approach control (12.3.2)?
6. Do you review all user accounts every six months (7.2.4), and application and system account access at your TRA-defined frequency (7.2.5.1)?
7. Are cryptographic cipher suites (12.3.3) and hardware and software technologies (12.3.4) reviewed at least every 12 months?
8. Does your security awareness training cover phishing and social engineering (12.6.3.1), and does your incident response plan monitor the alerts from your tamper-detection mechanism (12.10.5)?

Frequently asked questions

Are the PCI DSS v4.0.1 future-dated requirements mandatory now?

Yes. Since 31 March 2025 all 51 future-dated requirements are mandatory and are assessed as ordinary requirements. Before that date they were best practice and not scored.

What is the difference between PCI DSS v4.0 and v4.0.1?

v4.0.1 is a limited revision published on 11 June 2024. It clarified guidance and applicability notes and fixed errata, but added and removed no requirements. It also did not change the 31 March 2025 deadline.

Do 6.4.3 and 11.6.1 apply to my e-commerce site?

It depends on how you take payments. If you qualify for the revised SAQ A published in January 2025 and meet its eligibility criterion, these two requirements do not apply. For other e-commerce channels, they are mandatory. A QSA or our SAQ Selector can confirm which applies to you.

What is a Targeted Risk Analysis?

It is a documented analysis, required by Requirement 12.3.1, that justifies how often you perform a control the standard lets you set the frequency for. It records the asset, the threat, the factors affecting likelihood and impact, and the resulting frequency, and it is reviewed at least every 12 months.