PCI DSS 4.0 became the mandatory standard on March 31, 2024 when PCI DSS v3.2.1 was retired. The 64 new and evolved requirements include changes that affect e-commerce architectures in ways most development teams have not fully digested. The most architecturally significant: Requirement 6.4.3, which mandates that all scripts loaded or executed on payment pages be managed and authorized, with an inventory maintained and a method in place to confirm that each script is authorized and integrity can be assured. This requirement alone breaks the standard SPA-based payment page architecture used by the majority of e-commerce platforms.
The PCI DSS 4.0 customized approach allows entities to use different controls to achieve the stated objective of a requirement. The customized approach creates flexibility — but it also creates assessment complexity, because the assessor must validate that the customized control achieves the stated objective. Organizations using the customized approach need a more sophisticated relationship with their QSA, not less.
Requirement 6.4.3: Script Security for Payment Pages
Requirement 6.4.3 requires: all payment page scripts that are loaded and executed in the consumer's browser are managed, authorized, and an inventory of all scripts is maintained, with a method to confirm each script is authorized and integrity can be assured. Every JavaScript file — analytics scripts, chat widgets, A/B testing scripts, and tag manager payloads — that loads on a payment page must be in an authorized inventory and must have integrity verification. Subresource Integrity (SRI) hashes satisfy the integrity requirement for static scripts. For dynamically-loaded scripts served from third-party CDNs where content changes, SRI alone is insufficient — the script version and hash must be managed at deployment time.
The SPA architecture problem: single-page applications that load payment pages as routes within a larger application often load scripts once at application initialization — not scoped to the payment page. The entire application's script inventory becomes the payment page script inventory under 6.4.3. The compliant architecture for SPAs: isolate the payment flow as a separate application or iframe with its own script loading scope, or implement a Content Security Policy that restricts script execution on the payment route to the authorized inventory.
Requirement 6.4.3 also applies to scripts loaded by scripts — if a tag manager loads additional scripts based on rules, those dynamically loaded scripts are also in scope. A tag manager rule that loads a third-party chat widget on the payment page puts the chat widget's script in scope for 6.4.3. The authorization and inventory requirement applies to the full script execution graph, not just top-level script references.
Targeted Risk Analysis: Replacing Prescriptive Frequencies
PCI DSS 4.0 introduces targeted risk analysis (TRA) as an alternative to prescriptive control frequencies. Requirement 12.3.1 requires that each PCI DSS requirement with a customizable frequency be supported by a TRA that defines the frequency based on the organization's specific risk environment. The TRA must document the threat landscape for the specific control, the assets or systems the control protects, and how risk factors were considered in determining the frequency.
New Authentication Requirements
PCI DSS 4.0 strengthens authentication requirements significantly. Requirement 8.4.2 mandates MFA for all access into the CDE. Requirement 8.3.6 requires passwords/passphrases to meet a minimum length of 12 characters. Requirement 8.6.1 requires all user accounts and related access privileges to be reviewed at least once every six months. These are now mandatory at PCI DSS Level 1 without the previously available compensating control path.
- Audit all scripts on payment pages — build the authorized inventory required by 6.4.3 before the next QSA assessment
- Implement Subresource Integrity for all static scripts on payment pages
- Evaluate whether SPA architecture scopes payment page scripts correctly — consider isolated payment flow architecture
- Review tag manager configurations for payment page script loading — dynamic script loading is in scope for 6.4.3
- Implement targeted risk analysis process for requirements with customizable frequencies — document the methodology
- Audit CDE authentication — MFA is now required for all CDE access under 8.4.2, not just administrative access
EU AI Act: What CTOs Actually Need to Do Before August 2026
DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase
FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.