PCI DSS requirement 6.4.3, in plain terms

PCI DSS 6.4.3 requires you to manage every script that loads and executes in the consumer's browser on a payment page, by confirming each script is authorized, assuring the integrity of each script, and maintaining an inventory with a written justification of why each one is necessary. It was introduced in PCI DSS v4.0 as a future-dated requirement and became mandatory on 31 March 2025 under v4.0.1. It exists because card-skimming attacks such as Magecart do not compromise your server: they add or alter a script that runs in your customer's browser, reads the card fields, and sends the contents elsewhere. An inventory you can trust is the control that makes an unapproved script visible.

PCI DSS v4.0.1 requirement 6.4.3 applies to all payment page scripts that are loaded and executed in the consumer's browser. It asks for three things, and an assessor will look for all three separately:

Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.

The hard part is not writing the list. It is knowing what to put on it. Most teams start from the tags they remember adding, and the inventory is wrong on day one, because a tag manager loads vendors, and those vendors load their own. A script you never chose is still a script that executed on your payment page, and 6.4.3 does not distinguish between the two.

Starting from what actually executed inverts the problem. The tag reports every script that ran in a real session, so the inventory begins as a complete list of observed reality, and your job becomes approving, justifying or removing each entry rather than trying to remember what is there.

You approve a vendor, the vendor loads its own vendors. 6.4.3 applies to every script that executes, not only the ones you added yourself.

A vendor can change the contents of a file without changing its address. If your integrity check is "the script is still loading from the domain we approved", you will not notice. Subresource Integrity solves this for static files by pinning a hash in the markup, but it breaks the moment a vendor legitimately updates their script, which is why few teams run SRI on third-party tags in production.

Pinning approval to the payload hash gets the same guarantee without the breakage. When a vendor ships new code, the script does not silently continue: it returns to the inventory as a change that needs review. You decide whether to approve the new version. That is the difference between an inventory that reflects reality and one that reflects the day it was written.

A justification answers why this script needs to be on this page, not why the vendor is useful in general. Assessors notice the difference, and the second version is also the one that makes it obvious when a script should be removed.

Three questions make most justifications write themselves: what does this script do on the payment page, who owns the decision to keep it, and what breaks if it is removed. If the third answer is "nothing", you have found something to cut, which is the cheapest compliance work available.

You will see this requirement written both as PCI 6.4.3 and as PCI DSS 6.4.3. They are the same thing, and the short form is what most people search for. It has been mandatory since 31 March 2025, when it stopped being a future-dated best practice in PCI DSS v4.0. It applies to entities with payment pages where scripts execute in the consumer browser. SAQ A merchants received a carve-out in the January 2025 update, but it is narrower than most people assume: you have to confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems, which is a statement you should be able to support. If you embed a payment iframe, the iframe belongs to your provider but the page around it is yours, and that page is where a script can reach the form.