Why PCI DSS 6.4.3 and 11.6.1 exist
E-skimming attacks capture card data from e-commerce payment pages, for example by adding or altering a script that runs in the shopper's browser. The attack happens on the customer's device, so server-side controls alone may not see it. That's why this area is often called client-side security.
PCI SSC says requirements 6.4.3 and 11.6.1 are there to reduce the risk of e-skimming attacks during e-commerce transactions. Each requirement's customized approach objective in PCI DSS v4.0.1 states its intent. For 6.4.3: “Unauthorized code cannot be executed in the payment page as it is rendered in the consumer's browser.” For 11.6.1: “E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated.”
The two requirements work as a pair. 6.4.3 controls which scripts are allowed to run on the page. 11.6.1 watches for changes that get past those controls, and its objective adds that anti-skimming measures can't be removed without a prompt alert.
Both were among the 51 of PCI DSS v4.0's 64 new requirements that were future-dated, and they became mandatory on March 31, 2025. Until that date the standard didn't require them; now they're assessed like any other requirement.
Requirement 6.4.3 in plain terms
6.4.3 applies to all payment page scripts that are loaded and executed in the consumer's browser. For each one, you need:
- A method to confirm the script is authorized, so only scripts someone approved can run on the page.
- A method to assure the integrity of the script, so an approved script that has been altered is detected or blocked.
- An inventory of all scripts, with a written business or technical justification for why each is necessary.
Outcomes, not a product
The requirement asks for “a method”, not a specific product or technique. The guidance in the standard and PCI SSC's 2025 information supplement describe approaches, but the choice of mechanism is yours, and you need to be able to show that it works.
The applicability notes also make clear that the requirement covers scripts loaded from your own environment and scripts loaded from third and fourth parties. Analytics tags, tag managers, chat widgets and testing tools all count if they load on the payment page, and so does anything they load in turn.
Which pages and scripts are in play
Start with the standard's definitions. A payment page is a web-based user interface with one or more form elements intended to capture account data from a consumer, or to submit captured account data, for processing and authorizing payment transactions. Payment page scripts are commands the consumer's browser processes, such as JavaScript; HTML and CSS don't count.
PCI DSS v4.0.1 added applicability notes to clarify how 6.4.3 applies when a page embeds a payment provider's form. If your webpage includes a third-party service provider's embedded payment page or form, such as an iframe, the scripts on your page are yours to manage under 6.4.3, while scripts inside the embedded form are the provider's responsibility. The standard's guidance says to expect the provider to give you evidence that it meets the requirement.
PCI SSC has addressed 3-D Secure in an FAQ: validating 6.4.3 isn't required for scripts called from a merchant checkout page to perform 3DS functions, but any script run for another purpose is subject to 6.4.3.
If you redirect shoppers to a provider-hosted payment page instead, ask your acquirer and provider how that affects your scope and which self-assessment questionnaire applies.
Requirement 11.6.1 in plain terms
11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification, including indicators of compromise, changes, additions and deletions. In PCI DSS v4.0.1, what it watches is the payment page's security-impacting HTTP headers and its script contents, as received by the consumer's browser. Three details matter:
- It evaluates what the browser receives, not only what's in your code repository or on your server. A script injected through a compromised third party would show up there.
- It must alert people, so someone has to be assigned to respond when it fires.
- It runs at least weekly, or at a different frequency you set through a targeted risk analysis performed according to all elements of Requirement 12.3.1.
The targeted risk analysis behind a different frequency
12.3.1 spells out what a targeted risk analysis must include: the assets being protected, the threats the requirement protects against, the factors that contribute to likelihood or impact, an analysis that justifies how the chosen frequency minimizes the likelihood or impact of the threat, a review at least once every 12 months to confirm the results still hold, and an updated analysis when that review calls for one.
The applicability notes add that 11.6.1 isn't meant to have you install software in your customers' systems or browsers. You use techniques on your side to prevent and detect unexpected script activity.
How 6.4.3 and 11.6.1 relate to SAQ A
In January 2025, PCI SSC announced a revised SAQ A, effective March 31, 2025, that removes requirements 6.4.3, 11.6.1 and 12.3.1. PCI SSC explained that 12.3.1 had been in SAQ A only to support 11.6.1. In their place, SAQ A gained an eligibility criterion: the merchant confirms that “their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”
PCI SSC was explicit that the changes affect how merchants report and “do not remove or diminish the underlying requirements within PCI DSS.” The requirements are still in the standard.
FAQ 1588 explains how to meet the new criterion. It applies to merchants whose webpage includes a provider's embedded payment page or form, such as an iframe. It doesn't apply to merchants that redirect shoppers to the provider or fully outsource payment functions. A merchant can meet it in one of two ways:
- Use techniques such as, but not limited to, those in 6.4.3 and 11.6.1, deployed by the merchant or a third party.
- Get confirmation from its third-party service provider or payment processor, which must itself meet PCI DSS, that the provider's solution, implemented as instructed, includes techniques that protect the merchant's payment page from script attacks.
Confirm eligibility before you choose the questionnaire
PCI SSC points merchants who are unsure whether they're eligible for a self-assessment questionnaire, or which one fits, to their merchant bank (acquirer), the applicable payment brands or another compliance entity. Confirm eligibility that way before assuming SAQ A applies. Your organization completes and signs its own questionnaire, so keep the evidence behind your script confirmation.
PCI SSC's March 2025 guidance on payment page security
On March 10, 2025, PCI SSC announced an information supplement, “Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1.” It's available in the PCI SSC document library.
The Council wrote it for any entity that processes payment card transactions through e-commerce, or that has a webpage that can affect the security of e-commerce payments by using embedded iframes, and it names both merchants and third-party service providers as the audience.
Its stated focus is making sure payment page scripts are “properly authorized, checked for integrity, and monitored for tampering,” and managing both scripts and security-impacting HTTP headers to prevent unauthorized changes to webpages. Read it alongside the standard: the supplement is guidance, and the requirements are what you validate against.
Building and keeping a script inventory
The inventory is the backbone of 6.4.3, and it's easier to keep current if you build it the same way every time:
- List every payment page, including checkout variants for mobile, guest checkout and each brand or storefront.
- Record every script each page loads in the browser: first-party files, inline scripts, third-party scripts and anything those scripts load in turn.
- For each script, record its source, its owner inside your organization, and the business or technical reason it's needed.
- Remove scripts that have no justification. Each script dropped from the payment page is one less to authorize and monitor.
- Record how each script is authorized and how its integrity is assured.
- Tie the inventory to change management, so a new or changed script can't reach the payment page without an update and an approval.
- Review the inventory on a schedule and whenever the page changes, and compare it with what your 11.6.1 mechanism actually sees.
People own the justification
A tool can help discover scripts, but the justification and the approval have to come from the people who own the payment page. An inventory that nobody reviews drifts out of date as soon as marketing adds a new tag.
Evidence to keep for 6.4.3 and 11.6.1
Whether you're completing a self-assessment questionnaire or preparing for an assessment, keep evidence that shows the requirements operate over time, not only that they were designed:
- The current script inventory, with justifications, owners and approval records
- Configuration showing how scripts are authorized and how their integrity is assured
- Change records for scripts added to, changed on or removed from payment pages
- The 11.6.1 mechanism's configuration, the pages it monitors and how often it runs
- Alert records, and how each alert was investigated and resolved
- If 11.6.1 runs less often than weekly, the targeted risk analysis and its annual review
- For SAQ A merchants, the evidence behind the script eligibility confirmation, such as your record of the provider's confirmation