by Source Defense
On a recent Source Defense roundtable, seasoned QSAs gathered to discuss the latest PCI DSS 4.0.1 updates—specifically requirements 6.4.3 and 11.6.1—and how organizations should respond. What followed was a frank, practical, and sometimes surprising conversation about merchant eligibility, the limits of iframe protection, and what compliance now looks like in an eSkimming-threatened landscape.
Here are the key takeaways from the conversation.
Understanding the SAQ-A Changes
A key topic addressed during our roundtable was the recent modification to SAQ-A eligibility requirements. While the change might appear to simplify compliance for some merchants, our experts emphasized that the fundamentals remain largely unchanged.
“Ultimately, the council themselves have said that easiest, best way to meet that eligibility criteria is to enact 6.4.3, and 11.6.1,” said Lee Quinton, Compliance Practice Manager at TrustedSec. “The easiest and best way to meet that eligibility criteria is to enact 6.4.3 and 11.6.1.”
Ty Huelle, Technical Manager at Optiv, reinforced this perspective, warning merchants against trying to navigate compliance without proper tools: “You want to stay out of that gray area. And personally, I haven’t seen anything without a tool intervention. You have to have some level of Integrity monitoring going on in order to meet, 6.4.3. and 11.6.1., so getting the tools that are built for it is the ideal.”
The Deadline Has Passed – What Now?
The panel also addressed a common misconception: that organizations still have time to implement these controls. In reality, April 1, 2025 marked the enforcement deadline.
“This train has come and gone,” said Robert Davidson, National Practice Lead at Level Blue. “You were expected to have these controls in place before your next assessment after April 1.” Quentin added, “If you said you were going to do it monthly, then show me. It’s not enough to say you’re planning to get compliant. You need the logs, the reports, and the policies.”
The Scope Has Gone From ‘Page’ to ‘Site’
A recurring theme throughout the discussion was how the scope of compliance has expanded. Several panelists noted the use of the word “site” in the revised documentation, as opposed to “page.”
As Art “Coop” Cooper, Principal Security Consultant at TrustedSec explained: “From the council’s perspective, if any part of your site can host or load a payment form—even dynamically—then it’s in scope. That includes single-page applications and parent pages with iframes.”
Davidson agreed: “If you’re an attacker and you’re in a single-page application, you’re in every single interaction that ever happens in the cross of that application. You only need to hook it once.”
The Challenge of Single Page Applications
Modern web development practices, particularly Single Page Applications (SPAs), present unique challenges for PCI DSS compliance. As our Source Defense expert Matt McGuirk pointed out: “If you have one page that is the entire application, guess what? The whole thing’s in scope now.”
“Single page apps for the purposes of PCI do not make things easier. They make it incredibly difficult, especially if you provide a lot of external references,” added Davidson.
Why Manual Approaches Fall Short
A recurring theme throughout the discussion was the impracticality of manual approaches to meeting requirements 6.4.3 and 11.6.1. The complexity of modern websites, with their numerous third and fourth-party scripts, makes manual tracking virtually impossible.
“Pick the tool though that helps you that recognizes what a lot of these common scripts are from Google and analytics and stuff,” Huelle emphasized. “And that tool says, ‘Hey, we’ve seen this so much with all our customers, we can tell you what this is,’ instead of you going out and figuring it out what it is, because let them use their intelligence that’s baked into their tool.”
He further elaborated on what QSAs expect to see from mature organizations: “You want something that’s going to go give a severity rating on it. Say, ‘Hey, this could be threatening.’ Or, ‘Oh, your privacy data is leaving, you know, you might want to do something about that,’ or, ‘Oh, this is pretty safe. This is normal communication chatter.’ That’s what you want out of your tool that’s doing this for you, and you need to show that level of maturity to a QSA.”
The Historical Context: Why These Requirements Matter
The roundtable experts provided valuable context on why these requirements were introduced in the first place. “That’s the history of the time, right? We have to look at when this was written… Magecart was everywhere. It was hitting the news, it was hitting the media. It was hitting, you know, individual sites. You know, hundreds, thousands of sites were impacted,” explained Davidson.
“Any wonder, really, if we’ve just stepped back to the previous version of SAQ-A, virtually no detective controls, defensive controls were pretty much on their ass,” Quinton said. “And you own that, you own that web server that’s controlling the entrance to the iframe or the redirect. Thank you very much. Man in the middle, all day long.”
Finding a Trusted Solution
For merchants navigating the complex landscape of eSkimming security solutions, our panel offered guidance on how to evaluate and select the right vendor. While maintaining their vendor-neutral stance as QSAs, they emphasized the importance of working with established, proven solutions.
“I can honestly say every customer that I know that is using Source defense is a happy customer that I’ve worked with,” noted Huelle.
Conclusion: Time to Act Is Now
As our roundtable concluded, the message was clear: organizations can no longer delay implementing robust eSkimming security measures. The deadline has passed, the requirements are in effect, and the potential consequences of non-compliance are significant.
“Please don’t wait, because I have clients working at least the last year on this stuff, right? Going through all of their, you know, payment pages, all their scripts,” emphasized Davidson.
Source Defense provides industry-leading solutions designed specifically to address these requirements with minimal implementation effort and management overhead. Our platform offers comprehensive script monitoring, automatic policy enforcement, and protection against eSkimming attacks – helping you achieve compliance while safeguarding your customers’ sensitive information.
For more information on how Source Defense can help you meet PCI DSS 4.0 requirements 6.4.3 and 11.6.1, request a demo today. View the full webinar recording here.
Source Defense is a Principal Participating Organization with the PCI Security Standards Council and the pioneer in eSkimming security. We’ve helped thousands of the world’s leading brands address these issues and continue to educate merchants, QSAs, and stakeholders about the vulnerabilities in modern website design that make eSkimming attacks possible.
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.
