PCI DSS v4 · Requirements 6.4.3 & 11.6.1

Your checkout page has to account for every script it runs.

Since 31 March 2025, PCI DSS v4 requires you to authorize, inventory, and integrity-check every script on a payment page — and to alert when one changes. These stopped being best practice and started being assessed. Here is what each requirement actually asks for, and which evidence answers it.

Payment Page Playbook Talk to Us
The Short Version

Authorize · Inventory · Assure · Alert

6.4.3 governs what runs on the page. 11.6.1 governs noticing when it changes. You need both, and you need them evidenced.

6.4.3Authorized scripts, assured integrity, inventory with written justification.
11.6.1Tamper/change detection with alerting, evaluated weekly or per risk analysis.
SAQ A tooOutsourced checkout does not automatically remove these from scope.
Why These Two Exist

Magecart moved the threat into the browser

Card skimming stopped being a server problem years ago. A single compromised analytics tag, a hijacked CDN, or an injected line of JavaScript reads the card field directly out of the DOM and posts it somewhere else — while your server logs stay perfectly clean and your TLS certificate stays perfectly valid. 6.4.3 and 11.6.1 exist because the payment page as received by the consumer browser is the only place that attack is visible.

The server never sees it

A skimmer exfiltrates straight from the browser to an attacker endpoint. Nothing traverses your backend, so nothing in your server logs, WAF, or database tells you it happened.

The blast radius is your vendors

Your checkout loads chat widgets, analytics, tag managers, A/B tools. Each one can inject further scripts at runtime. Their compromise becomes your breach and your assessment finding.

Detection has to be client-side

11.6.1 says “as received by the consumer browser” deliberately. Checking what your origin serves misses anything injected downstream — which is exactly how these attacks work.

Requirement 6.4.3

Manage every script the payment page executes

6.4.3 breaks into three obligations. Assessors look for all three, separately, with evidence for each.

1. Confirm each script is authorized

Someone accountable has to have approved every script on the page. In practice this means a maintained allowlist and a change process — not a screenshot of the network tab taken once a year.

2. Assure the integrity of each script

You must be able to show that the script executing is the script you approved. Hashes of released artifacts, a signed manifest, and a per-build marker inside the file itself are how you demonstrate that.

3. Maintain an inventory with justification

Every script needs a written business or technical reason to exist. This is the control that quietly removes the forgotten marketing tag nobody can explain — which is usually the one that gets compromised.

Requirement 11.6.1

Notice when the page changes

A change- and tamper-detection mechanism must alert your people to unauthorized modification of the payment page’s contents and its HTTP headers, as the consumer’s browser receives them. It must run at least weekly, or on a cadence justified by a targeted risk analysis.

  • Headers count too. A weakened CSP or a changed Content-Security-Policy is in scope, not just the body.
  • Alerting, not just logging. The requirement says alert personnel. A dashboard nobody watches is not a control.
  • Weekly is the floor. Skimmers often live for days. Most teams that take this seriously evaluate continuously, per page load.
  • Evidence matters. Your assessor will ask what fired, who saw it, and what happened next.
Evidence a build should be able to produce
# every released file, hashed and signed
dist/checkout.js    sha256:9f2a...  watermark:rel-8841
dist/vendor.js      sha256:41cd...  watermark:rel-8841
manifest.json.sig   ed25519 verified OK

# runtime: tamper signal -> your SIEM
{ "event":"integrity.violation",
  "release":"rel-8841",
  "page":"/checkout",
  "ts":"2026-07-17T09:14:03Z" }
Mapping

Which control answers which requirement

To be explicit: obfuscation is not named anywhere in 6.4.3 or 11.6.1, and no product makes you compliant. What a protection toolchain can do is emit the artifacts your assessor asks to see. Here is the honest mapping.

Inventory → 6.4.3 (3)

A third-party script inventory captured in the browser — what loaded, from where, with what hash — is the raw material for the written inventory. See managed web integrity for versioned policies and evidence export.

Watermark + signed manifest → 6.4.3 (2)

Per-build HMAC watermarks and an Ed25519-signed manifest of SHA-256 hashes let you prove the served file is the released file. Background: supply-chain integrity.

Beacon + SIEM → 11.6.1

Runtime defense detects tampering in the browser and forwards violations to Splunk, Elasticsearch, or a webhook — turning detection into the alert the requirement asks for.

Generate the evidence report
npx jso-protector compliance pci-dss-v4 \
  --manifest dist/build.manifest.json.sig \
  --root dist \
  --watermark-key $JSO_WATERMARK_KEY \
  --beacon-url https://beacon.example/ingest \
  --siem splunk-hec \
  --script-inventory inventory.json \
  --output pci-evidence.md

# exit 0 = evidenced
# exit 2 = partial (gaps listed in report)
The Reporter

Your build already knows most of the answers

The evidence for 6.4.3 and 11.6.1 is mostly a by-product of a protected build — hashes, signatures, watermarks, beacon wiring. The reporter reads those artifacts and writes the mapping so you are not assembling it by hand the week before an assessment.

  • Verifies the signed manifest first. An unsigned manifest fails closed unless you pass --allow-unsigned, which downgrades the report to partial.
  • Re-hashes files on disk with --root and compares against the manifest — a tampered file surfaces as a 6.4.3.b failure, not a footnote.
  • Validates watermark signatures when given --watermark-key; without the key it can only report presence, and says so.
  • Reports per sub-control — 6.4.3.a/b/c and 11.6.1.a/b/c are scored separately, because assessors ask about them separately.
  • Names what it cannot evidence. The control set carries an explicit out-of-scope list for the parts you own, rather than implying full coverage.
Straight Answers

What we will not claim

“This product makes you PCI compliant”

It does not, and neither does anyone else’s. Compliance is assessed against your whole cardholder data environment by a QSA or ISA. Tools supply controls and evidence; people and process supply the rest.

“Obfuscation satisfies 6.4.3”

It does not. Obfuscation raises the cost of understanding and tampering with your checkout logic — genuinely useful, and unrelated to the authorization, inventory, and integrity obligations the requirement lists.

“SRI ticks the integrity box”

Partly, for URL-loaded scripts. It cannot see inline scripts or anything injected at runtime by a tag you already trust — which is the Magecart pattern. Use it, do not rely on it alone.

“SAQ A means you are out of scope”

Not since v4.0.1. Merchants who fully outsource checkout still carry payment-page script obligations. Confirm your scope with your assessor rather than with a vendor blog post.

Next Step

Start with the inventory you cannot produce today

Open your checkout page, list every script that executes, and write one sentence justifying each. The ones you cannot justify are your first finding — and the fastest risk you can retire this week. The payment page playbook walks through the protection split, inventory, and alerting wiring.

Payment Page Playbook › See the Evidence Model