Not PCI DSS 6.4.3 & 11.6.1 Compliant Yet? Time’s Running Out!

You know what’s happening on April 01 2025? Yes, there’s April Fools, but that’s also the first day that critical requirements in PCI DSS v4 go into effect for all merchants. 

‍

That’s right, all merchants, regardless of SAQ level. 

‍

It doesn’t matter how small or large your business is, or where you’re located. 

‍

If you’re an entity that accepts online payments, then you need to take PCI DSS v4.0, especially requirements 6.4.3 and 11.6.1, very, very seriously.

‍

There’ll be a lot of jokes come April 01 2025, but this won't be one of them! So, with fewer than 80 days left at the time, we hosted a webinar mapping out what you must do to meet PCI’s 6.4.3 and 11.6.1 requirements before the deadline.

‍

Last week, we brought Chuck Brooks (President of Brooks Consulting International) together with our very own Thomas Borrel (Chief Product Officer at DataStealth) and James Fuentes (Product Manager at DataStealth), to review 6.4.3 and 11.6.1’s challenges and define the steps you must take to stay out of the PCI Security Standard Council’s sights. 

‍

You can watch the webinar at any time on our YouTube channel, but if you’d like to start with a quick overview of the discussion, then keep reading!

Breaking Down PCI’s DSS Requirements 6.4.3 and 11.6.1

PCI DSS v4.0 was published in 2022 and came into effect in March 2024, with requirements 6.4.3 and 11.6.1 being designated as best practices until March 31, 2025. 

‍

As of the publishing date of this post, that leaves you with less than 75 business days to meet those requirements; meaning, organizations need to move fast.

‍

“When the council released the standard, they gave our industry two years to prepare and an additional year for some of those requirements - like 6.4.3 and 11.6.1. The simple fact that they gave us that much time should tell us something - they understood how complex it was to meet both of these requirements.” - Thomas Borrel. 

‍

PCI DSS 6.4.3 Sets the Processes

Requirement 6.4.3 requires that all payment page scripts that are loaded and executed in the consumer’s browser must be managed as follows:

‍

• Inventoried with written technical/business justifications
• Be explicitly authorized by your organization
• Have their integrity assured

‍

It’s easy to underestimate how many scripts you’re using, but Thomas noted that the average payment page today hosts over 60 scripts “and their uses go beyond just development teams; marketing teams are also heavy users with their own use cases, such as understanding user journeys or customizing user experiences.” 

‍

As there are a lot of use-cases for scripts, there are also hundreds - if not thousands - of tools out there requiring their users to insert scripts. It can be really challenging for cybersecurity leaders or compliance heads to keep track of and can lead blind spots to what’s on their payment pages.

‍

That’s why the PCI SSC now requires you to establish controls in line with requirement 6.4.3 to clearly document and justify each script, check each script vendor’s privacy and security measures (especially if they generate fourth-party scripts), and explicitly approve or authorize them for use. 

‍

This also means that you’ll need to work with marketing, sales, and all stakeholders who need to insert scripts in the website (not just the payment page - more on that later) to make sure all scripts can be justified and authorized.  This is no longer a compliance or engineering-only issue, but an all-hands-on-deck challenge. These new stakeholders need to be involved from day-one and an ongoing basis.

Pages Leading to the Payment Page Aren’t Exempt

6.4.3 also applies to the pages that direct to the payment page. The scope is now much more expansive and will require input from your other teams. 

‍

Moreover, even if you’re using a TPSP and iframe to house your payment gateways, the parent page hosting it must also comply with PCI DSS v4.0’s requirements 6.4.3 and 11.6.1.

PCI DSS 11.6.1 Requires Tools

Requirement 11.6.1 mandates that organizations deploy tamper detection mechanisms. These need to alert personnel about unauthorized modifications to HTTP headers or script content. In addition, these mechanisms must monitor the headers/scripts every seven days at a minimum.

‍

Tamper detection is critical for identifying unauthorized changes, deletions or additions. Thomas noted that deletion is particularly critical as it often signals an attack is in progress. 

‍

What’s at Stake of Not Complying?

The potential consequences of failing to meet PCI’s 6.4.3 and 11.6.1 requirements cut across a few key areas, including financial penalties, operational disruption, reputational damage, and a much sharper level of scrutiny from the PCI SSC.

‍

Besides penalties from the PCI SSC, failing to comply with 6.4.3 and 11.6.1 also leaves you a lot more exposed and vulnerable to attacks, like e-skimming.

‍

“What’s concerning is that these types of attacks often go undetected for long periods of time. By the time they are discovered, significant damage has already been done - payment data is stolen, customer trust eroded, and businesses are left to deal with the aftermath. The attackers are also becoming increasingly sophisticated, leveraging tools like AI to identify vulnerabilities in supply chains and outdated scripts.” - Chuck Brooks. 

‍

It’s important to emphasize Chuck’s last point about vulnerabilities in supply chains. Many tools themselves rely on scripts, often referred to as fourth-party scripts. 

‍

While you can do your due diligence to ensure vendors follow best practices in preventing breaches on their end, there is always the risk of a breach or attack somewhere along the chain won’t take place (even if your own website or environment is secure).

‍

That’s why Chuck highlighted the need to adopt proactive monitoring with real-time detection and remediation measures. 

‍

Becoming PCI DSS 6.4.3 and 11.6.1 Compliant

Why Script-Based Solutions aren’t Enough

One common approach to requirements 6.4.3 and 11.6.1 is to deploy script-based solutions. However, Thomas discussed how this approach has major drawbacks:

‍

“The core issue with script-based solutions is their inherent vulnerability. Essentially, these solutions rely on scripts to monitor other scripts, which creates a recursive problem. If the monitoring script is compromised or removed, the entire security mechanism can fail.”

‍

Thomas walked through an example of how attackers can delete or deactivate the monitoring script on certain transactions. They avoid detection and with more selective targeting, it could get very difficult to identify breaches in real-time.

‍

Browser compatibility is also a major issue. Many script-based solutions tend to work with just a subset of browsers, usually the most popular ones. As a result, as much as 10% of all transaction web traffic remain unprotected. Script-based solutions also depend on browser behavior as well as the execution order of the scripts, which attackers can manipulate. For example, an attacker can run their execution ahead of the monitoring script. 

‍

“Ultimately, relying on scripts to secure scripts introduces too many points of failure and doesn’t provide the robust protection needed for PCI DSS v4.0 compliance,” said Thomas. 

‍

To showcase these vulnerabilities, DataStealth’s James Fuentes did a demo to prove how an attacker could manipulate/remove a monitoring script and, in turn, add a rogue QR code that could compromise a payment page (see here for the full video).

‍

‍

How DataStealth Will Make You Compliant

Unlike script-based solutions, DataStealth’s PCI Tampering Detection and Protection (TDP) will ensure PCI DSS 6.4.3 and 11.6.1 compliance by operating in the line of traffic. It doesn’t require code changes, agents, or collectors to be installed to your system. 

‍

Not only does this approach reduce integration complexity, but it also ensures compatibility with 100% of the browsers. In effect, DataStealths TDP solution protects your payment page  universally across all your customers.

‍

You can see how this works in action in James’ demo (see here for the video).

‍

Finally, if you want to know more about PCI DSS v4.0 compliance for requirements 6.4.3 and 11.6.1, reach out to our team for more information and next steps. 

‍

‍

Top Audience Questions 

• Do I need to be PCI DSS v4.0-compliant by March 2025? Or can I wait until my next audit (if it happened after March 2024?)

Compliance must be achieved by March 31, 2025—not just for your next audit (if it will take place after April 01 2025) but as an ongoing requirement starting from that date. In other words, you’re accountable from March 31, 2025.

• Do script-based solutions work for PCI DSS v4.0 compliance, or are they not a good choice?

Script-based solutions are generally not recommended for PCI DSS v4.0 compliance due to their inherent vulnerabilities and dependency on scripts monitoring other scripts, which creates additional points of failure.

• When a script change is found, do you shut down the user session or route around the script?

This depends on policy settings. DataStealth can either block access to compromised pages or remove unauthorized scripts while allowing other content to reach the consumer’s browser.

• How long does it take to meet requirements 6.4.3 and 11.6.1?

The timeframe varies depending on factors like the number of payment pages and complexity of payment flows.

• We manage our payments through an iframe with Stripe. So, are these new requirements our responsibility? Or theirs?

There may be a shared responsibility. The merchant may be responsible for the parent page hosting the iframe, while the third-party provider (like Stripe) may be responsible for scripts delivered through the iframe. Please consult your QSA for an answer specific to your environment.

• How do you handle updates to scripts?

Collaboration between DataStealth and merchants is crucial. Each script update must be authorized, as updates can introduce new vulnerabilities through dependencies or libraries that may have been compromised.

• What is the scope of applicability for single-page applications (SPAs) under these new requirements?

For SPAs, unless there is a clean redirect outside the application for payment processing, the entire SPA is considered in scope because it acts as the parent page housing forms or iframes.