PCI DSS 4.0.1 in Force: The Requirements That Quietly Became Mandatory and What They Cost Engineering

The PCI DSS 4.0 requirements that everyone filed under “later” stopped being future-dated on 31 March 2025. They are now baseline, and most of them are engineering problems, not paperwork the QSA can wave through.

For two years the standard let firms treat a specific set of new controls as best practice — present in the document, marked as not yet mandatory, quietly deprioritised in favour of whatever had a hard deadline. That grace window closed. Since 31 March 2025 those controls are simply part of PCI DSS, and an assessor tests them as baseline. The awkward part is where they land. Client-side script controls, targeted risk analyses and the expanded multi-factor rules do not belong to your compliance function. They belong to the people who own the payment page, the identity layer and the change process. “We planned to get to those” is no longer an answer anyone will accept.

Which version you are actually being assessed against

A point of confusion worth clearing first. PCI DSS v4.0 was published in March 2022. A limited revision, v4.0.1, was published on 11 June 2024, and v4.0 was retired on 31 December 2024 — so v4.0.1 is now the only active version. The revision corrected errata and clarified wording; it did not move the effective date of the future-dated requirements, which remained 31 March 2025. If your last self-assessment still leans on the transition language, it describes a state of the world that no longer exists. None of these controls carry a “best practice until” footnote any more.

The payment page is now in scope in a way it was not

The two requirements catching firms out hardest are 6.4.3 and 11.6.1, and they are a pair. Requirement 6.4.3 says you must manage every script that loads on a payment page: confirm each script is authorised, assure its integrity, and keep an inventory that records what each one is and why it needs to be there. Requirement 11.6.1 says you must run a mechanism that alerts personnel to unauthorised modification of the HTTP headers and the payment-page content as received in the consumer’s browser, evaluated at a frequency your risk analysis justifies and at least every seven days.

Read those together and the intent is obvious: they are aimed at digital skimming — the Magecart-style attacks that inject or tamper with JavaScript to lift card data from the browser before it ever reaches your server. That is why the phrase “as received in the consumer’s browser” matters so much. A scan of your origin server proves nothing about what a third-party tag manager, an analytics SDK or a compromised fourth-party dependency injected at runtime on the customer’s machine. The control is asking about the delivered page, after every redirect and every dynamically loaded script.

For most engineering teams this is genuinely new work. You need an authoritative inventory of every script on the payment flow, including the ones marketing added through a tag manager without telling anyone. You need an integrity method that survives legitimate updates — static Subresource Integrity hashes break the moment a vendor ships a new build, so a pure SRI approach tends to generate either false alarms or silent gaps. And you need monitoring of the real delivered page, not a synthetic check against your own repository. This is the same pattern as turning class cyber rules into buildable deliverables that we describe in turning class cyber requirements into newbuild engineering deliverables: the words in the standard are short; the implementation is a real system someone has to own.

A concrete baseline for the script controls

A Content-Security-Policy that allowlists script sources, combined with per-script integrity and a reporting endpoint, is the defensible starting point for 6.4.3 and feeds the monitoring that 11.6.1 demands. It is not the whole answer — CSP alone does not satisfy the inventory-and-justification obligation, and it does not replace browser-side change detection — but it is the layer an assessor will expect to see configured and enforced rather than merely reported on.

# Response headers for the payment page (nginx). Enforce, do not report-only.
# Allowlist every script origin; block everything you have not justified.
# CSP violation reports feed the 11.6.1 change-and-tamper evidence trail.

add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://js.your-psp.example 'sha256-Base64HashOfInlineBootstrap=';
  connect-src 'self' https://api.your-psp.example;
  frame-src https://js.your-psp.example;
  object-src 'none';
  base-uri 'self';
  report-uri /csp-report;
" always;

# Report-To gives a structured channel for the violation feed (British spelling in prose;
# the directive name itself is fixed by the standard).
add_header Report-To '{"group":"csp","max_age":10886400,"endpoints":[{"url":"/csp-report"}]}' always;

The integrity attribute belongs on the tags themselves, and the point to internalise is that it needs a process behind it, not a one-off:

<!-- Subresource Integrity pins a known-good build. It WILL break on a
     legitimate vendor update, which is the feature, not the bug: the break
     is your signal to re-verify and re-hash under change control. -->
<script src="https://js.your-psp.example/checkout.js"
        integrity="sha384-Base64HashOfTheApprovedBuild"
        crossorigin="anonymous"></script>

Treat this as the floor. The 11.6.1 obligation to detect tampering in the delivered browser page still needs a monitoring capability on top — whether you build it or buy it is a real decision, but pretending the CSP header alone closes the requirement is how firms fail the retest.

Targeted risk analysis is now a maintained artefact

Several 4.0 requirements no longer prescribe a fixed frequency — they let you set the interval, provided you justify it. Requirement 12.3.1 is the mechanism for that: a targeted risk analysis for each activity where you define the cadence, documenting the assets, the threats, the factors you weighed and the resulting frequency, reviewed at least annually. Requirement 12.3.2 attaches a similar analysis to anything you implement through the customised approach. This is not a form you fill in once. It is a living document an assessor will ask to see, dated, owned and revisited. Where you set an interval — how often you scan the delivered payment page, how often you review access — the risk analysis is the evidence that the number was a decision rather than a guess. Reporting quietly becoming a maintained data obligation is a pattern we have written about before in the context of the statutory gambling levy turning reporting into a data obligation; the shape is identical here.

MFA stopped being an admin control

The authentication changes are the ones teams most often think they already meet and do not. Requirement 8.4.2 extends multi-factor authentication to all access into the cardholder data environment — not just remote access, not just administrators, but every user and every access path, including from inside your own network. Requirement 8.5.1 then sets conditions on the MFA system itself: it must resist replay, it must not be bypassable (the convenient “remember this device” exception is out), it must use at least two different factor types, and access is denied unless every factor succeeds. A VPN with MFA at the perimeter and a flat CDE behind it does not satisfy this. If a user can reach cardholder systems from a trusted subnet without a second factor, you have a finding.

None of this is exotic. It is a segmentation and identity project with a compliance deadline attached, and the deadline is already behind you.

What to check before the next assessment window

The failure mode is not ignorance of the standard. It is a team that read the future-dated list in 2023, agreed it mattered, then let it sit behind nearer deadlines until this one arrived unremarked. So the questions are narrow. Can you produce the script inventory for your payment page today, with a justification per script? Can you show the mechanism that would alert you to a tampered header in a real customer’s browser, and when it last ran? Can you show a dated targeted risk analysis behind every interval you set yourself, and MFA on every path into the CDE, including the internal ones? If any answer is a hesitation, the gap is not on your assessor’s side of the table. It is on yours, and the standard already assumes you closed it.