PCI DSS 4.0.1 payment-page script rules are being audited in earnest in 2026

By Daniel Wilson Kemp · Founder, Lifted Payments · July 26, 2026

If you take card payments through a web page, 2026 is the year the auditors start asking hard questions about the JavaScript on it. Requirements 6.4.3 and 11.6.1 of PCI DSS v4.0.1 — the rules that force merchants to inventory, authorize and integrity-check every script on a payment page, and to run tamper detection on that page at least weekly — have been technically mandatory since March 31, 2025. This year is the first full assessment cycle in which those controls are being evaluated by Qualified Security Assessors in earnest, rather than treated as future-dated.

The timing is not academic. On July 23, 2026, the PCI Security Standards Council published a document mapping PCI DSS v4.0.1 to the NIST Cybersecurity Framework 2.0 — a signal that the standard is settling into steady-state governance and cross-framework alignment rather than transition. Meanwhile the threat the client-side rules were written to stop is measurably worse. If you run an online store or embed a third-party checkout, here is what the rules require, what the recent SAQ A change means, and how keeping card data off your page shrinks the whole problem.

What the PCI SSC did on July 23, 2026

The PCI Security Standards Council published a resource on its PCI Perspectives blog titled "Mapping PCI DSS v4.0.1 to the NIST Cybersecurity Framework 2.0" (PCI SSC, July 23, 2026). The Council describes it as an update to work first published in 2019, developed by its Board of Advisors "as a tool to support organizations' security control management efforts" — a practical resource for aligning payment-security controls with a broader risk framework.

The mapping itself is guidance, not a new mandate — it does not add requirements. But it matters as a marker: v4.0.1 is now the operative version being cross-walked into broader risk frameworks, and the future-dated controls that dominated the v4.0 rollout are simply "the standard" now. For merchants, the practical consequence is that the client-side script rules are being assessed this cycle, not deferred.

What requirements 6.4.3 and 11.6.1 actually require

These two controls target the browser layer — the code that runs on the shopper's device while they type a card number — because that is where perimeter defenses and server-side scanning cannot see. Both have been mandatory since March 31, 2025 (c/side, July 2026).

6.4.3 — script inventory, authorization and integrity

Requirement 6.4.3 imposes three obligations for every script that loads on a payment page. The scope is broad: it covers your own first-party code, third-party SDKs, and the fourth-party scripts those vendors pull in at runtime.

• Authorization. A method must confirm each script is explicitly authorized before it loads or executes.
• Integrity. A method must assure the integrity of each script — that it has not been altered.
• Inventory and justification. You must keep an inventory of scripts with a written justification for why each one is necessary.

The gap this exposes is real. Security firm Feroot reports that merchants typically discover 30 to 60 scripts running on their payment pages but "can only document authorization for a fraction of them" (Feroot, October 2, 2025). An analytics tag, a chat widget, a tag manager that injects other tags — each is a script you now have to name and justify.

11.6.1 — change and tamper detection

Requirement 11.6.1 requires a detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and the content of payment pages as they are received by the consumer's browser. That mechanism must evaluate the received headers and page content at a frequency set by a targeted risk analysis, or at least once every seven days (c/side, July 2026).

Weekly is the floor, not the goal. As c/side notes, "a tamper that appears after one scan and is cleaned before the next leaves no trace" (c/side, July 2026) — which is exactly how a skimmer avoids detection. Continuous monitoring is the safer posture.

The threat driving the audit push

These rules exist because browser-layer card skimming — Magecart, e-skimming, "formjacking" — has been climbing fast. Recorded Future's 2024 Payment Fraud Intelligence Report (published early 2025) found that Magecart e-skimmer infections reached nearly 11,000 unique e-commerce domains in 2024, a threefold increase from 2023, and that 269 million card records were posted across dark and clear web platforms that year.

The evasion tooling is keeping pace with the defenses. c/side reports that "playwright-stealth" — browser automation tuned to suppress the signals that expose skimmers to scanners — was roughly ten times more widely used by the end of 2025 (c/side, July 2026). That is the core of the news hook: the client-side rules are being audited in earnest at the same moment the attacks they target are actively getting harder to catch.

The SAQ A change you need to read carefully

Here is the nuance that trips up small merchants. In early 2025 the PCI SSC refined SAQ A eligibility. Requirements 6.4.3 and 11.6.1 are not enumerated in the short SAQ A itself — they were removed from it, along with a related targeted risk analysis (Akamai, February 26, 2025). That sounds like relief, but it comes with a trade.

To use SAQ A now, a merchant must attest that their entire website is secure against attacks from malicious scripts — a broader obligation than the two line items it replaced. Merchants who cannot make that attestation fall to SAQ A-EP or SAQ D, and those questionnaires still carry 6.4.3 and 11.6.1 in full (Akamai, February 26, 2025). So the rules do not disappear for e-commerce; where they land depends on how your checkout is built.

• Fully outsourced checkout. A redirect or a payment iframe hosted entirely by your provider can support SAQ A — but you still attest the surrounding site is not susceptible to script attacks.
• Form on your own page. A self-hosted or direct-post form that touches card data on your page pushes you to SAQ A-EP or SAQ D, where 6.4.3 and 11.6.1 apply directly.
• Keyed / phone orders. A keyed virtual terminal is not SAQ A at all — it validates under SAQ C-VT. Do not let anyone label a virtual terminal "SAQ A."

What merchants must now be able to evidence

For an assessor or your acquirer, an intention is not evidence. If your checkout puts you into 6.4.3 and 11.6.1 territory, be ready to produce concrete artifacts, not descriptions.

• A living script inventory. Every script on the payment page, with owner, purpose and a written justification — refreshed, not a stale spreadsheet.
• An authorization method. Evidence that scripts are approved before they execute — for example a content security policy or subresource integrity, with change control around it.
• Tamper detection with alerts. A tool that watches page content and HTTP headers as the browser receives them and alerts on unauthorized change, run at least every seven days and logged.
• A completed, honest SAQ. The right questionnaire for how you actually accept cards, with the SAQ A script-attack attestation made only if it is true.

The real fix is shrinking scope, not just adding scanners

You can bolt monitoring onto a sprawling payment page — but the durable move is to reduce how much of the standard applies to you in the first place. The fewer places raw card data touches your systems, the fewer scripts fall under 6.4.3 and 11.6.1, and the simpler your attestation becomes.

That is the principle behind a tokenization-first approach. At Lifted Payments, card data is captured under E2EE tokenization (via Voltage), so the sensitive value is encrypted at the point of entry and is never stored in the clear on the merchant's side. For card-present acceptance that design supports a SAQ-A posture; you can read how the mechanics work in our guide to tokenization and SAQ-A compliance, and the same "keep the PAN off your surface" logic is what makes tap-to-pay defensible, as we cover in is tap to pay safe.

For online acceptance, the compliance question is largely an architecture question: does your integration keep card data inside your provider's hosted fields, or does it flow through your own page? That single choice decides whether you are filling out the short SAQ A or the long SAQ D, so it belongs at the top of any evaluation — see how to choose a payment gateway. If you take keyed or phone orders, route them through a dedicated virtual terminal (SAQ C-VT) rather than typing cards into a web form that then inherits the full client-side ruleset.

None of this replaces reading the standard or talking to your assessor. But the merchants who will find 2026 assessments painless are the ones who stopped touching card data they did not need to — and got an honest read on how they actually accept payments. If you want that read, our merchant services team will review one recent statement and quote interchange-plus with no application fee, and can walk through how your acceptance channels map to the current SAQs.

Sources

1. PCI SSC — Mapping PCI DSS v4.0.1 to the NIST Cybersecurity Framework 2.0 — PCI Perspectives blog, July 23, 2026 — the news hook; guidance mapping developed by the PCI SSC Board of Advisors; an update to 2019 work; adds no new requirements.
2. Akamai — PCI DSS v4.0.1 changes and how they affect SAQ A — February 26, 2025 — 6.4.3/11.6.1 removed from SAQ A but a new whole-site malicious-script attestation required; SAQ A-EP and SAQ D retain the rules.
3. c/side — PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 client-side compliance guide — Published July 14, 2026 (modified July 20, 2026) — mandatory since March 31, 2025; script inventory/authorization/integrity; weekly-minimum tamper detection; playwright-stealth ~10x more used by end of 2025.
4. Feroot — PCI compliance checklist for CISOs — October 2, 2025 — organizations typically find 30 to 60 scripts on payment pages but can document authorization for only a fraction.
5. Recorded Future — Annual Payment Fraud Intelligence Report: 2024 — Published early 2025 (asset cta-2025-0121) — nearly 11,000 e-commerce domains hit by Magecart e-skimmers in 2024, a threefold increase from 2023; 269 million card records posted on dark and clear web platforms.