What does PCI DSS 6.4.3 require for payment-page scripts?

PCI DSS 6.4.3 requires every script loaded and executed in the consumer's browser on a payment page to be authorized, integrity-assured, and listed in an inventory with a written business or technical justification. Paired with 11.6.1, which mandates weekly change-and-tamper detection, these have been enforceable since March 31, 2025.

PCI DSS 6.4.3: Payment-Page Scripts as a Change-Control Problem

Q: When did PCI DSS 6.4.3 and 11.6.1 become mandatory?

Both requirements have been in full effect since March 31, 2025, when the future-dated requirements of PCI DSS v4.0.1 stopped being best practice and became enforceable.

Q: Does 6.4.3 apply if I use a hosted payment iframe?

Yes. The requirement covers scripts on any page that includes an embedded payment page or form. The scripts on the surrounding page remain in scope even when the payment fields themselves live in a third-party iframe.

Q: How often must the tamper-detection mechanism run?

At least weekly, or at a frequency justified by a targeted risk analysis under Requirement 12.3.1. PCI SSC guidance recommends more frequent or real-time monitoring where feasible because malicious changes can persist between weekly checks.

Q: Is a Content Security Policy enough to comply?

No. A CSP helps limit which origins can load scripts, but it does not maintain an inventory, assure the integrity of each script's contents, or provide the weekly change-and-tamper detection that 11.6.1 requires.

Q: Why is this a change-management issue and not just security?

Every script addition or modification is a change to the page the customer's browser renders. Compliance requires proving each change was authorized and detecting changes that were not, which is exactly what a change process produces.

This article covers compliance operations, not legal advice. Confirm scope and control selection with your QSA. No affiliate links appear in this post.

Most teams read requirements 6.4.3 and 11.6.1 as a security-tool purchase. They are actually a change-control problem. A payment page picks up a new third-party script the moment marketing adds a tag, a vendor updates a library, or an attacker injects a skimmer. Each of those is a change to the page a customer’s browser renders. If your change process does not see script additions, your compliance evidence has a hole no dashboard closes.

PCI DSS 6.4.3 requires that every script loaded and executed in the consumer’s browser on a payment page be authorized, integrity-assured, and inventoried with justification. Requirement 11.6.1 requires a change-and-tamper detection mechanism that alerts personnel to unauthorized modification. Both have been in full effect since March 31, 2025, per the PCI Security Standards Council. They are no longer future-dated.

Why this matters

The two requirements exist because of e-skimming. Attackers inject or modify JavaScript on checkout pages to steal card data as a customer types it, a technique the PCI SSC’s payment-page security supplement describes as a persistent threat to e-commerce. The malicious code often lives in a third-party or fourth-party script the merchant never audited.

That is why this is a change-management story. The controls do not ask you to trust your scripts once. They ask you to detect when the set of scripts changes and to prove each change was authorized. A team that already runs a change process for infrastructure but treats front-end deploys as “just marketing” will fail both requirements on the same audit.

What 6.4.3 actually says

The requirement text is specific. Per the PCI DSS v4.0.1 standard, all payment-page scripts that are loaded and executed in the consumer’s browser must be managed so that:

a method is implemented to confirm that each script is authorized;
a method is implemented to assure the integrity of each script;
an inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

Three verbs matter: authorize, assure integrity, inventory. The standard applies this to scripts loaded from your own environment, from third parties, and from fourth parties, including pages that embed a payment processor’s iframe. The scope is the full set of scripts the browser executes, not just the ones your own repo commits.

The justification clause is the one teams skip. It is not enough to list a script. The inventory must record why the script is necessary. That single field turns the inventory into a change-review artifact: a new script with no justification is an unauthorized change by definition.

What 11.6.1 adds

Requirement 6.4.3 governs the scripts you know about. Requirement 11.6.1 catches the ones you do not. The standard requires a change-and-tamper detection mechanism deployed to alert personnel to unauthorized modification, including indicators of compromise, changes, additions, and deletions, to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.

The frequency is the number to write down. The mechanism functions must be performed at least weekly, or periodically at a frequency set by a targeted risk analysis under Requirement 12.3.1. The PCI SSC guidance for 6.4.3 and 11.6.1 recommends more frequent or real-time monitoring where feasible, because a malicious modification can persist undetected between weekly evaluations. Weekly is the floor, not the target.

The phrase “as received by the consumer browser” is the trap. Server-side file-integrity monitoring does not satisfy 11.6.1. The mechanism has to evaluate what the browser actually renders, because a skimmer can be injected downstream of your origin server through a compromised third-party dependency.

No single control covers everything

Teams reach for one technique and assume it closes both requirements. It does not. The table below maps the common approaches to the specific obligations, based on the requirement text and PCI SSC guidance.

Matrix showing how CSP, Subresource Integrity, tamper-detection agents, and manual review map to each PCI DSS 6.4.3 and 11.6.1 obligation

A Content Security Policy allow-list limits which origins can load scripts, which helps with authorization, but it does not inventory scripts, does not assure the integrity of a script’s contents, and does not alert you when an allowed origin serves changed code. Subresource Integrity hashes a specific script and blocks it if the file changes, which is strong for integrity, but SRI does nothing for inventory, authorization workflow, or the weekly detection obligation, and it breaks on scripts that legitimately update often. A tamper-detection agent or service covers the detection and alerting obligations well but still needs a documented authorization and justification process behind it. Manual review plus a CMDB gives you the inventory and justification but cannot meet the weekly browser-side detection requirement by hand.

The practical answer is a layered set: an inventory and authorization workflow for 6.4.3, plus an automated browser-side detection mechanism for 11.6.1, glued together by your change process.

Where change management fits

This is the part a GRC tool does not solve. The requirements assume an authorization decision exists to point at. Vendor tooling reflects the same shape: per Imperva’s compliance guidance, an authorization workflow should let security teams approve or block scripts with justification and documentation for audit, and generate an alert when a new or modified script appears so it can be reviewed promptly. That is a change-control statement: an alert on a script change is a change request that needs a normal-change or post-hoc-approval path, exactly the structure a change advisory board already runs for other assets.

Fold payment-page scripts into the process you have. A front-end deploy that adds or modifies a script becomes a change record. The record carries the business justification the inventory needs. The detection mechanism becomes the verification step that confirms production matches what was authorized. When the two disagree, you have an unauthorized change and an incident trigger in one signal. Teams that already document SOX change control mapped to ITSM can extend the same evidence trail here.

The scoping surprise for smaller merchants: the requirements reach e-commerce merchants who previously self-assessed with minimal validation. Per SecurityMetrics, even merchants who outsource payment pages must account for third-party scripts on any page that touches the payment process. Embedding a processor’s iframe does not remove the obligation for the surrounding page’s scripts.

The scope reaches further than most inventories do. The PCI DSS standard explicitly names scripts loaded from fourth parties, meaning a script your third-party vendor pulls in from someone else. A tag manager you approved can load an analytics library that loads an ad pixel that loads a script you never reviewed. Each hop is a change to what the browser executes, and each hop is in scope.

Static counting misses this. Per SecurityMetrics, attackers can inject content dynamically even when only a small number of scripts appear in the static page, so you have to capture everything loaded during an actual payment transaction, not the source you committed. That is why 11.6.1 evaluates the page as received by the browser: it is the only vantage point that sees the fourth-party chain resolve.

The evidence your assessor samples

Both requirements are validated by artifacts, not intentions. For 6.4.3, an assessor examines the script inventory and confirms each entry carries an authorization method and a written justification. For 11.6.1, the standard’s testing procedures have the assessor examine system settings and monitoring results to verify the detection mechanism runs, and, if you chose a non-weekly frequency, examine the targeted risk analysis that justifies it. A change process generates all three as a byproduct: the change record is the authorization, the inventory entry is the justification, and the detection log is the monitoring evidence.

What to do about it

Enumerate every script on every page in the payment flow, including tag-manager injections and third-party dependencies, and capture what loads during an actual transaction, not just the static HTML.
Add a justification field to each entry and delete or block any script no one can justify. An unjustified script is the fastest audit finding to fix and the cheapest attack surface to remove.
Route script additions and changes through your existing change process so every entry has an authorization record, and define the post-hoc approval path for changes that cannot be pre-authorized.
Deploy a browser-side change-and-tamper detection mechanism that evaluates rendered headers and scripts at least weekly, and document a targeted risk analysis if you choose any frequency other than weekly.
Wire detection alerts into incident response so an unexpected script change opens a ticket, not just a dashboard entry, and score the exposure with a change-risk assessment before it ships.
Keep the inventory, authorization records, and detection logs together as the evidence package your assessor will sample, alongside your other compliance-mapped change controls.

Frequently asked questions

When did PCI DSS 6.4.3 and 11.6.1 become mandatory? Both have been in full effect since March 31, 2025, when the v4.0.1 future-dated requirements became enforceable.

Does 6.4.3 apply if I use a hosted payment iframe? Yes. Scripts on any page that embeds a payment form remain in scope, even when the card fields live in a third-party iframe.

How often must the tamper-detection mechanism run? At least weekly, or at a targeted-risk-analysis frequency. PCI SSC recommends more frequent or real-time checks where feasible.

Is a Content Security Policy enough to comply? No. A CSP helps with origin control but does not inventory scripts, assure each script’s integrity, or meet the 11.6.1 weekly detection obligation.

Why is this a change-management issue and not just security? Because every script change alters what the browser renders, and compliance means proving each change was authorized and catching the ones that were not.

For more on building audit-ready change evidence, see our compliance pillar and the guide to a compensating-controls register auditors accept.

Sources

#pci-dss #payment-page-security #change-control #e-skimming #compliance

Published September 14, 2026.