Card data used to be stolen from databases. For most of a decade it has been stolen from the browser instead: a few lines of JavaScript added to the page where the customer types the card number, reading the fields as they are filled and sending them elsewhere while the real payment goes through untouched. The server is clean. The logs are clean. The customer sees nothing. The acquirer sees a cluster of fraud six weeks later and traces it back.
PCI DSS v4 answered with two requirements, 6.4.3 and 11.6.1, which have been mandatory since the end of March 2025. They are short, they are precise, and they are routinely answered with the wrong evidence. Here is what each one asks, what satisfies it, and what has changed for the merchants who thought an iframe took them out of the discussion.
Requirement 6.4.3: know your scripts, authorise them, check their integrity
The requirement applies to every script loaded and executed in the consumer’s browser on a payment page, and it asks for three things. An inventory of those scripts, each with a written business or technical justification. A method to confirm that each script is authorised. A method to assure the integrity of each script.
The inventory is where most teams discover what their page has become. First-party code, the payment provider’s library, analytics, consent management, chat, A/B testing, the tag manager and everything the tag manager loads, which changes without a deployment. The inventory has to include the children, not just the tag manager, and someone has to be able to say why each one is on the page where the card is typed. “Marketing asked for it” is a reason to move it to another page, not a justification.
Authorisation is change control applied to the page as served: a script appears on the payment page only after someone approved it, and the list of approved sources is enforced somewhere, not just filed. A Content Security Policy in enforcing mode is the usual enforcement: the browser refuses to run anything from a source the policy does not name. A policy in report-only mode is a monitoring tool, not an authorisation control, and assessors will say so.
Integrity is the hard one. For a static third-party file, Subresource Integrity does it: the script tag carries the hash, the browser refuses a file that does not match. Most payment and analytics vendors serve files that change without notice and cannot carry a fixed hash, so for those the integrity method is a monitoring one, which brings us to 11.6.1, or a decision: the script does not belong on this page.
Requirement 11.6.1: detect the change, in the browser, and tell someone
The second requirement asks for a change- and tamper-detection mechanism on the payment page as the consumer’s browser receives it, covering the security-impacting HTTP headers and the contents of the scripts. It must alert personnel to unauthorised modification, including additions and deletions. It must run at least once every seven days, or at a frequency your targeted risk analysis justifies.
Read the phrase “as received by the consumer browser” twice. File-integrity monitoring on your web server watches files on disk. Skimmers are injected through compromised third parties, through tag managers, through a CDN, and through the server itself in ways that leave the files on disk alone. A mechanism that watches the server does not see the page the customer gets. This is the most common wrong answer we see in evidence folders.
The mechanisms that do answer it, each with a limit worth knowing:
- CSP violation reporting tells you when the browser blocked a script from an unlisted source. It does not tell you when an authorised script changed its contents. It covers additions, not tampering.
- Synthetic monitoring from outside fetches the page the way a browser would, on a schedule, and compares headers and script contents with the last known good state. It sees what a customer would see, from where the monitor runs. It does not see a skimmer that activates only for certain customers or regions, which is why the better services fetch from several places and vary their fingerprints.
- In-page agents run alongside your scripts in real customers’ browsers and report what executed. They see the most and add a script of their own to the page, which then belongs in the inventory.
- Hash comparison of the scripts your own servers deliver catches tampering on your side only.
Most environments need two of these. All of them need a person who receives the alert and a procedure that says what to do with it, because the requirement is the alert and the response, not the dashboard.
A mechanism that watches the server does not see the page the customer gets.
Who owes what
If your page contains the payment form, both requirements are yours in full.
If your page embeds the payment provider’s iframe or redirects to its hosted page, the provider owes both requirements for the content it serves, and you are responsible for the page around it: the parent page is yours, the scripts on it are yours, and a skimmer on the parent page can replace or overlay the iframe. The form being someone else’s does not make the page someone else’s.
If you are the provider, the merchant’s assessor will ask you for evidence that the iframe content and the scripts you ask merchants to include meet 6.4.3 and 11.6.1. Your Attestation of Compliance should say so without prompting.
SAQ A: what the written confirmation changes, and what it does not
The merchants using an iframe or a redirect validate with SAQ A, the shortest questionnaire, and this is where the standard has moved twice.
PCI DSS v4 first put 6.4.3 and 11.6.1 into SAQ A, which asked small merchants to run script inventories and tamper detection on a page they had mostly not written. The v4.0.1 revision of SAQ A took the two requirements out again and replaced them with an eligibility condition: the merchant has confirmed that its site is not susceptible to attacks from scripts that could affect the e-commerce system. The Council’s guidance then gave two ways to meet it. The merchant can apply the techniques of 6.4.3 and 11.6.1 to its own page. Or it can obtain written confirmation from the payment provider that the embedded form protects against script attacks when implemented according to the provider’s instructions.
Most merchants will take the letter, and that is allowed. Two things about it are worth saying plainly.
The letter changes which questionnaire you fill in. It does not change your attack surface. Three small shops we helped after the fact ran the same open-source platform with an iframe or a redirect to their provider, so each was legitimately SAQ A, and each was compromised anyway: stolen administrator credentials, a backdoored module, then skimmers on the pages the merchants owned. The providers suspended payments until they received a passing scan and a QSA-signed questionnaire. The letter would have been perfectly valid throughout. We tell that story in full in When your payment provider cuts you off.
The letter has a condition in it. “When implemented according to the provider’s instructions” means the provider’s integration guide is now part of your compliance evidence: the iframe loaded the way the guide says, no scripts of yours reaching into it, the provider’s library loaded from the provider’s source. An assessor reading the letter will ask to see the implementation next to the instructions. Keep both.
What people get wrong
They monitor the server. The requirement is about the page in the browser.
They run a report-only policy for a year and call it a control. Report-only observes; enforcing authorises.
They inventory the tag manager and not its children. The children are the scripts; the manager is how they got there.
They read “every seven days” as a weekly scan. The seven days are a ceiling, and the risk analysis that justifies a longer interval has to exist in writing.
They treat the iframe as a boundary. The iframe content is the provider’s. The page is yours, and it is the page that gets attacked.
They send alerts to a mailbox nobody reads. The mechanism is complete when a person acts on it.