PCI DSS 4.0.1: Client-Side Security Mandatory in 2026

What PCI DSS 4.0.1 Has Required Since 31 March 2025

PCI DSS 4.0.1 is the current version of the Payment Card Industry Data Security Standard, a limited revision of version 4.0. Version 4.0 introduced a set of new requirements as so-called future-dated best practices - with a transition period that ended on 31 March 2025. Since that date these requirements must be met as part of a PCI DSS assessment (PCI Security Standards Council). Two of them target the client-side security of payment pages directly: Requirement 6.4.3 and Requirement 11.6.1.

Practically everyone who takes card data through a payment page is affected. Even if you outsource the actual card entry to an embedded payment window from a payment provider, you remain responsible for your own page that embeds that window - because that is exactly where it is decided which scripts run in the browser. With version 4.0.1 the PCI Security Standards Council explicitly extended the scope to merchants who previously got by with the simplest self-assessment questionnaire (PCI Security Standards Council). Payment page scope therefore becomes relevant for almost every card-accepting shop.

A brief look at the timeline shows why the topic is pressing now: version 4.0 of the standard was published back in March 2022, and the clarifying version 4.0.1 followed in June 2024 (PCI Security Standards Council). Throughout that entire time, 6.4.3 and 11.6.1 counted as optional best practice - a deliberately long run-up so operators could build the controls without time pressure. That run-up ended on 31 March 2025. Anyone who had not implemented the requirements by then is now catching up under assessment pressure instead of calmly choosing the right solution.

Requirement 6.4.3: Script Inventory, Authorisation and Integrity

Requirement 6.4.3 demands that all scripts loaded and executed in the customer's browser on the payment page are actively managed. A previously invisible, organically grown script landscape becomes a controlled, documented inventory. Specifically, the standard names three conditions that must be met for every single script (PCI Security Standards Council):

1. Authorisation: There is a method that confirms each script is explicitly authorised. A script that nobody approved does not belong on the payment page.
2. Integrity: There is a method that assures the integrity of each script - proof that the delivered file exactly matches the approved state and has not been secretly altered.
3. Inventory with justification: An inventory of all scripts is maintained in which each script has a written justification of why it is necessary (PCI Security Standards Council).

In practice, that is precisely the hurdle. A modern checkout page rarely loads just one script: tag managers, analytics, chat widgets, fraud prevention, payment SDKs and consent tools each bring their own code - and many of them load further scripts in turn. These chains are hard to capture manually and change constantly. Why every embedded third-party script poses its own risk is explored in the guide to the risks of third-party scripts.

Requirement 11.6.1: Weekly Monitoring of Headers and Scripts

While 6.4.3 organises the inventory, Requirement 11.6.1 provides ongoing monitoring. It calls for a change-and-tamper-detection mechanism that alerts the relevant personnel to unauthorised modifications - that is, indicators of compromise, changes, additions and deletions - to the security-impacting HTTP headers and the script contents of the payment page, as received by the consumer browser's Document Object Model (DOM) (PCI Security Standards Council). The perspective is decisive: what matters is not the state on the server but what the customer's browser ultimately loads and executes.

For the frequency of this check the standard allows two paths - a fixed default and a risk-based alternative:

Anyone who does not want to maintain a documented risk analysis ends up with the weekly minimum cadence. For a threat that can capture card data within minutes, however, a week is a long window - many operators therefore check considerably more often. The targeted risk analysis under Requirement 12.3.1 requires you to name the asset being protected, the threat and the factors that make its realisation more likely (PCI Security Standards Council); the result is almost always a tighter interval than seven days.

Why Client-Side Attacks Like Magecart Are So Dangerous

Magecart is the umbrella term for a number of groups that carry out web skimming. The pattern is broadly similar: attackers inject JavaScript into the checkout page that reads the input fields and exfiltrates the stolen card data to a foreign server - while the order completes perfectly normally for the customer. Because nothing crashes and no error appears, the manipulation often goes undetected for a long time. The scale is significant: according to the Verizon Data Breach Investigations Report 2024, around 18% of retail data breaches were attributable to Magecart or digital skimming (Verizon DBIR 2024). In retail, payment data was compromised in roughly 37% of the analysed cases and credentials in around 35% (Verizon DBIR 2024). Overall the report confirmed 10,626 data breaches out of 30,458 examined security incidents (Verizon DBIR 2024).

The malicious code rarely enters through the front door. More often attackers exploit the trust operators place in their embedded third-party components:

A compromised payment page answers the customer with a clean purchase confirmation and the attacker with fresh card data. Without continuous monitoring of the code actually delivered, the operator notices both last.

— XICTRAQ Security Editorial (project experience)

The delay between compromise and discovery is characteristic. Because a skimmer produces neither error messages nor outages, weeks often pass before it is noticed - and during that time fresh card data leaks with every order. The British Airways case illustrates the scale: there the manipulated code was active over a period of several weeks before the manipulation was even noticed. It is precisely this gap that close monitoring of the code delivered in the browser closes, rather than relying on chance findings or tip-offs from outside.

What OWASP Says About Third-Party Scripts

The OWASP Foundation has long treated embedded third-party JavaScript as a risk class of its own. The core of the problem: a third-party tag runs with the same privileges as your own page code. It can read the DOM, access cookies and capture form input - exactly the data that arises on a payment page (OWASP Foundation). Trust in an external provider is therefore also trust in that provider's security.

OWASP distinguishes three fundamental risks when using third-party scripts (OWASP Foundation):

• Loss of control: The provider's changes are delivered instantly and without review - the operator usually does not check the new code before it runs in customers' browsers.
• Arbitrary code execution: Unreviewed script runs on the client side and can become a carrier of malicious code after a server compromise at the provider itself.
• Information disclosure: The third party receives HTTP headers, referrers, cookies and DOM data and can build user profiles from them.

As a technical countermeasure OWASP recommends, among other things, Subresource Integrity (SRI): a stored cryptographic hash ensures that only the reviewed code is executed - though this requires the provider's CORS support and must be monitored continuously, because every legitimate update changes the hash (OWASP Foundation). SRI, a Content Security Policy and continuous script monitoring interlock. How client-side risks fit into the current threat landscape is shown in the overview of the OWASP Top 10 web risks 2025.

Script Integrity Monitoring: Meeting 6.4.3 and 11.6.1 Technically

This is exactly where script integrity monitoring comes in. It builds a SHA-256 baseline for every monitored third-party script, re-fetches the files at a short cadence and raises an alarm as soon as the content drifts from the approved state. In parallel it monitors the page's security-impacting HTTP headers. It thereby translates the abstract requirements 6.4.3 and 11.6.1 into concrete, provable controls.

Combined with the security scan, which uncovers missing protective headers and outdated components, this creates continuous protection of the client side. Anyone who also wants to keep an eye on the behaviour of marketing and consent tags will find a privacy-adjacent use of the same idea in the guide to monitoring consent tag drift.

How to Implement 6.4.3 and 11.6.1 in Practice

The path from requirement to defensible evidence can be structured in six steps. They lead from taking stock through ongoing monitoring to the documentation a Qualified Security Assessor (QSA) wants to see at audit time:

1. Inventory payment pages and scripts: Capture every page on which card data is entered and all scripts loaded on it in the browser - including those loaded on the fly.
2. Document authorisation and justification: Record for each script who approved it and why it is necessary. This meets the inventory and justification part of Requirement 6.4.3.
3. Set an integrity baseline: Store a SHA-256 fingerprint per script as a reference for the approved state.
4. Determine the monitoring cadence: Decide whether to use the default cadence of seven days or justify a tighter frequency via a targeted risk analysis under Requirement 12.3.1.
5. Monitor header and script drift continuously: Set up automatic checking with alerting so that unauthorised changes are detected and reported - the heart of 11.6.1.
6. Retain evidence: Keep the inventory, baselines and change history. These logs are the proof presented to the QSA.

Client-side security is one building block of broader hardening. Securing brand communication contributes too - for example with a verified logo in email, as described in the article on BIMI and the VMC brand certificate. And anyone who manufactures digital products should also consider the parallel CRA vulnerability reporting obligation. For the data protection side of an incident, monitoring can be linked with GDPR compliance.

Start with the script inventory and the baseline - that is the foundation both requirements build on. Registration takes a few minutes, a demo shows the full feature set in context, and the pricing overview places the plans in perspective.