With less than four months until the compliance deadline for new eSkimming security controls in PCI DSS, Source Defense, a pioneer in client-side security, hosted a critical roundtable discussion featuring leading Qualified Security Assessors (QSAs).
The webinar brought together top industry experts to address requirements 6.4.3 and 11.6.1, which organizations must implement by Q1 2025. The panel included Ron Tosto from Servadus, KJ Sedjro from RSM US, Daniel Baron from Protiviti, and Matt McGuirk from Source Defense.
The New Frontier: Client-Side Security
Ron Tosto, Principal Security Consultant at Servadus, emphasized that these requirements emerged directly from documented security incidents. “This requirement didn’t come out of the blue. It’s really based on things that you’ve seen from PCI forensics investigations actually happen in the real world,” Tosto said.
The initial response from organizations revealed significant confusion about scope and applicability. KJ Sedjro, Director of Payment Security at RSM US, highlighted this common challenge: “A lot of clients did not know at first if that it applied to them. So it was more of making them understand at first that even the user browsers, whatever happened on that side, affects them directly,” Sedjro said.
Requirements Evolution
The technical complexity of the requirements posed a significant challenge for organizations, particularly in tracking the entire chain of scripts that might appear on payment pages. While previous requirements focused on direct inventory, the new standards demand visibility into dynamically loaded third, fourth, and even fifth-party scripts.
Ron Tosto, highlighted this dramatic shift: “I remember the first time I read the requirement, it was like, what do we have to do? And how are we going to get this done? Because even in 6.4.3, it simply said to have an inventory, but now it’s having an inventory of the supply chain,” Tosto said.
A significant evolution occurred between PCI DSS versions 4.0 and 4.0.1 that relaxed the restrictions on allowable scripts. While version 4.0 strictly limited payment pages to only include scripts directly supporting payment functionality, version 4.0.1 adopted a more flexible approach.
“Originally, it said that it only scripts that support payment functionality. Now, in 4.01, it says that it’s anything that’s justified for business or technical reasons,” said Daniel Baron, Senior Director at Protiviti. This revision gives organizations more flexibility to maintain necessary business functionality while requiring proper justification for each script’s presence.
Understanding Scope and Responsibility
A critical area of confusion for many organizations centers on their security responsibilities when using payment service providers. Many merchants assume that outsourcing payment collection through iframes or hosted payment pages transfers all security responsibilities to their provider. However, Daniel Baron, emphasized that significant security obligations remain with the merchant.
“Even in this scenario where the payment functionality has been outsourced, like leveraging for payment iframe from a PCI-validated service provider for payment collection, the referring page still maintains some risk,” Baron said. “That code that is calling the iframe, that code that is performing the redirection, could theoretically be modified by an attacker, and security of that code must be maintained.”
Strategic Implementation Considerations
One of the most complex challenges organizations face is justifying the presence of common third-party tools and services on payment pages. Many tools, such as analytics, marketing tags, and customer experience solutions, serve essential business functions but weren’t designed with payment card security in mind. Organizations must now carefully evaluate whether these tools are necessary specifically on payment pages and whether their presence can be justified given the security risks.
Ron Tosto, illustrated this challenge using a common example with Google Tag Manager, a widely used tool for managing marketing and analytics tags: “If you go back to Google and say, hey, can you prove that Tag Manager is not doing anything [bad] with my payment page? They’re going to say, well, I didn’t design that for payment pages, and I’m not going to justify why you should use it,” Tosto said.
This example highlights a broader challenge: Many widely used third-party services cannot or will not provide the security attestations organizations need to justify their presence on payment pages. Organizations must, therefore, carefully weigh the business benefits of these tools against the security risks and compliance requirements, potentially reconsidering their use on pages where payment information is collected.
Path to Compliance: Looking Ahead
As organizations navigate these new requirements, working with PCI-validated service providers may offer some relief in meeting compliance obligations. Daniel Baron explained how validated service providers could help reduce the compliance burden.
“If the service provider providing some of the scripts or the payment page is a PCI-validated service provider with the valid AOC, an organization can rely on that AOC for the integrity of those components provided by that service provider,” Baron said.
However, KJ Sedjro cautioned against oversimplifying the implementation process. “Even though you may find a way to remediate the problem, it may be even harder than you think,” he said. This warning underscores the importance of thorough planning and realistic resource allocation.
With the Q1 2025 compliance deadline approaching, organizations face mounting pressure to implement these new security controls. The panel’s collective guidance emphasized several critical success factors:
- Begin implementation efforts immediately rather than waiting until closer to the deadline
- Ensure a thorough understanding of the requirement scope, particularly regarding third-party scripts
- Secure appropriate technical expertise, whether internal or through trusted partners
- Plan for ongoing monitoring and maintenance of these security controls
These new client-side security requirements mark a pivotal shift in payment security strategy. They acknowledge that protecting modern web applications requires security controls that extend well beyond traditional server-side protections. Organizations that start early and plan thoroughly will be better positioned to meet both the compliance deadline and the security objectives these requirements aim to achieve.
How SourceDefense Helps Meet PCI DSS 4.0 Requirements
SourceDefense provides a comprehensive Client-Side Security Platform that helps organizations meet the new PCI DSS 4.0 requirements for client-side security. The platform enables organizations to:
- Audit and authorize website scripts: SourceDefense allows organizations to inventory and monitor all scripts running on their payment pages, including those from third-party vendors. This helps meet PCI DSS 4.0 Requirement 6.4.3, which requires an inventory of scripts and their business justification.
- Detect and respond to client-side threats: The platform continuously monitors payment pages for unauthorized changes or suspicious activity. If a threat is detected, SourceDefense can automatically block the malicious script and alert the organization. This helps meet PCI DSS 4.0 Requirement 11.6.1, which requires a change- and tamper-detection mechanism for payment pages.
- Simplify compliance: By providing a centralized platform for client-side security, SourceDefense makes it easier for organizations to understand their script inventory, detect threats, and demonstrate compliance to auditors.
By leveraging SourceDefense’s Client-Side Security Platform, organizations can more easily meet the complex technical requirements of PCI DSS 4.0, protect their customers’ sensitive data, and reduce the risk of costly data breaches.
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.
