Your audit flagged PCI DSS 6.4.3 and 11.6.1. Learn the fastest path to compliance with server-side eSkimming protection – no code changes, operational in days.
The dust has settled on your PCI DSS audit, and the results are in: your organization was flagged on requirements 6.4.3 and 11.6.1.
You're not alone.
These two requirements, introduced in PCI DSS v4.0 and enforced since March 31, 2025, have become one of the most common compliance gaps for both merchants and service providers processing online payments.
Here's what you need to know:
Requirement 6.4.3 mandates that you maintain a complete inventory of all scripts executing on your payment pages, with documented authorization and integrity verification for each one.
Requirement 11.6.1 requires you to deploy a tamper detection and protection mechanism that monitors scripts and security-impacting HTTP headers on those pages, alerting your team to unauthorized changes.
Together, they form the PCI DSS v4.0 defence against e-skimming attacks, i.e., the class of client-side threats, often called Magecart, where attackers inject malicious JavaScript into checkout pages to steal payment card data in real time.
Two approaches exist for meeting these requirements: client-side JavaScript monitoring or server-side traffic inspection.
DataStealth's eSkimming Protection uses server-side inspection, meaning it requires no code changes, provides 100% browser coverage, and cannot be tampered with by attackers.
Being flagged under PCI DSS requirements 6.4.3 and 11.6.1 indicates your organization lacks adequate controls for managing and monitoring the scripts that run on your payment pages.
This is a serious gap. The March 31, 2025, enforcement deadline has passed, which means these requirements are no longer best practices – they are mandatory.
PCI DSS requirement 6.4.3 falls under Requirement 6, which governs secure systems and software development.
It mandates that all payment page scripts loaded and executed in the consumer's browser be managed through three controls: a method to confirm each script is authorized, a method to ensure the integrity of each script, and a maintained inventory with written justification for each script's necessity.
PCI DSS requirement 11.6.1 falls under Requirement 11, which covers regular security testing.
It requires organizations to deploy a change and tamper-detection mechanism that alerts personnel to unauthorized modifications – i.e., indicators of compromise, changes, additions, and deletions – to the HTTP headers and script contents of payment pages as received by the consumer's browser.
These mechanisms must evaluate payment pages at least weekly, or at intervals determined through a targeted risk analysis per Requirement 12.3.1.
The consequences of non-compliance are significant.
Payment processors and card brands can levy non-compliance fees, increase your transaction rates, or revoke your ability to process payments entirely.
If a breach occurs while you are non-compliant, your liability exposure increases substantially.
The PCI compliance levels that apply to your organization determine the specific audit and reporting requirements you face, but requirements 6.4.3 and 11.6.1 apply universally, regardless of whether you validate through a Self-Assessment Questionnaire (SAQ) or a full Report on Compliance (ROC).
The threat is not theoretical either.
In January 2026, researchers at Silent Push exposed a long-running Magecart campaign that had been operating undetected since 2022, targeting checkout pages across thousands of e-commerce websites and harvesting payment data from six major payment networks.
The attackers used heavily obfuscated JavaScript that could erase its own traces, making detection by traditional server-side defences nearly impossible.
These are among the leading data breach risks for enterprises today, and requirements 6.4.3 and 11.6.1 exist precisely to prevent them.
Meeting requirements 6.4.3 and 11.6.1 is not a one-time checkbox exercise. These controls demand continuous monitoring and management, which is where most internal teams struggle.
Modern payment pages load dozens of scripts – e.g., analytics tools, marketing pixels, payment gateway integrations, A/B testing platforms, customer support widgets, logistics tracking, and more.
Each one of these scripts must be cataloged, authorized with a written business justification, and continuously verified for integrity.
Third-party scripts are especially problematic because they often dynamically load additional fourth-party scripts, expanding the attack surface without your knowledge.
Third-party vendors frequently update their code to fix bugs, add new features, and apply security patches. Each update changes the script's integrity hash, triggering reviews and re-authorization.
Performing these checks periodically – say, weekly – may satisfy the minimum requirement under 11.6.1, but it leaves meaningful gaps. Attackers have demonstrated the ability to inject, execute, and remove skimming code between scan intervals.
Building and maintaining an in-house script management and tamper detection system requires dedicated engineering time, security expertise, and ongoing documentation for QSA review.
For organizations already stretched thin across other PCI DSS v4.0 requirements, diverting internal teams to stand up a custom solution for 6.4.3 and 11.6.1 creates friction and slows development velocity.
Some approaches to meeting these requirements, particularly those that inject additional monitoring scripts into payment pages, can inadvertently expand your PCI scope.
Adding new JavaScript to your checkout flow introduces new components that must themselves be inventoried, authorized, and monitored, creating a compliance feedback loop.
Organizations pursuing PCI audit scope reduction should be especially wary of solutions that have the opposite effect.
When evaluating solutions for PCI DSS requirements 6.4.3 and 11.6.1, you'll encounter two fundamentally different architectural approaches: server-side traffic inspection and client-side script-based monitoring.
Understanding the difference matters. It affects your browser coverage, tamper resistance, implementation effort, PCI scope, and ongoing maintenance burden.
Three differentiators deserve deeper examination.
The PCI Council's own guidance document, "Payment Page Security and Preventing E-Skimming," acknowledges that script-based monitoring solutions can be disabled or tampered with.
The guidance specifically notes that merchants using script-based approaches must implement additional controls to alert them if those monitoring scripts are deleted from the protected page.
Server-side inspection does not have this vulnerability because there is no client-side component for attackers to target.
For a deeper analysis of these limitations, see our breakdown of why script-based solutions fail to meet PCI compliance for 6.4.3 and 11.6.1.
Client-side JavaScript can only run in browsers that support it and only when it is not blocked.
Users running older browsers, accessibility tools, or browser extensions such as ad blockers may never run the monitoring script, leaving their sessions unprotected.
Server-side inspection operates on the traffic itself before it reaches any browser, making it entirely agnostic to the client's device, operating system, or browser configuration.
Client-side solutions require you to inject sensor scripts into your application code.
This creates deployment dependencies, ties compliance to your release cadence, and introduces scripts that must themselves comply with 6.4.3's inventory and authorization requirements.
Server-side inspection requires only a DNS routing change – i.e., your application code remains untouched.
If you want to understand how to validate that your chosen approach genuinely protects your checkout pages, read our guide on how to prove your website is secure against script-based attacks.
DataStealth's eSkimming Protection was built from the ground up to meet and exceed PCI DSS v4.0 requirements 6.4.3 and 11.6.1.
It uses server-side traffic inspection, operating inline with your web traffic before pages are served to consumers. This architecture eliminates the vulnerabilities inherent in script-based approaches.
DataStealth dynamically catalogues every script executing on your payment pages – i.e., inline, first-party, third-party, and fourth-party – in real time, before the page reaches the consumer's browser.
It maintains a comprehensive inventory of authorized scripts, performs integrity checks, and automatically blocks unauthorized scripts from loading.
This automated approach to script management ensures continuous compliance without manual intervention or periodic scanning gaps.
DataStealth continuously monitors scripts and security-impacting HTTP headers in real time, inspecting traffic before page delivery rather than after.
It instantly detects unauthorized changes, additions, deletions, or tampering attempts, triggering real-time alerts and automated security responses.
This goes well beyond the minimum weekly evaluation cadence required by 11.6.1, providing persistent browser tamper detection that operates every time a page is served.
Because DataStealth inspects traffic before it reaches the browser, it provides complete coverage regardless of the consumer's device, operating system, or browser.
There are no gaps for older browsers, no dependency on JavaScript execution, and no vulnerability to ad blockers or browser extensions disabling the protection.
Every customer session is protected equally.
Once DataStealth installs eSkimming Protection in your environment, our team takes on most of the workload of managing and maintaining your implementation.
This frees your organization from needing to train teams on a new technology stack or hire additional staff dedicated to 6.4.3 and 11.6.1 compliance.
DataStealth is a PCI DSS Level 1 Service Provider, audited annually by a Qualified Security Assessor (QSA).
We provide an Attestation of Compliance (AOC), a responsibility matrix, and complete documentation so your QSA can easily evaluate and verify your compliance efforts.
If you work with a QSA who supports DataStealth's approach, you can learn more about our QSA Partner Program.
Implementation timelines depend on your specific environment, but DataStealth lends for a much faster deployment as:
DataStealth handles deployment, management, and ongoing enforcement end-to-end.
You get powerful eSkimming Protection software plus a team of expert personnel who actively maintain and enforce compliance policies alongside your staff.
For organizations that have just been flagged on 6.4.3 and 11.6.1, speed matters.
Every day without compliant controls in place is a day of exposure — to potential e-skimming attacks, to non-compliance penalties from payment processors, and to increased breach liability.
DataStealth is designed to close that gap as quickly as possible.
It's also worth noting that the PCI Council has updated SAQ A eligibility criteria, requiring merchants to confirm that their sites are not susceptible to attacks from scripts that could affect their e-commerce systems.
Even if you previously qualified for SAQ A and were exempt from directly addressing 6.4.3 and 11.6.1, the new SAQ A eligibility requirements mean you still need to demonstrate that your payment pages are protected.
Understanding whether to continue working on 6.4.3 and 11.6.1 or focus on qualifying under SAQ A is a decision worth discussing with your QSA.
You were flagged for a reason – and now the clock is running.
DataStealth's eSkimming Protection gives you a clear, fast path to compliance with requirements 6.4.3 and 11.6.1, without burdening your internal teams or expanding your PCI scope.
Schedule your demo today and see how effortless payment page security and compliance can be.
Bilal is the Content Strategist at DataStealth. He's a recognized defence and security analyst who's researching the growing importance of cybersecurity and data protection in enterprise-sized organizations.
