SAQ A’s New Eligibility Criteria: More on What It Means

Since my last blog post, I’ve spoken to many of Jscrambler’s customers, potential customers, ISAs, and QSAs about what the changes to SAQ A mean to them. I’ve been following much of the discussion in the many QSA and vendor blog posts, as well as LinkedIn articles. Jscrambler also held its second forum of the QSA Alliance Program on Wednesday, 5th February, on exactly this topic, which was well-attended by a good cross-section of the QSA and ISA communities joining the discussion.

The consensus seems to be - now that the initial confusion has settled down - that we’re in a situation that’s not dissimilar to where we were before these changes. In other words, whatever it was that merchants were doing to meet requirements 6.4.3 and 11.6.1 before these requirements were removed from SAQ A should still see them well in the future to meet the new "Eligibility Criteria".

Wait, what’s been going on?

The PCI Council announced on 30 January that it was releasing an update to SAQ A v4.0.1, which removed requirements 6.4.3, 11.6.1, and 12.3.1. It also added one bullet point to the eligibility criteria, highlighted below:

Additionally, for e-commerce channels:

• 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).

Now, requirements 6.4.3 and 11.6.1 in the original SAQ A v4.0.1 have applicability notes attached to them. They explain that if you accept payments via a full redirect to your PCI DSS-compliant payment service provider, these two requirements don’t apply. If, however, you’re using iframes on your own site, then they apply - after 31 March 2025. However, there’s no such applicability note for the addition of the new eligibility criteria, meaning this new bullet point will apply to all merchants doing SAQ A as soon as it takes effect on 31 March 2025.

There has also been some confusion about some of the words used—what is a “site” in this context? Where did the term “merchant’s e-commerce system(s)” come from? How are they different from a payment page that most merchants will have? Are they different?

Let’s look at those now.

Whose Site Is It Anyway?

tl;dr The reference to “their site” in SAQ A v4.0.1r1 refers to the merchant’s website, not the TPSP’s site.

As a part-time pedant, one of the conversations I’ve followed was a few people suggesting that the word “their” in the eligibility criteria could actually mean the TPSP rather than the merchant. I can absolutely see where they’re coming from - when both bullet points from the eligibility criteria that I quoted above are read together, “their” could mean the TPSP. In fact, the very first time I read the updated Eligibility Criteria, this is how I interpreted it, too.

However, there are a number of places that confirm that the wording can only mean the merchant’s website.

First, the Document Changes for SAQ A v4.0.1r1 states:

Removed Requirements 6.4.3, 11.6.1, and 12.3.1 and added an Eligibility Criteria for merchants to confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).

There’s no mention of the TPSP in that entry - “their” can only mean the merchant. Second, the PCI Council’s blog post announcing the SAQ A changes stated something very similar:

After thorough consideration and review of industry stakeholder feedback, PCI SSC is making the following updates to SAQ A:

• Removal of PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1.

• Addition of an Eligibility Criteria for merchants to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

Again, the PCI Council is clear that it’s the merchant’s site that they’re referencing. Finally, just yesterday, the PCI Council posted on LinkedIn, again writing about this change in a way that can only mean that they’re referencing the merchant and not the TPSP:

After thorough consideration and review of industry stakeholder feedback, #PCISSC is making the following updates to SAQ A:

• Removal of #PCIDSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1.

• Addition of an Eligibility Criteria for merchants to "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

Based on everything the PCI Council has published about its update to SAQ A, the new Eligibility Criteria bullet point can only refer to the merchant’s site, not the TPSP’s site. 

OK, but what is a “site”?

“Site” is used throughout PCI DSS v4.x to describe a physical location, but that doesn’t make sense in this context. The obvious interpretation is that it refers to the merchant’s website, but when we look at the types of attacks PCI DSS protects against, then this could be too broad an interpretation.

There are two common types of web skimming attacks - one is often referred to as “silent skimming”, where the transaction goes through as normal, but the attacker is able to siphon off the data at the same time. In other words, the attack is invisible to the customer and the merchant. The second type of attack is commonly called a “double-entry” attack. Here, an attacker subverts the payment flow to show their own form that captures the payment data on the first attempt. It pretends there’s been an error, and the attacker sends the customer to the real payment page on the second attempt. If you want to read more about this, there’s a recent example that Jscrambler detected on casio.co.uk, which gives a good technical description of how this type of attack works.

On a traditional website, meaning one where a customer goes to make a payment, and the browser loads a full webpage for that purpose, an attacker who is able to inject code on another part of the site is very unlikely to result in silent skimming attacks against the payment page. However, Single Page Applications (SPAs) work differently, and an attacker who can attack the SPA may very well be able to attack the payment area within the SPA, as their script will load early and will stay running within the SPA unless a whole new page is loaded.

Put another way, both types of websites are susceptible to double-entry attacks anywhere. However, silent skimming attacks would only affect traditional websites on the payment page, whereas SPAs would be susceptible to silent skimming attacks across the entire application.

Why does this matter? Well, PCI DSS v4 added requirements 6.4.3 and 11.6.1 and scoped the requirements to apply only to the payment pages rather than the whole site. This strongly suggests that PCI DSS is only really tackling silent skimming attacks. It would be very strange for SAQ A (and SAQ A only) to have significantly stricter eligibility criteria, requiring protection against both types of attack and going beyond what PCI DSS requires. Because of this, it seems to be a fair assumption to say that the PCI Council is referring to parts of the site susceptible to silent skimming attacks only. As websites gain more protection against silent skimming attacks, it’s likely that attackers will focus more on double-entry attacks in the future, and so it’s quite probable that the PCI Council will want to broaden these requirements in the future to cover both attack types.

Of course, by taking my compliance hat off and replacing it with my security hat, double-entry attacks are becoming more prevalent, and if you’re able to extend these protections to the whole site, then your overall security posture will be improved.

What about the “merchant’s e-commerce system(s)”?

Again, it’s not possible to answer definitively, as this is a new term. It’s up to the PCI Council to define this, which, hopefully, they will do soon.

In the meantime, there are only a couple of things it could mean within the context of SAQ A. Given that we know it’s referring to e-commerce merchants, there are only two main ways for this to be implemented: either a full redirect to the TPSP or by loading an iframe provided by the TPSP. Where the merchant has fully outsourced the whole website to a PCI DSS-compliant TPSP, then this could well be referring to the whole site in that case, but it would be defined as part of their PCI DSS scoping efforts and defined as part of the agreement in place between the merchant and TPSP as part of Requirement 12.8 instead.

In the case of a full redirect, the merchant’s payment page is hosted entirely by the TPSP, so this is probably meant as a broader term that covers both the merchant’s payment page containing iframes or the mechanism used to redirect to the TPSP.

Why has this changed, and why now?

Ultimately, it’s very difficult to answer why the PCI Council made this change. In the previously mentioned blog post announcing the change, the PCI Council stated that it was based on “thorough consideration and review of industry stakeholder feedback.” However, unlike an RFC, where the Council shares all the feedback with other RFC participants, this hasn’t gone through the RFC process, so the PCI Council hasn’t shared what feedback caused this change.

Normally, changes to the standard require a substantial implementation period. For future-dated requirements that were added to PCI DSS v4, these new requirements were published in March 2022, and they became best practices for three whole years before they became requirements.

However, the SAQs are not the standard.

While it’s the PCI Council, through its Technical Working Group, that creates the PCI DSS requirements and determines with input from participants which requirements should go into which SAQ, the SAQs are ultimately compliance documents. That means the PCI Council should be able to explain what the words in their documents mean, but it’s then up to each payment brand (and, in turn, each acquirer or compliance-enforcing entity) to determine which entities are required to complete SAQs, and how they might apply to entities required to complete them.

I don’t know why now, either. Unless the Council publishes the feedback it received (and I have no expectation that it will), we’ll never know why it made these changes a mere two months before the requirements were due to come into effect.

What does this mean for merchants who were previously eligible for SAQ A?

Given that the new Eligibility Criteria set criteria that are very similar to requirements 6.4.3 and 11.6.1, it would be fair to expect that if you were previously planning to meet those requirements, continuing on your current path should allow you to meet the new Eligibility Criteria, too. If the Council expected this to have much impact, then I would have expected them to have given entities years rather than months to respond.

However, if you believe that the broadening of “payment page” to “site” might impact you, then a good first step would be to contact your QSA and get their interpretation. We’ve heard differing opinions from the QSAs we’ve spoken to so far on the term “site”, but to date, all those QSAs we’ve spoken to who have given an opinion have agreed that any method used to meet requirements 6.4.3 and 11.6.1, when applied to the payment page or whole website as necessary, should meet the intent of the new Eligibility Criteria, based on everything published to date. Either way, the advice I get from others, and the advice from Jscrambler, can best be summed up as “stay the course.”

Finally, if you’re a Jscrambler customer or potential customer and believe this change could impact your business, please get in touch. We’ll be happy to discuss it with you in more detail.