PCI DSS v4.0.1: The Future-Dated Requirements Are Live — Here's What's Actually Failing

A payments company in Mumbai told us in April that they were fully v4.0.1 compliant. They had the gap analysis, the policy pack, the MFA rollout, and a signed-off remediation plan from 2024. Then their QSA asked a simple question about their checkout page: show me the inventory of every script that executes on it, and show me how you would know if one changed. There was a long silence. The scripts were there — analytics, a chat widget, two tag-manager containers, a fraud tool. Nobody owned the list, and nothing was watching it.

That is the shape of most PCI DSS failures right now, and it has nothing to do with not knowing the deadline. The 51 future-dated requirements in PCI DSS v4.0.1 stopped being best practice on 31 March 2025. They are ordinary requirements now, tested like any other, and we are far enough past the date that the excuse of "we are working towards it" no longer survives an assessment. This is what is actually failing, and why.

Worth clearing up, because it still causes confusion in scoping calls. PCI DSS v4.0 has been retired — v4.0.1 is the only active version, and it was a limited revision that corrected and clarified rather than added obligations. Of the 64 new requirements introduced in v4.x, 13 applied immediately when v4 became mandatory in March 2024. The other 51 were future-dated with a 31 March 2025 effective date.

So there is no longer a "phase two" to plan for. If your last Report on Compliance or SAQ was signed before those requirements bit, your next one is the first that tests all of them — and that gap is where most organisations are getting caught.

If you take one thing from this piece, take these two. They cover the payment page — the scripts that run on it, and knowing when it changes — and they exist because of Magecart-style e-skimming, where attackers do not breach your server at all. They compromise a third-party script your page already loads, and read the card details out of the browser as your customer types them.

The pattern we see is that 6.4.3 gets answered with a spreadsheet and 11.6.1 with an existing vulnerability scanner. Neither survives testing. 6.4.3 needs a process attached to whoever can change the page — including your marketing team's tag manager — and 11.6.1 needs change detection running at a frequency defined by a targeted risk analysis, not by whatever your scanner already does.

One honest note on scope: these apply to the page as rendered in your customer's browser. If your checkout is a full redirect to your processor, your exposure is genuinely smaller. If it is an iframe embedded in your page, you are still shipping the page that hosts it, and that is where the next section catches people.

This is the most misread development of the last year, and it is costing e-commerce merchants their compliance position.

With SAQ A r1, effective 1 April 2025, requirements 6.4.3, 11.6.1 and 12.3.1 were removed from the questionnaire. A lot of merchants read that headline, concluded the script obligations no longer applied to them, and stopped. What they missed is that the Council added a new eligibility criterion in their place. To use SAQ A at all, the merchant must confirm "that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

Read that carefully. The requirement left the questionnaire and came back as a condition of being allowed to use the questionnaire. There are exactly two ways to satisfy it: implement protection techniques of the kind described in 6.4.3 and 11.6.1 yourself, or obtain confirmation from your PCI DSS compliant processor or TPSP that their solution, implemented per their instructions, protects your payment page from script attacks. Doing neither does not make you compliant with a shorter SAQ — it makes you ineligible for SAQ A.

The distinction that decides which camp you are in is how payment is presented. If you use an embedded payment page or form — an iframe from your provider — this criterion applies to you. If you redirect the customer away entirely, by HTTP redirect, meta tag or JavaScript, or you send them a payment link by email, it does not. FAQ 1588 was published specifically to clear this up, which tells you how much confusion it caused.

The practical action is unglamorous and takes an afternoon: write to your payment provider and ask, in writing, for confirmation that their embedded solution includes techniques protecting your payment page from script attacks. Keep the reply. That letter is your evidence, and most merchants we speak to have never asked for it.

Requirement 8.4.2 requires multi-factor authentication for all non-console access into the cardholder data environment — any role, from any location. Not just administrators. Not just remote access from outside the network.

In a 2024 assessment, an organisation could usually pass by MFA-ing the VPN and the admin jump box. Under the requirement as it now stands, the ordinary application support engineer connecting to a CDE server from a desk inside the office is in scope too. The projects that go badly are the ones that discovered this during the assessment rather than before it, because retrofitting MFA to internal service access is an architecture conversation, not a licensing one.

Internal vulnerability scans must now be authenticated. That single word invalidates a lot of long-standing scan programmes, because unauthenticated scanning sees a fraction of what is actually there — it fingerprints services from the outside instead of reading installed package versions.

Two consequences catch people. First, the finding count usually jumps sharply on the first authenticated run, which is not a regression — it is the first honest picture, and your remediation plan has to absorb it. Second, systems that cannot accept credentials for scanning have to be documented as such, the scanning account needs sufficient privilege to be meaningful, and if that account can be used for interactive login it must be managed under the account-management requirements. Auditors do check the account, not just the report.

Requirement 12.3.1 lets you set the frequency of certain activities yourself, based on a documented targeted risk analysis (TRA). It is the most flexible thing in v4.x and the most commonly faked.

A TRA is not a paragraph justifying the interval you already run. It has to identify the asset being protected, the threat, the factors that make the chosen frequency reasonable, and a review cycle. When an assessor sees five TRAs that all conclude "quarterly" in identical language, they read it for what it is. If you genuinely believe a control can run less often than the conventional interval, the TRA is how you make that case — but it has to be an argument, with reasoning someone else could disagree with.

Start with the payment page, because it is both the most likely to fail and the most likely to be actively exploited while you deliberate — e-skimming is not a theoretical risk, it is the dominant way card data is stolen from e-commerce merchants. Then close MFA scope, because it takes the longest and depends on other teams. Then fix the scanning programme, and absorb the finding count honestly. Do the TRAs last, when you know what you are actually justifying.

One thing not to do: treat a compensating control as the plan. Compensating controls exist for genuine, documented business or technical constraints, and they carry their own assessment burden. "We did not get to it" is not a constraint.

Open your checkout page in a browser, open developer tools, and list every script that loads. Then ask two questions: who authorised each of these, and who would know if one changed tonight. If you cannot answer both, you have found your first gap, and it is the same one that fails most assessments we see.