The Shift
What PCI DSS 4.0 requires on your payment pages
For most of its history, PCI DSS protected card data on the server and in transit, but treated the browser as out of scope. PCI DSS 4.0 changed that. Two new requirements — 6.4.3 and 11.6.1 — put client-side security on the compliance agenda for the first time, and they were written with one threat in mind: Magecart.
Magecart is the umbrella term for the criminal groups that inject malicious JavaScript — a digital skimmer — into payment pages to read card details directly from the form as they are entered. Because the skimmer runs in the customer's browser, server-side controls never see it. The breaches at British Airways and Ticketmaster are the best-known examples. How Magecart attacks work →
The future-dated requirements of PCI DSS 4.0, including 6.4.3 and 11.6.1, became mandatory on 31 March 2025.
The Requirement
Requirement 6.4.3 explained
Requirement 6.4.3 applies to every script loaded and executed on a payment page, and it sets out three obligations.
Authorise
Confirm each script is allowed
A method must be in place to confirm that every script executing on the page is authorised to run. A Content Security Policy is the browser-native way to do this.
Assure integrity
Detect unauthorised change
Each script's integrity must be assured so that tampering is detected. Subresource Integrity pins a script to a known-good version and blocks it if the file changes.
Inventory
Justify every script
A written inventory of every script must be kept, each with a business or technical justification for why it is necessary. The fewer scripts you run, the smaller the attack surface.
These map onto two browser standards that predate PCI DSS 4.0 by years: Content Security Policy for authorisation, and Subresource Integrity for integrity. The inventory is where policy meets housekeeping — you need a living record of what runs, why, and proof it is still exactly what you authorised. See how Script Watch inventories your scripts →
Ready to implement? Follow our step-by-step 6.4.3 implementation guide →
The Requirement
Requirement 11.6.1 explained
Requirement 6.4.3 gets your payment page into a known-good state. Requirement 11.6.1 keeps it there. It calls for a mechanism that detects unauthorised modification of the security-impacting HTTP headers and the script content of payment pages, and alerts on change — continuously, as the page is received by the consumer's browser.
This is a detective control, and it is where real-time reporting becomes essential. A CSP configured with a reporting endpoint turns every policy violation into an alert: the moment an unauthorised script attempts to load, or an authorised one is tampered with, a report is generated from the real browser session. See how Policy Watch detects CSP drift →
Ready to implement? Follow our step-by-step 11.6.1 implementation guide →
Not quarterly. Not on a schedule. Continuously — because that is how fast a skimmer appears.
Eligibility
SAQ A, A-EP and D: which applies to you
The Self-Assessment Questionnaire is how eligible merchants attest to compliance. Even merchants who embed a payment provider's page in an iframe — and never directly touch card data — still control the parent page hosting it, which is why client-side security reached even the lightest-touch merchants.
SAQ A
An eligibility condition, not a question
6.4.3 and 11.6.1 are not asked in SAQ A. Instead you must confirm the site is not susceptible to script attacks before you may use SAQ A at all.
SAQ A-EP
Assessed directly
Merchants whose own page can affect the security of the payment transaction answer 6.4.3 and 11.6.1 as questions, in full, with evidence.
SAQ D
Assessed directly
The broadest questionnaire. 6.4.3 and 11.6.1 apply as written, alongside the rest of PCI DSS.
Requirements 6.4.3 and 11.6.1 were removed from SAQ A in early 2025, and the script-susceptibility condition took their place. PCI SSC FAQ 1588 sets out two ways to satisfy it: use techniques such as those described in 6.4.3 and 11.6.1 to protect the page from scripts targeting account data, deployed by you or by a third party; or obtain confirmation from the PCI DSS compliant provider of your embedded payment form that, implemented to their instructions, their solution protects that form from script attacks.
The second route covers the provider’s embedded form. It says nothing about the rest of the page you serve around it — the tags, analytics and personalisation your own team deploys — which is where a skimmer is placed.
The condition does not reach every merchant. FAQ 1588 states it does not apply where your page redirects the customer away to the provider (an HTTP 30x, a meta refresh or a JavaScript redirect), or where payment functions are fully outsourced. If the customer leaves your page before entering card details, the scripts on it fall outside this criterion.
The not-applicable route narrowed in August 2026. FAQ 1331 now states that SAQ eligibility criteria should not be used as a guide to which PCI DSS requirements apply in a Report on Compliance unless reviewed, discussed and agreed with the merchant’s compliance accepting entity — the payment brands and acquirers. A merchant and their assessor can no longer settle between themselves that 6.4.3 and 11.6.1 do not apply.
| Report URI covers |
Doesn't replace |
| Script inventory and change detection |
Penetration testing |
| CSP enforcement and violation logging |
Secure code review |
| Behavioural data exfiltration monitoring |
WAF or edge security |
| Audit-ready evidence generation |
Vulnerability remediation |
Compliance
The evidence auditors actually expect
The gap most organisations face isn't awareness of the requirements — it's the difference between having a control and being able to prove it worked. A script inventory in a spreadsheet satisfies the letter of 6.4.3 the moment you create it, but says nothing about what ran a week later. A CSP deployed without violation monitoring might be enforcing your policy, or silently failing.
PCI DSS 6.4.3 doesn't accept ‘we think we're compliant.’ A policy you can't prove is working isn't a control — it's a hope.
Report URI captures what actually happens in your users' browsers and turns it into structured, exportable evidence mapped directly to 6.4.3 and 11.6.1: a timestamped script inventory with authorisation status, change logs showing what was modified and when, and a record of CSP enforcement over time. Because everything works through the browser's native Reporting API, there is no agent to install and no traffic routed through a third party. See exactly how Report URI meets 6.4.3 and 11.6.1 →
Take it to your assessor: get the PCI DSS 6.4.3 & 11.6.1 evidence pack — a QSA-ready mapping of each requirement to the evidence you can export, available on this site and as a branded PDF download.
Cost
What staying non-compliant costs
Card brands assess a monthly penalty for as long as a merchant is out of compliance, and it escalates the longer it runs — no breach required.
If a skimmer does reach a payment page, what it costs is set by how long it runs before anyone notices. The data breach cost calculator puts a number on that, and on the probability at which continuous monitoring pays for itself.
Get Ready
A practical 6.4.3 & 11.6.1 readiness checklist
The technical approach is the same regardless of which SAQ you complete. Work through these steps — grouped by the requirement each one satisfies — to get a payment page into a defensible state.
Requirement 6.4.3 — authorise, assure integrity, inventory
Inventory every script on the payment page and remove anything without a written justification
Authorise the scripts that remain with a Content Security Policy scoped to the payment page
Pin third-party scripts to known-good versions with Subresource Integrity
Requirement 11.6.1 — detect and evidence change
Add a CSP reporting endpoint so every violation is captured from real browser sessions
Alert on any change to the deployed policy, security-impacting headers, or payment page scripts
Export the inventory, change logs and enforcement history as audit-ready evidence
Standards Body
Where this guidance comes from
Given how much of our work goes into helping organisations defend against client-side attacks like Magecart, joining the PCI Security Standards Council as an Associate Participating Organisation was a logical step. It gives us the ability to contribute directly to draft standards and supporting materials, so the reading of 6.4.3 and 11.6.1 on this page comes from inside the process that produces them rather than from an outside interpretation of the finished document.
By joining as an Associate Participating Organization, Report URI has the opportunity to play an active part in improving payment security globally by helping drive awareness and adoption of PCI Security Standards.
Lance Johnson, Executive Director, PCI Security Standards Council
The full announcement is in our joint press release with the PCI SSC.
FAQ
Frequently asked questions
Requirement 6.4.3 requires that every script on a payment page is authorised, has its integrity assured, and is inventoried with a written business or technical justification for why it is needed. It exists to prevent Magecart-style skimming attacks that steal card data in the browser.
Requirement 11.6.1 requires a mechanism that detects unauthorised changes to the security-impacting HTTP headers and the script contents of payment pages, and alerts on those changes continuously rather than on a periodic schedule.
Requirements 6.4.3 and 11.6.1 were removed from SAQ A in early 2025, but a new eligibility condition requires SAQ A merchants to confirm their site is not susceptible to script-based attacks. PCI SSC FAQ 1588 confirms that using the techniques described in 6.4.3 and 11.6.1 is the practical way to meet that condition.
A Content Security Policy lets the browser enforce which scripts are authorised to run and restricts where data can be sent. With a reporting endpoint it also produces a continuous record of what was blocked and allowed, which supports both the authorisation obligation of 6.4.3 and the change detection obligation of 11.6.1.
The future-dated requirements of PCI DSS 4.0, including 6.4.3 and 11.6.1, became mandatory on 31 March 2025.
Auditors expect a timestamped script inventory with authorisation status, change logs showing what was modified and when, and a record of CSP enforcement covering what was blocked and allowed over time. Report URI produces this as structured, exportable, audit-ready evidence.
Prove PCI DSS compliance on your payment pages.
One header. No infrastructure changes. Continuous, audit-ready evidence from day one.
