The PCI Security Standards Council removed requirements 6.4.3 and 11.6.1 from SAQ A in January 2025. It did not remove them from PCI DSS. Lauren Holloway, the Council's Director of Data Security Standards, put it plainly two months later: they came out of the questionnaire, but "they are still in the standard."
If you take cards through an embedded payment form and file SAQ A, the script inventory and the tamper detection still bind your checkout page. There is no longer a line on your paperwork where you report them. That hole is the most consequential thing in v4.0.1 for anyone who writes code, and the pages ranking for "PCI DSS 4.0 for developers" do not mention it. They cover secure coding training. This covers what the standard forces into your CSP header, your build pipeline and your database.
What Changed in PCI DSS 4.0 for Developers
Version history first, because much of what is online is stale. v4.0 published in March 2022. v3.2.1 retired on 31 March 2024, and v4.0 itself retired that December, replaced by v4.0.1 (June 2024), a revision with "no additional or deleted requirements". Of the 64 new requirements in v4.0, 51 were future-dated and became mandatory on 31 March 2025. Not 1 April, which is the date several ranking pages print. The grace period is over.
There is no v5.0. Between 3 June and 20 July 2026 the Council ran a Request for Comments whose stated purpose was "to help determine whether to revise, and what type of revisions are needed for, PCI DSS v4.0.1". One question asks whether requirements need addressing "considering the impact of AI and mobile". That is the entire forward signal on the public record.
What Do Requirements 6.4.3 and 11.6.1 Actually Require?
6.4.3 governs every script loaded and executed in the consumer's browser on a payment page. Confirm each script is authorised, assure the integrity of each script, and keep an inventory "with written business or technical justification as to why each is necessary". Most summaries truncate that to "written justification" and drop the or technical, which matters when your only honest justification is that checkout breaks without the script. 11.6.1 is detection, not prevention. A change- and tamper-detection mechanism must alert on unauthorised modification to "the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser". Both. And "as received by the consumer browser" rules out checking your repo, your build artefact, or what your origin thinks it served. The Guidance column gives the reasoning in one line: "the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted." Cadence is at least weekly, or an interval you justify through a targeted risk analysis under 12.3.1.The standard names sub-resource integrity, CSP and tag-management systems as integrity examples, then adds that "the use of any one mechanism is not necessarily a full detection and reporting mechanism." Two limits follow that it leaves you to work out:
- SRI cannot cover a PSP loader. Stripe's security guide says its JavaScript "must be loaded directly from" Stripe's domain and tells you not to self-host it. You cannot pin an integrity hash to a file your processor rotates on its own schedule. SRI is for your static, version-pinned assets.
- CSP in report-only mode is not detection. CSP reports blocked loads. A script already on your allow-list that starts reading card fields generates no violation, because nothing was blocked. CSP checks origin, not behaviour.
Does a Stripe or Adyen iframe Remove the Script Requirements?
No. It splits them at the iframe boundary, and the Applicability Notes say exactly where the cut falls.
6.4.3 "applies to all scripts loaded from the entity's environment and scripts loaded from third and fourth parties". Fourth parties means the scripts your vendors' scripts pull in. It "also applies to scripts in the entity's webpage(s) that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frames or iframes)". It does not apply to scripts inside the processor's iframe. Those belong to the processor, and you are expected to obtain evidence they manage them, under Requirement 12.9.
So the parent page hosting Stripe Elements is squarely in scope. Your analytics tag, your session-replay script, the A/B testing snippet someone added last quarter: each sits on the page framing the card inputs, and each needs a justification line and an integrity mechanism.
The standard names the control for the frame itself, under Good Practice: restricting where the payment page may load from "using the parent page's Content Security Policy" helps prevent unauthorised content being substituted. Pin frame-src to your processor's origin. One directive, and the highest-value line of config here.
Why SAQ A Removed 6.4.3 and 11.6.1 in January 2025
Both were in SAQ A from v4.0 in 2022 as future-dated items. October 2024 added completion guidance for 6.4.3 and pulled in 12.3.1. Then January 2025 reversed course, and the Document Changes table in SAQ A r1 records it: the Council removed 6.4.3, 11.6.1 and 12.3.1, and added an eligibility criterion that the merchant confirm its site is "not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)".
FAQ 1588 gives two routes to satisfying that criterion: implement techniques "such as, but not limited to, those that are spelled out in PCI DSS Requirements 6.4.3 and 11.6.1", or obtain confirmation from your compliant processor that its embedded solution protects against script attacks when implemented per its instructions.
The trap is in the scoping, and it runs the opposite way to what most write-ups assume. FAQ 1588 applies the criterion only to merchants using an embedded payment page or form. Redirect merchants sit outside it, and the Council's March 2025 information supplement goes further: 6.4.3 and 11.6.1 "do not apply to merchants with webpages that redirect to a TPSP's page", whether by HTTP 30x, a meta redirect tag or a JavaScript redirect. One carve-out survives and is easy to miss. "Where scripts are used as part of a redirection mechanism", both requirements apply to those scripts.
The bind lands on embedded-form merchants instead. The same supplement states that embedding a third-party payment form "does not completely remove the merchant's embedding page (the parent page) from scope", nor does it make 6.4.3 and 11.6.1 inapplicable. File SAQ A with Stripe Elements on the page and those two requirements still reach your parent page, while the questionnaire offers no line on which to report them. The practitioner blog PCI Guru put that question in September 2026 and answered it honestly: it is for the acquirer to work out.
One further point the supplement makes and no integration guide does: in a single-page app the whole SPA "effectively behaves as one continuous 'page'", so 6.4.3 and 11.6.1 reach every view, not only the one rendering the card fields.
SAQ A r1 also still contains 8.3.6 (12-character passwords) and 11.3.2 (quarterly external ASV scans), and FAQ 1604, published June 2026, confirms ASV scanning applies to redirect and iframe merchants alike. Its scoping note explains why: those requirements attach to the page hosting the redirect or the embedded form, because that page affects how account data is transmitted even though it never receives any.
SAQ A vs SAQ A-EP vs SAQ D: Where the Line Falls
The dividing line is where the card input fields originate, and it is worth about a hundred extra sub-requirements.
| SAQ A (r1, Jan 2025) | SAQ A-EP | SAQ D (Merchant) | |
|---|---|---|---|
| Principal requirements | 7 of 12 (2, 3, 6, 8, 9, 11, 12) | all 12 | all 12 |
| Answerable questions | 27 | ~139 | effectively the full standard |
| Eligibility test | elements originate "only and directly from" a compliant processor | elements originate "either from the merchant's website or" a compliant processor | anything else |
| Customised approach | not available | not available | available |
| Typical integration | hosted fields, PSP iframe, full redirect | direct post, card form assembled by your page | you touch the PAN |
Stripe's published mapping follows that line exactly: Checkout and Elements are SAQ A because the inputs render from Stripe's domain, the old Stripe.js v2 pattern is SAQ A-EP because card data is "entered in a form hosted on your own site", and direct API is SAQ D.
The engineering reading: moving card inputs into a processor-served iframe is the largest scope reduction available to you and it costs about a day. Going from an iframe to a full redirect buys more than I expected before reading the supplement, because it lifts 6.4.3 and 11.6.1 apart from the scripts in the redirect mechanism itself. What follows you either way is 11.3.2.
Which PCI DSS 4.0 Requirements Change Code, Not Policy
Most writing on v4.0 concerns documents. These produce a pull request.
| Requirement | What it forces |
|---|---|
| 8.3.6 | Minimum 12-character passwords (8 only where the system cannot support 12), numeric and alphabetic. Was 7 under v3.2.1, and the "at least equivalent" complexity escape hatch is gone. |
| 8.4.2 | MFA for all non-console access into the CDE, not just administrators. The largest single expansion in v4.0. |
| 8.5.1 | The MFA system "is not susceptible to replay attacks", two different factor types, and "success of all authentication factors is required before access is granted". That last bullet kills step-up flows granting partial access after factor one. |
| 8.6.2 | No passwords hard-coded "in scripts, configuration/property files, or bespoke and custom source code" for accounts usable at interactive login. |
| 6.3.2 | An inventory of bespoke and custom software and third-party components incorporated into it. An SBOM in all but name. The official Summary of Changes drops that second clause; the standard does not. |
| 6.4.2 | An automated solution for public-facing web apps that "continually detects and prevents web-based attacks", removing v3.2.1's option of an annual review instead. The standard never says "web application firewall". |
| 3.5.1.1 | Hashes rendering PAN unreadable must be keyed cryptographic hashes of the entire PAN. Unkeyed one-way hashing no longer suffices. |
| 3.5.1.2 | Disk or partition-level encryption satisfies the storage rule only on removable media, and the note is explicit that "hot-swappable drives, bulk tape-backups" are non-removable. Plainly: LUKS, BitLocker and encrypted EBS volumes do not make your database compliant. |
| 3.4.2 | A technical control preventing copy or relocation of PAN over remote access. Under v3.2.1 this was policy text in Requirement 12. |
| 10.4.1.1 | "Automated mechanisms are used to perform audit log reviews." A SIEM mandate in one sentence, naming no product. |
| 11.3.1.2 | Internal vulnerability scans must be authenticated. v3.2.1 required none. |
| 12.3.3 | An inventory of all cipher suites and protocols in use, plus a plan for responding to cryptographic vulnerabilities. Crypto-agility, filed under governance where engineers never look. |
One widely reported change is not one. Log retention under 10.5.1 is 12 months with three months immediately available, exactly what v3.2.1 required under 10.7. Renumbered, not tightened.
The targeted risk analysis under 12.3.1 is the flexibility valve, and it applies to nine requirements: 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1 and 12.10.4.1. For each you set the frequency, documenting the assets protected, the threats, the contributing factors, your justification for the interval, and a review at least every 12 months. That is the difference between weekly synthetic monitoring of your payment page and a cadence you can defend with your own evidence.
Defined Approach vs Customised Approach: Why Almost Nobody Uses It
v4.0 introduced the customised approach: meet the stated objective your own way instead of following the prescribed control. In four years I have not met a team using it, and Appendix D explains why. You document each control in a Controls Matrix, run a targeted risk analysis under 12.3.2 for each, test it, maintain evidence of ongoing effectiveness, and hand it all to an assessor who then derives bespoke testing procedures. Three blockers finish the job: anyone filing a self-assessment questionnaire is excluded outright, "compensating controls are not an option with the customized approach", and its use "may be regulated by organizations that manage compliance programs", so your acquirer can simply refuse.
It is a good idea aimed at the wrong tier. The teams with appetite for a novel control are the ones on a questionnaire, and they are barred.
Is PCI DSS a Legal Requirement in the UK?
No, and the standard says so: whether an entity must comply or validate "is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers)". It also states that where its requirements conflict with local law, local law wins.
The UK statutory framework for payment firms is the Payment Services Regulations 2017, and the FCA does not audit against PCI DSS. Enforcement is contractual, through your merchant agreement: monthly non-compliance fees, scheme fines passed down after a breach, and eventually losing the merchant ID. Not a softer regime, just a different creditor.
Two things to keep straight. 3DS and strong customer authentication do not reduce PCI DSS scope, and FAQ 1603 from September 2026 confirms 3DS authentication values are not treated as sensitive authentication data, so the CAVV may be retained as chargeback evidence. And FAQ 1331 from August 2026 says SAQ eligibility criteria should not guide the scoping of a Report on Compliance unless "explicitly reviewed, discussed and agreed upon" with your acquirer. If your scoping argument rests on an SAQ you are not filing, get it agreed. For the statutory side of European reform, the PSD3 and PSR guide covers obligations that genuinely are law.
What This Means for Payment Engineers
In the order I would do them:
1. Build the script inventory as a file in the repo, not a spreadsheet. One row per script: origin, business or technical justification, approver, date, integrity mechanism. Fail CI when the rendered payment page loads something absent from it. That covers two of the three bullets in 6.4.3 and is the only version that stays accurate.
2. Move CSP out of report-only on payment pages, with script-src on an allow-list plus nonces, and frame-src pinned to your processor's origin.
3. Wire report-to to a collector that alerts a human. A directive nobody watches is not a detection mechanism, and an assessor will say so.
4. Add synthetic monitoring of the rendered page and its response headers, weekly at minimum and from more than one vantage point. Conditional payloads that fire only for certain geographies are what this is meant to catch.
5. Audit for 8.5.1's last bullet. Any flow granting partial access after the first factor is non-compliant as written.
6. Check what your disk encryption buys you. If the answer is transparent volume encryption on a database server, 3.5.1.2 says it does not count.
7. Ask your processor for its 12.9.2 responsibility matrix in writing, and for the script-protection confirmation FAQ 1588 allows. Neither arrives unasked.
If you build the payment layer rather than integrate one, the same discipline applies further down the stack, where idempotency keys have no interoperable standard either.
What Comes After PCI DSS v4.0.1
A prediction, marked as one. The 2026 RFC asked about AI and mobile, and that framing points at agent-initiated payments more than at phones. PCI DSS assumes a consumer browser rendering a payment page, and 11.6.1's reasoning depends on it: the browser is where the JavaScript is interpreted, so the browser is where you detect tampering. Put an autonomous agent there instead and the control has nothing to attach to.
I expect the next revision to add a scope note for headless and agent clients rather than new requirements, and to land in 2027, given the Council took roughly two years from RFC to publication last cycle. What I would not expect is the script rules getting easier. They are the direct answer to browser-side skimming, and skimming has not gone anywhere.
Until then, treat 6.4.3 and 11.6.1 as engineering obligations that exist whether or not your questionnaire asks about them, because that is precisely what the Council has said they are.
Written by Tom Wang, a payments engineer working on stablecoin and cross-border infrastructure.