by Source Defense
The introduction of PCI DSS 4.0.1 marked an important step forward for the payments ecosystem. For the first time, the standard directly acknowledges the risks posed by client-side attacks and eSkimming (aka digital skimming), and introduces explicit requirements (6.4.3 and 11.6.1) to address them.
That progress reflects years of advocacy from across the PCI community, including merchants, QSAs, and security providers working to close a long-standing gap in web security.
But one year in, it is increasingly clear that the standard, as currently implemented and interpreted, is not fully aligned with how modern eSkimming/digital skimming attacks actually work. In several key areas, it risks creating a false sense of security that adversaries are already exploiting.
As a PCI Board of Advisors member, a Principal Participating Organization in the PCI Council and a global partner to Mastercard in combating digital skimming, Source Defense believes it is critical to address these gaps directly.
The Problem with “Controls That Don’t Control”
PCI DSS 4.0.1 includes examples and guidance that point organizations toward controls such as Content Security Policy (CSP) and Subresource Integrity (SRI). While these mechanisms have value in specific contexts, they are fundamentally misaligned with the nature of modern eSkimming / digital skimming attacks. They are static controls applied to a dynamic threat.
CSP relies on allowlists and requires constant maintenance. SRI depends on fixed hashes, making it ineffective for dynamic scripts. Neither approach provides behavioral awareness, and neither can reliably prevent malicious activity when attackers operate within trusted domains or compromised third-party services.
Even more concerning, their inclusion as reference approaches in the DSS has led many organizations to believe they are adequately protected when in reality, they are not. This is a real concern. Industry guidance bodies, QSAs, and even contributors to the standard have acknowledged that CSP and SRI do not prevent eSkimming in practice. When controls are positioned as sufficient but fail under real-world conditions, they introduce risk rather than reduce it.
A Scope That Misses the Actual Attack Surface
PCI DSS 4.0.1 places primary emphasis on “payment pages.” That framing is intuitive but incomplete.
Modern eSkimming/digital skimming attacks rarely begin on the payment page itself. They target the broader customer journey: product pages, cart flows, and login forms. They use the entire website as the attack surface, not just the payment page. Attackers exploit trusted scripts, tag managers, and first-party code long before a transaction is initiated.
Empirical evidence reinforces this point. In forensic investigations, compromises consistently originate on the referring page, not the payment page or the third-party hosted payment form.
Focusing controls narrowly on payment pages creates blind spots across the rest of the site. It also reinforces a dangerous assumption that outsourcing payment processing removes risk. It does not.
Attackers are increasingly using techniques such as payment flow manipulation – injecting fake payment options, redirecting users to fraudulent gateways, and capturing data before it ever reaches a processor. If the scope of protection does not reflect the scope of the attack, compliance will never equal security.
Compliance Confusion Undermining Security
Changes that were made to SAQ-A eligibility in January of 2025 further complicate the landscape. By removing explicit requirements for 6.4.3 and 11.6.1 for some, while introducing vague language around confirming a site is “not susceptible” to script-based attacks, the standard has created confusion across the merchant community.
Many organizations interpreted these changes as a reduction in responsibility. In practice, the opposite is true: the requirement to secure against eSkimming / digital skimming still exists, but without clear, enforceable guidance.
This has led to delayed adoption of meaningful controls, particularly among Level 3 and Level 4 merchants, who are among the most frequently targeted. The result is a fragmented ecosystem where compliance posture varies widely, and attackers continue to operate with minimal resistance.
Detection Alone Is Not Enough
PCI DSS 4.0.1 appropriately includes both preventive (6.4.3) and detective (11.6.1) controls. However, in practice, many implementations lean heavily on detection. That is a problem because eSkimming is a real-time attack. Data is exfiltrated the moment a malicious script executes. Alerts generated after the fact do not protect the consumer, they just document the breach.
Modern security requires prevention at the point of input. It requires the ability to control script behavior in real time, not simply monitor it. This distinction is important because it is the difference between observing an attack and stopping it.
A Call for Evolution, Not Criticism
PCI DSS 4.0.1 has done something important: it has brought client-side risk into focus. Now the standard must evolve to reflect the reality of the threat. That should include:
- De-emphasizing static controls like CSP and SRI as primary defenses
- Expanding scope from payment pages to full payment flows and site-wide exposure
- Clarifying SAQ-A guidance to eliminate ambiguity and loopholes
- Prioritizing real-time, behavior-based prevention over detection-only approaches
The threat landscape has already moved and attackers are operating at scale, leveraging trusted infrastructure, and continuously adapting their techniques. The standard must keep pace.
Moving Forward as a Community
Source Defense is proud to work alongside the PCI Council, QSAs, merchants, and partners like Mastercard to strengthen the global payments ecosystem and improve the standard. Compliance should reflect real-world risk and drive real-world protection. The opportunity in front of the PCI community is clear: refine the standard to match how attacks actually happen and ensure that organizations are not just compliant, but secure.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.