PCI DSS SAQ A Eligibility Changes: Why Security Should Outweigh Compliance Checklists
When the PCI Security Standards Council (PCI SSC) updated SAQ A’s eligibility criteria in January 2025, they removed requirements 6.4.3 and 11.6.1 for merchants for SAQ-A if they meet two additional requirements, namely:
“All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.”
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
On paper, this reduces compliance overhead. But is it really that simple?
In our recent webinar, we explored how the security realities behind these requirements haven’t changed, and how ignoring them risks breaches.
The Rules That Vanished (But Didn’t)
Requirements 6.4.3 and 11.6.1 weren’t arbitrary. They addressed two critical threats:
- Script Hijacking: Magecart-style attacks injecting malicious code into payment pages.
- Header Tampering: Attackers disabling security protocols like HTTP Strict Transport Security (HSTS).
High-profile breaches—British Airways ($26M fine in 2018) and Ticketmaster (2023)—stemmed from unsecured third-party scripts. The PCI SSC initially responded with 6.4.3 (script inventory and authorization) and 11.6.1 (continuous monitoring).
But under SAQ A’s new criteria, merchants using iframes need only confirm their systems aren’t “susceptible to attacks originating from scripts loaded on their sites.” Compliance now hinges on a checkbox, not active safeguards.
Why This Change Creates False Confidence
1. Third-Party Trust isn’t Absolute
Third-party trust in PCI compliance has inherent limitations, as emphasized by Lindsay’s “school bus” analogy in the webinar: iframe providers only secure users once they reach their domain, disclaiming liability for vulnerabilities before that point.
For example, a hijacked “Pay Now” button (hosted on the merchant’s site) could redirect users to malicious pages before reaching the secure iframe.
This pre-iframe attack vector leaves merchants fully liable, even if the third-party iframe itself remains uncompromised.
As Lindsay explained, attackers increasingly exploit these gaps: A 2024 study found 46% of e-skimming attacks occurred on pages hosting or redirecting to iframes.
Compliance with SAQ A might reduce audit scope but it doesn’t eliminate risks like brand damage or forensic costs when breaches occur on the merchant’s domain.
Thomas noted that attackers may target SAQ A organizations as “low-hanging fruit,” exploiting complacency post-compliance changes. Merchants must recognize that third-party validation covers their environment, not the entire customer journey.
Proactive measures like tamper detection for pre-iframe elements (e.g., buttons, headers) remain critical, as attackers “don’t care about your SAQ level—they exploit gaps wherever they exist” (Vivek).
2. Attackers Follow the Path of Least Resistance
SAQ A merchants often become prime targets for attackers despite their PCI compliance status, thanks to perceived vulnerabilities created by SAQ A’s narrowed scope.
Cyberattackers may focus on SAQ A merchants in the following ways:
Targeting Outsourcing Reliance
SAQ A merchants outsource payment flows to iframes/redirects, creating a false sense of security. Attackers exploit this by focusing on pre-iframe attack surfaces, such as hijacked "Pay Now" buttons (hosted on the merchant’s domain) that redirect users to malicious pages before reaching the secure iframe or compromised third-party scripts (e.g., chatbots, analytics tools) injected into merchant-hosted pages.
A 2024 SANS Institute study found 46% of e-skimming attacks occurred on pages hosting or redirecting to iframes, underscoring attackers’ focus on these weak points.
Exploiting Reduced Monitoring Mandates
SAQ A no longer requires 6.4.3 (script integrity checks) or 11.6.1 (continuous monitoring), creating gaps attackers can exploit using conditional malware or backdoors.
For example, with conditional malware, they may deploy scripts that activate only when security sensors (e.g., browser plugins) are absent, evading detection. Likewise, they can find potential gaps in third-party tools to create backdoors into your system.
Leveraging Third-Party Liability Gaps
While SAQ A shifts compliance responsibility to iframe providers, attackers focus on pre-iframe vulnerabilities for which merchants remain liable. For example, a hijacked redirect or tampered landing page tarnishes the merchant’s reputation, even if the iframe itself is secure.
3. Regulatory Uncertainty Looms
Likewise, SAQ A’s updated requirement—to confirm systems are “not susceptible to attacks originating from scripts loaded on their sites”—lacks clear technical benchmarks.
Finally, while SAQ A seemingly shifts compliance responsibility to iframe providers, pre-iframe vulnerabilities (e.g., hijacked “Pay Now” buttons) remain the merchant’s liability.
CSPs and SRI Tags Aren’t Enough
During the webinar, Vivek and Lindsay discussed CSPs and SRI tags. While these provide value as a starting point, they’re not enough for modern e-commerce environments.
CSPs, designed to restrict unauthorized script execution by whitelisting trusted domains, can help block malicious code injections. However, Vivek highlighted some key limitations of CSPs, namely, that they aren’t optimal when dealing with dynamic scripts.
For example, frequent updates to third-party scripts (e.g., payment gateways or analytics tools) force merchants to constantly revise policies, creating operational friction.
Worse, CSPs cannot detect script behavior changes within approved domains. For example, a compromised Google Tag Manager script would bypass CSP checks entirely.
SRI tags, which validate script integrity via cryptographic hashes, offer a starting point, but, again, they’re not optimal for today’s e-commerce systems.
Vivek noted that SRI requires "dynamic generation of checksums" for every script update, a burdensome process for merchants using third-party services outside their control (such as payment processors updating scripts without notice).
This makes SRI "highly impractical" in real-world scenarios where scripts evolve frequently.
Additionally, neither CSPs nor SRI address Requirement 11.6.1’s mandate for alerting on unauthorized changes—SRI lacks monitoring capabilities, and CSPs only trigger alerts if policies are violated, not if approved scripts are tampered with.
Overall, Vivek noted, “CSP and SRI are foundational, but without real-time monitoring, you’re leaving visibility gaps attackers exploit.” In other words, they provide a start, but you need to build upon them with solutions specifically designed to fully support 6.4.3 and 11.6.1
Two Paths Forward
Option 1: Tamper Detection and Integrity Monitoring
This option focuses on ensuring that all scripts and content delivered to consumer browsers are authorized and maintain integrity, even in the absence of explicit compliance mandates for SAQ A merchants.
As Vivek explained, DataStealth’s solution operates in-line with traffic, scanning all scripts on payment pages to create an inventory of authorized content. If content matches the approved inventory, it is allowed to proceed; if not, the system can block specific scripts or entire pages based on their criticality to the transaction.
This approach ensures that unauthorized changes—such as malicious code injections—are detected and mitigated before they can impact consumers or compromise sensitive data.
This meets SAQ A’s new eligibility criteria while layering defences against e-skimming. The solution is particularly beneficial for merchants who want to maintain SAQ A eligibility without making significant changes to their payment environment.
By layering real-time tamper detection with existing security frameworks like CSPs and SRIs, DataStealth provides a minimally invasive yet robust defence against e-skimming attacks and Magecart-style breaches.
The managed service aspect of this solution also reduces operational burdens for merchants by filtering out false positives and surfacing only critical alerts that require immediate action.
Ultimately, this option is ideal for merchants who want to prioritize security by ensuring that their website and customer data are properly protected. This fully addresses the need to comply with PCI DSS 6.4.3 and 11.6.1 and helps shield merchants from increasingly capable attackers.
It not only protects consumers during online transactions but also helps merchants confirm that their site is not susceptible to attacks originating from scripts—aligning with SAQ A’s updated eligibility criteria while ensuring a secure user experience.
Option 2: Secure Payment Form Injection
This option involves outsourcing the collection and processing of payment card data entirely to a third-party service provider, such as DataStealth, which injects a secure, tamper-proof payment form directly into the merchant’s checkout page.
This method ensures that sensitive cardholder data never enters the merchant’s systems. Instead, the data is tokenized at the edge—before it reaches the merchant environment—and securely transmitted to payment processors.
This approach drastically reduces the scope of a merchant’s Cardholder Data Environment (CDE) and can help organizations achieve or maintain SAQ A eligibility.
The injected payment form is delivered via JavaScript and rendered in an iframe on the consumer’s browser.
Unlike traditional iframe implementations, DataStealth’s solution includes tamper detection and protection mechanisms to ensure that the injected content remains secure from e-skimming or Magecart attacks.
By operating in-line with payment traffic, DataStealth validates all scripts and content being delivered to browsers, blocking unauthorized changes in real-time.
This combination of tokenization and integrity monitoring addresses vulnerabilities in pre-iframe elements, such as hijacked “Pay Now” buttons or malicious redirects, which are common attack vectors for SAQ A merchants.
As Lindsay noted, this solution not only streamlines compliance but DataStealth also provides merchants with an Attestation of Compliance (AOC) and RACI to simplify audits.
Ultimately, Secure Payment Form Injection is ideal for organizations seeking to minimize compliance costs, reduce the number of tools required for payment processing, and maintain a consistent brand experience.
By eliminating raw cardholder data from their systems and securing all content delivered to consumer browsers, merchants can significantly lower their risk of breaches while meeting PCI DSS requirements.
This solution is particularly beneficial for those re-evaluating their current iframe setups or looking to adopt a more secure and streamlined approach to payment processing.
The Bottom Line
SAQ A’s changes reflect PCI SSC’s evolving threat awareness but create a dangerous paradox: compliance no longer mandates the very controls that protect against today’s top threats.
As Lindsay Kleuskens, Account Executive at DataStealth, concluded:
“Merchants face a choice: treat compliance as the ceiling or the floor. We’ve seen what happens when it’s the ceiling—breaches, fines, lost trust. The floor is where security lives.”
Top Audience Questions
1. Are Subresource Integrity (SRI) tags sufficient to meet SAQ A’s new eligibility criteria?
No, SRI tags alone are not sufficient.
While SRI is a useful tool for validating the integrity of scripts via cryptographic hashes, it lacks alerting capabilities when unauthorized changes occur, which is a critical aspect of Requirement 11.6.1. Additionally, SRI is impractical for dynamic environments where scripts frequently change, especially third-party scripts outside the merchant’s control.
2. What SAQ should a merchant complete if they cannot confirm their site is not susceptible to attacks?
If a merchant cannot confirm their e-commerce system is not susceptible to attacks originating from scripts loaded on their site, they must default to SAQ A-EP.
This shift significantly increases the compliance burden, as SAQ A-EP includes approximately 151 requirements compared to SAQ A’s 31. However, this step ensures the merchant meets requirements 6.4.3 and 11.6.1 when they cannot satisfy the new eligibility criteria for SAQ A.
3. If an e-commerce process is fully outsourced to a PCI-compliant third-party provider, does the merchant need to do anything?
It depends on the setup:
If the entire e-commerce experience (including checkout) is hosted by the third-party provider, the merchant has no additional responsibilities under PCI DSS requirements for that process.
However, if the merchant hosts any part of the user journey—such as a “Pay Now” button redirecting users to the third-party provider—they are responsible for securing those elements (e.g., preventing hijacked redirects).
While this may not always be a compliance requirement under SAQ A, it remains a critical security best practice to protect against reputational damage in case of an attack.
4. Are merchants responsible for PCI compliance when using third-party iframes or redirects?
Merchants are responsible for securing any parent pages hosting third-party iframes or redirects (e.g., ensuring “Pay Now” buttons are not hijacked).
However, once users enter the iframe or are redirected to the third-party provider’s domain, responsibility shifts entirely to the provider, who must demonstrate compliance through an Attestation of Compliance (AOC).
Merchants should still implement measures like tamper detection on pre-iframe elements to prevent reputational damage from breaches originating on their site.
Next Steps
Ultimately, every business’ challenges and needs are unique. The best way to start addressing your PCI DSS compliance needs, be it requirements 6.4.3/11.6.1 or reducing audit scope, is to get experts to examine your system and build a tailored solution.
Reach out to our team to get the ball rolling today!
