PCI DSS 6.4.3 and 11.6.1 explained: what your payment pages must do in 2026

Since April 1, 2025, every PCI DSS v4.x assessment includes two requirements that did not exist in v3.2.1: 6.4.3 (payment page script management) and 11.6.1 (tamper detection on payment pages). They were written for one threat: Magecart-style skimming, where a single compromised third-party script silently exfiltrates card data from your checkout.

This article explains what the requirements actually say, the SAQ A subtlety most merchants miss, and the practical ways to comply.

What requirement 6.4.3 requires

All scripts that are loaded and executed in the consumer’s browser on payment pages must be managed as follows:

• a method to confirm that each script is authorized.
• a method to assure the integrity of each script.
• an inventory of all scripts, with a written business justification for each one.

Three verbs matter: authorize, assure integrity, inventory. A spreadsheet updated once a quarter fails all three the day a tag manager injects something new. One more scope detail people miss: “payment page” includes the parent page embedding a payment iframe, so the iframe alone does not bound your obligations.

What requirement 11.6.1 requires

A change- and tamper-detection mechanism must be deployed that:

• alerts personnel to unauthorized modifications (changes, additions, deletions, indicators of compromise) to the HTTP headers and the contents of payment pages as received by the consumer browser.
• is configured to evaluate the received HTTP headers and payment page.
• runs at least once every seven days, or at the frequency set by your targeted risk analysis (12.3.1).

The key phrase is “as received by the consumer browser.” Server-side file integrity monitoring does not satisfy it, because a skimmer injected by a compromised CDN never touches your servers. You have to observe what browsers actually execute.

The SAQ A trap

In early 2025 the PCI Council removed 6.4.3, 11.6.1 and 12.3.1 as line items from SAQ A (iframe/redirect merchants). At the same time it added an eligibility criterion: the merchant must confirm that all payment page elements delivered to the browser originate only from PCI-compliant processors, and that “the site is not susceptible to attacks from scripts” affecting the e-commerce system.

The requirements didn’t disappear. They moved into the eligibility gate. If a script on your checkout parent page can tamper with the payment iframe, you can’t truthfully tick the box. Most SAQ A merchants therefore still need script and header monitoring. The evidence just takes a different form.

Three ways to comply

The first route is an enterprise client-side security agent (Source Defense, Jscrambler, HUMAN Security, c/side). A JavaScript agent watches or sandboxes every script in the visitor’s browser. This gives you the strongest behavioral detection, but look at the price of admission: you are adding a vendor’s script to the very payment page these requirements exist to protect, a new supply-chain exposure your assessor will want to discuss. Pricing is enterprise sales-led and often per-page-view, so the bill scales with your traffic rather than your risk, and deployment involves your front-end teams.

The second is to do it yourself. Build a script allowlist, add Subresource Integrity hashes, run weekly synthetic browser checks, keep the inventory in a document. Feasible on paper. In practice the inventory goes stale silently the first time a tag manager pushes something nobody logged, integrity checks miss dynamically-loaded scripts, and assembling audit evidence becomes a recurring manual project someone has to own.

The third is browser-sourced monitoring via CSP. The Content-Security-Policy header already makes every visitor’s browser report which scripts load on your payment pages. CentralCSP uses that signal (one HTTP header, no agent on the page) to maintain a live script inventory with integrity hashes (SHA-256/384/512) on every plan, and, in the PCI DSS module on Scale (€349.99/month), the rest of what the two requirements ask for: you declare your payment pages, each script on them gets an authorization and a written business or technical justification with auto-validation rules for routine hash rotations and known-CVE matching from the Technologies view (6.4.3), and a dated change timeline records every script added, changed or removed, with an alert the moment something appears without a justification and evidence exports as CSV, PDF and SBOM (11.6.1). Rules evaluate on ingest, well past the seven-day minimum, and the justifications and change ledger are kept until the account is deleted, not for the 90 days raw reports live. For most merchants this is the route we recommend: both requirements covered from one header, no new script on the payment page, no enterprise sales cycle to sit through.

QSA acceptance of CSP-based approaches for 11.6.1 varies, so the evidence package matters as much as the mechanism: a living inventory, justifications, hashes, and a change log you can export beat a verbal explanation of how the header works. That is precisely what CentralCSP’s evidence exports contain, which turns the varying-QSA question into a documentation exercise you have already done rather than an argument about mechanisms. What goes in that package, page by page, is in proving your payment scripts haven’t changed.

Where to start

Run a payment page through the free CSP scanner before anything else. It takes a minute, needs no account, and its security score tells you whether you are starting from a missing header or from a policy that only needs tightening (it grades the policy, it does not score PCI compliance, and that distinction is worth understanding before the assessment).

1. List your payment pages, including pages that embed payment iframes.
2. Deploy a report-only CSP header on them. Nothing can break in report-only mode.
3. Let real traffic populate the script inventory for a week or two.
4. Review, authorize and justify each script, and remove what nobody can justify.
5. Declare those pages as payment pages in the PCI module, turn on the unjustified-script alert, and export your first evidence pack before the auditor asks.

The teams that struggle with 6.4.3 and 11.6.1 are the ones treating them as a yearly documentation exercise. The browser will happily tell you what’s running on your checkout, every day, for every visitor. You just have to listen to it, and CentralCSP is the shortest way to do that listening: one header for the inventory, the PCI module on Scale for the justifications, the change ledger and the alerts, with the evidence export ready before the assessment starts.