PCI DSS 4.0 has been on the calendar for years, but most operators only started paying attention when the script-integrity requirements moved from "best practice" to mandatory on March 31, 2025. If you accept card payments on a web page, and that page loads any third-party JavaScript, Requirement 6.4.3 applies to you. This post walks through what the control actually requires, why it exists, and the practical steps for meeting it without turning your site into a maintenance treadmill.

What Requirement 6.4.3 says

The text is short and specific. Any script loaded and executed on a web page that accepts cardholder data must be subject to a mechanism that confirms each script is authorized, a mechanism that assures the integrity of each script, and an inventory of all scripts with written justification for each one. That is three deliverables, and the PCI Security Standards Council made clear during the 2025 workshops that all three are required — you cannot skip the inventory and rely only on Subresource Integrity hashes, and you cannot maintain an inventory without some integrity control.

Why this control exists

Magecart-style attacks kept working. They kept working because code review of your own repository tells you nothing about the third-party chat widget, analytics tag, or CDN that is being loaded at runtime. The attacker does not need to touch your git history. They compromise an upstream vendor, push new code, and every site loading that vendor's script is now silently exfiltrating card data.

The Polyfill.io incident in mid-2024 affected roughly 100,000 sites in a single change. The British Airways breach was the same pattern. The Ticketmaster incident. The list is long enough that PCI 4.0 finally codified the requirement to control what third-party scripts run on checkout and payment pages.

Authorization: the inventory with a reason for each script

The authorization piece is a document, not a technical control. You need a list of every third-party script that loads on a page where cardholder data is entered or displayed. For each script, a sentence or two explaining why it is there and who authorized it. Your analytics tag might be "marketing attribution, approved by CMO 2025-01-15." Your payment processor's own script would be "required by PSP integration, approved by engineering 2024-11-20." Scripts nobody can explain get removed. That part of the exercise alone is worth the effort — most sites have five to ten scripts nobody remembers approving.

Keep the inventory in a format your QSA can read. A spreadsheet is fine. A versioned markdown file in your internal docs is better because it has history.

Integrity assurance: what options you have

The PCI guidance explicitly lists three acceptable approaches. Subresource Integrity hashes on the script tag are the cleanest. Content Security Policy with script-src controls is acceptable if you can enumerate allowed sources tightly. Tag-management systems with integrity controls built in are allowed but must be verifiable, not just trusted. In practice, SRI hashes are the most defensible because they fail closed: if the vendor changes the file, the browser refuses to execute it.

The operational trade-off is real. Every time a vendor legitimately updates their script, your SRI hash will break and the script will stop loading. That means your monitoring needs to know the difference between a legitimate vendor update and a silent malicious change. Many vendors refuse to version their scripts or provide a changelog, which makes hash management genuinely painful. The trick is to pin hashes for the scripts that matter most (payment forms, checkout flows) and use broader controls elsewhere.

Monitoring for change detection

The control only works if you notice when a script changes. That means continuous monitoring, not a one-time audit. Tooling that scans your site at runtime, records the hash of every external script, and alerts on any change is what turns Requirement 6.4.3 from a theoretical document into an actual defense. Without monitoring, you have an inventory that was accurate the day it was written and is silently wrong every time a vendor ships.

BlackSight's supply chain scanner does exactly this — inventory third-party scripts, record hashes, cross-reference breach history, and alert on drift. Worth looking at whether you use it or build equivalent tooling in-house.

What QSAs are actually asking for in 2026 audits

Three artifacts, every time. The current script inventory with business justification. Evidence of the integrity mechanism (SRI snippets, CSP headers, tag-manager config). Evidence of change detection (monitoring reports, alert history, sample incidents). If you cannot produce all three, you have a finding. If you can produce all three, this control is generally signed off in the first pass.

The most common finding we see is "inventory exists but no continuous monitoring." Operators do the one-time audit and never automate it. The second most common is "SRI hashes pinned but no process when they break." Both are avoidable.

Run a free third-party script inventory at scanner.blacksight.io/supply-chain-security to see what your current state looks like before your next QSA visit.