Category: Compliance Enforcement

When you’re watching your favorite show on Netflix, chances are you’re worrying more about plot twists and character development than what’s happening behind the scenes to make sure that content is being delivered at its highest quality and not being hijacked for distribution on another platform by someone who didn’t pay for it.

But these are the exact issues that face companies like Netflix, Spotify, Amazon Prime Video, Disney+, Hulu, and other content-streaming providers, which have a unique challenge to both create and support valuable and high-quality content that people want to watch and that they can monetize, while also protecting it from illegal reproduction or piracy once it’s in the public domain.

These companies want to ensure that loyal clients who pay for their subscriptions are the only ones who can access their premium content, and that their streams are not interrupted by performance issues or other barriers to delivering the best possible user experience. 

Digital media streamers also aim to capitalize on the opportunities that come with having exclusive access to live sporting events — such as the Olympic Games, a boxing match, or Formula One races — and provide viewers with high-quality, low-latency streams without glitches, ensuring they don’t miss any of the action.

Protecting Streamers’ Value Proposition 

Jscrambler offers a unique proposition to the media-streaming services industry by providing client-side protection to help address the challenges they face in protecting their digital intellectual property (IP). Even if threat actors crack a content’s digital rights management (DRM) technology or try to scrape content for illegal redistribution, they still can’t hijack content when it’s running on a client-side application or browser protected by Jscrambler. 

This assurance protects media companies from loss of revenue that occurs when attackers steal valuable IP and content, reverse-engineer streaming platforms, bypass watermarking, or re-distribute proprietary content.

Indeed, for digital media content providers across the board, these threats to digital media, whether it be a recurring stream or a one-time-only live broadcast, at their core represent “an economic problem,” says Rui Ribeiro, Jscrambler co-founder and CEO.

The global video streaming market was valued at US$674.25 billion in 2024, and is projected to grow 18.5% to US$2,660.88 billion by 2032. Music streaming, meanwhile, is forecasted to grow 21% from US$36.7 billion in 2023 to US$125.70 billion by 2032. 

In the US alone, 83% of all households subscribe to at least one streaming service, with Netflix (over 260 million subscribers), Amazon Prime Video (over 168.3 million subscribers), and Disney+ (over 157 million subscribers) representing the largest share of the subscriber market.

The Fundamentals of Digital Media Protection

Keeping streamers happy depends on two fundamental factors, Ribeiro says: “protecting their content from theft or unauthorized distribution, and maintaining high quality of their output by reducing the latency of streamed content.” 

These factors are especially important to real-time streams of sporting and other live events, where advertisers and other sponsors provide financial support for streamed events. Their support is based on assurances that their content will be shown on proprietary, not hijacked, streams that eliminate their sponsored content. Even a short delay or glitch in a stream can destroy the value of a live event and thus the quality of the service, he says.

“The challenge is: how can you protect this type of content in a way that’s easy for the user but doesn’t have any latency,” Ribeiro says. “We help them because we can provide them with applications that have a lot of integrity, verifications, and monitoring.”

Jscrambler’s client-side protection provides security for content creators and streamers by protecting the IP, streaming player, and the ad revenue running inside it with runtime code protection that provides self-defensive capabilities. This enables applications to detect and react in real-time to any tampering, debugging, or poisoning attempts by entities attempting to modify the content or stream.

It also prevents piracy by making it harder to crack into a streaming provider’s video player and protecting any fingerprinting or watermarking technologies within it, thus blocking any unauthorized access to streaming apps.

“[Jscrambler’s solution] is good for both the end user and for the company providing the service because it’s tough to provide fake applications that could be compromising the end users,” Ribeiro says. “These come from a strong application protection with integrity verification.”

Meeting the Streamers’ Fundamental Needs

Another competitive edge that Jscrambler’s client-side protection offers comes from a technology it pioneered: advanced polymorphic JavaScript obfuscation. In fact, this technology was one of the main reasons Powtoon, a video and visual communication platform provider, chose Jscrambler to protect its software, which enables users to create cutting-edge video presentations.

Powtoon needed to protect its competitive advantage when its technology became subject to copycats, with competitive clones stealing the company’s graphical assets. The company wanted to protect these assets with client-side protection that would prevent theft of their proprietary technology. 

Powtoon’s implementation of Jscrambler is a real-world example of Ribeiro’s description of the two key needs of content-streaming providers: trusted protection and high performance.

Powtoon found Jscrambler’s polymorphic JavaScript obfuscation, which uniquely protects JavaScript code, not only comprehensive, but also customizable to their platform’s needs. The company also utilized the Jscrambler Client-Side Protection Platform to ensure that attackers can’t reverse-engineer their code or circumvent licensing restrictions, thereby preventing the hijacking of valuable IP.

“Most importantly, the use of Jscrambler’s client-side protection didn’t slow down their technology, maintaining the delicate balance between protecting Powtoon’s IP while preserving the quality of performance”, said Sven Hoffmann, CTO and co-founder at Powtoon.

“If I had to summarize the benefits of the Jscrambler product in one sentence, I would say it’s state-of-the-art code protection and negligible performance impact,” he said.

Providing these two key assurances for digital media and streaming providers enables them to focus on what they do best — delivering premium video and audio content that their subscribers eagerly consume — while having confidence in Jscrambler to protect their digital assets from hijacking or unauthorized redistribution.

1. Andrew, how does your role at Elavon EU shape payment security strategies to help merchants meet PCI DSS requirements 6.4.3 and 11.6.1?

My role at Elavon involves designing security frameworks that ensure merchants align with PCI DSS 6.4.3 and 11.6.1, safeguarding payment environments, and enabling our merchants to have direct access to best-in-class solutions with partners like Jscrambler. My goal is to help merchants become compliant with minimal disruption to their daily activities. 

As part of this process, I collaborate with teams to provide tools and guidance, helping merchants navigate complex compliance requirements efficiently across all aspects of the PCI process. I also drive strategies to address emerging threats like web skimming, ensuring merchants stay ahead of risks and deadlines.

2. What are the biggest hurdles merchants face in complying with PCI DSS 6.4.3 and 11.6.1, particularly in preventing web skimming attacks?

Merchants struggle with implementing script management and monitoring required by 6.4.3 and 11.6.1 due to limited resources and technical expertise. With the update to PCI 4 many merchants are unaware of changes they may be affected by or are hesitant to kick over that rock and find they have additional requirements. I strive to offer solutions, not problems, to our merchants to help them comply with best practices around data security. 

We’ve also seen a surge in web skimming attacks that have overwhelmed merchants lacking real-time detection capabilities. Small to mid-sized merchants often lack the budget or staff to maintain continuous compliance and threat monitoring.

3. Why is anti-skimming protection a critical priority for merchants today, given the surge in web skimming attacks?

The increase in Magecart attacks targeting payment pages risks data breaches and financial losses for our merchant customers. In addition, PCI DSS 6.4.3 and 11.6.1, effective as of March 31, 2025, now require robust anti-skimming measures to avoid penalties. Protecting payment pages from skimming ensures customer confidence, which is critical for merchants’ reputation and revenue. This will help our merchants avoid costly data breaches and subsequent scheme fines. 

4. How essential is client-side protection for securing payment pages against web skimming in a merchant’s overall security strategy?

Client-side protection is vital to monitoring and blocking malicious scripts on payment pages, where skimming attacks occur. It assists the merchant by taking another aspect of security out of their scope and is managed by third-party professionals. 

It also strengthens overall security by addressing vulnerabilities that server-side measures alone cannot cover. An effective client-side protection implementation will ensure compliance with PCI DSS 6.4.3, safeguarding merchants against non-compliance risks.

5. How does the Elavon EU-Jscrambler partnership empower over 400 merchants to meet PCI DSS 6.4.3 and 11.6.1 requirements and combat escalating web skimming threats?

Elavon’s payment processing knowledge and Jscrambler’s client-side security solutions equip Elavon’s 400 merchants to tackle the surge in skimming attacks. We pride ourselves on offering our merchants bespoke solutions to their Data Security issues, regardless of the size of the merchant. We see PCI compliance as a collaboration with our merchants and partners that helps protect them and ourselves from the ever-evolving threat to card security. 

The partnership with Jscrambler offers practical, scalable strategies to ensure merchants meet PCI DSS deadlines and secure payment pages effectively.

We have a lot more to share about our partnership. It’s important that our merchants attend the Mastering PCI DSS Requirements 6.4.3 and 11.6.1: Practical Solutions for Merchant Compliance webinar on May 20, 2025, to see how our partnership supports merchants on their compliance journey. 

On 28 February 2025, the PCI SSC released FAQ 1588 to clarify the new eligibility criterion in SAQ A for e-commerce merchants. In particular, the FAQ aims to clarify how a merchant can “confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

“The merchant can confirm that the merchant’s webpage is not susceptible to script attacks by either:

Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.

Or

Obtaining confirmation from the merchant’s PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.”

FAQ 1588

The FAQ, therefore, clarifies that merchants can meet the eligibility criterion and confirm that their webpage is not susceptible to attacks in one of two ways. 

Either

• by deploying controls like 6.4.3 and 11.6.1 that prevent and detect script attacks,
  
  or 
  
  

• by obtaining confirmation from providers of the iframed/embedded payment page that their solution protects the merchant’s payment page from malicious script-based attacks.

Given the unclear wording of the eligibility criterion this is potentially a helpful clarification. 

The first option validates Jscrambler’s position that implementing controls to manage and mitigate the risk of malicious JavaScript in the parent page is the best way to ensure that a merchant meets the eligibility criterion that “their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” 

What’s also encouraging is that the Council has specified “techniques such as but not limited to …” which means that merchants can choose to meet requirements 6.4.3 and 11.6.1 as they are written, or they could deploy something like Jscrambler’s Iframe Hardening and Webpage Integrity to the parent page which will protect the iframe integration from attacks while not having the same compliance overhead (authorize, inventory and justify) of requirement 6.4.3.

The second option, of obtaining confirmation from the TPSP/payment processor that their iframed payment page is not susceptible to attacks, is intriguing. We understand what the Council is trying to accomplish here, especially in respect of smaller merchants. However, we’ve seen many viable attacks launched from the parent page against TPSP’s iframe solutions. Jscrambler’s CTO, Pedro Fortuna, demonstrated such attacks at the PCI Community Meeting last year.

 It will be interesting to see:

• The extent to which TPSPs are prepared to provide such a confirmation.

• What these techniques that protect the merchant’s page are, whether they really exist, and how have they been validated?

• Whether the legal, risk, and information security departments of risk-mature merchants are willing to rely on such a confirmation without it being backed up by contractual clauses and associated warranties.
  

It should also be noted that, once again, the PCI SSC drafting is debatable. The second option to confirm non-susceptibility refers to “the merchant’s payment page.” In this architecture, the merchant does not have a Payment Page based on the PCI DSS glossary definition: the Payment Page comes from the TPSP/payment processor, not the merchant and it is embedded in the merchant’s non-payment page.

We’re assuming that the FAQ meant to say something like “the TPSP/Payment Processor’s Payment Page(s) in the iframe within merchant’s non-payment page” — although I admit that while this is technically accurate, and is consistent with the PCI DSS glossary, it is incredibly dense!

If I was still working for a brand and had input into how these things were worded, I’d have said:

(The merchant) Obtains documented confirmation from the TPSP/payment processor which provides the embedded payment page/form(s) that, when implemented according to the TPSP’s instructions, cardholder data intended to be captured by the TPSP/payment processor cannot be accessed by scripts executing in same execution context of the page(s) on the merchant’s website that include(s) the embedded payment page/form(s).

Which again is a bit dense but more represents the threat that we’re all trying to protect against.

SAQ A Clarifications and New Questions

To say that it isn’t ideal that the SSC removed two requirements from SAQ A just two months before they became applicable — and then replaced them with an inelegantly worded eligibility criterion — is an understatement. 

This FAQ goes a long way to clarify that eligibility criterion but asks new questions. 

• Firstly the degree to which TPSPs/Payment Processors will be prepared to offer the confirmation of non-susceptibility to attacks that merchants will demand. 

• Secondly, whether the underlying technical techniques actually work.

• And finally what form of confirmation will be sufficiently robust to allow risk-mature merchants to accept it.

When the revised SAQ A came out, Jscrambler advocated that meeting requirements 6.4.3 and 11.6.1 was the best way to confirm that the merchant’s site was not susceptible to attacks from scripts. FAQ 1588 has now clearly validated that approach. If you are already in the process of implementing tools such as Jscrambler’s Webpage Integrity to meet requirements 6.4.3 and 11.6.1, your safest approach is to continue on this path. 

If you are still considering your options, starting a discussion with your TPSP/payment processor and with your own internal risk and legal teams should be carried out alongside a review of the technical solutions open to you. 

My final thought is that taking the second option of just relying on the TPSP or payment processor is a real example of working out if you only want to be compliant, or whether you actually want to secure your customers’ payment card data?

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.

Unless entities have measures in place to protect their site, not just their payment pages, it is unlikely that they will be able to use SAQ A from 31 March 2025.

SAQ A v4.0.1 is Dead! Long Live SAQ A v4.0.1!

On Thursday, 30 January 2025, PCI SSC published an update to SAQ A 4.0.1, which is available in the PCI SSC Document Library. This means there are two slightly different SAQs, both with the same name, with only a publication date and revision number to differentiate them.

According to the PCI Council’s blog post about the update, SAQ A v4.0.1 published in October 2024, is valid until 31 March 2025. SAQ A v4.0.1 published in January 2025, is valid from 31 March 2025.

To keep things simple, I’ll refer to them as “current SAQ A” to refer to the October 2024 version, and “future SAQ A” to refer to the January 2025 version from now on.

What’s in a version number?

Historically, PCI standard updates which have kept the same version number have simply reflected changes to requirements that were previously best practices until a certain date which, due to the passage of time, have now become requirements. For example, when future-dated requirements in PCI DSS v3.2.1 – published in May 2018 – became full requirements in September 2022, the PCI Council published PCI DSS v3.2.1r1 at the same time and removed all references to the requirements being future-dated. However, in this update, PCI SSC has made some more substantive changes despite keeping the same version number.

Before I jump into this analysis, I want to highlight this sentence from the PCI Council’s blog post:
“Organizations must consult with their compliance enforcing entity if they have questions regarding PCI DSS compliance validation requirements or the applicable validation tools that they may be eligible to use.”

In other words, while it’s the PCI Council that’s written future SAQ A, it’s ultimately up to the Compliance Enforcing Entity (CEE) how they accept interpretations of them, although they’ll often rely on a QSA’s interpretation when making their final determination. 

What’s changed?

The most obvious change is the removal of requirements 6.4.3, 11.6.1, and 12.3.1 from the future SAQ A requirements. As a refresher, requirements 6.4.3 and 11.6.1 were added to  PCI DSS in version 4 to help prevent certain types of web skimming attacks, and requirement 12.3.1 is the Targeted Risk Assessment requirement, which is only referenced in requirement 11.6.1 in the current SAQ A. If 11.6.1 is removed, it makes sense to remove 12.3.1 too. However, the Council has added new eligibility criteria to future SAQ A, which seems much broader than the requirements being removed from current SAQ A. The new criteria read as follows:
The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).

Requirements 6.4.3 and 11.6.1 apply to the payment pages, but these new eligibility criteria apply to the whole site. I know from previous experience that the Council puts a huge amount of effort into the words it chooses, so this increase in scope can only be assumed to be deliberate.

Following this through logically, if a merchant is planning to continue using SAQ A in the future, they will now need to ensure that the way they protect against script-originated attacks covers the whole site and not just the payment page. If they can’t do this, they won’t meet the new eligibility criteria, and so they’ll likely need to complete SAQ A-EP instead. This would be a huge uplift, going from 27 applicable requirements in future SAQ A, up to 151 requirements and sub-requirements in SAQ A-EP.

SAQ A merchants typically outsource their payment processing either by redirecting to a TPSP or by embedding a payment form in an iframe. It’s this redirection or iframe embedding that the merchant needs to be able to confirm isn’t susceptible to an attack from another JavaScript  – whether that’s a first- or third-party JavaScript.

There will be many different ways a merchant can consider being effective for them to be able to make that confirmation. It could be as simple as having no scripts on their site, or ensuring that all scripts came from validated PCI DSS compliant service providers, or (and you might find this strange) implementing the types of controls that are in requirements 6.4.3 and 11.6.1. Of course, we’d suggest that implementing Jscrambler’s Webpage Integrity would be a preferred solution.

When does this become effective, exactly?

This should be an easy one to answer, but… it’s complicated. PCI DSS says that the new requirements are best practices until 31 March, after which they become requirements, whereas this SAQ is valid from 31 March, rather than after 31 March. My best guess is that this is a simple mistake and the Council meant to align the dates, but unless that gets clarified, if you happen to be sending in an SAQ on March 31, it may be better to submit before that date using the current October 2024 version of SAQ A, or after it using the future version of SAQ A, to avoid any potential confusion.

What about merchants completing an On-site Assessment & Report on Compliance?

FAQ 1331 is probably familiar to most assessors, as it allows merchants to potentially reduce the number of applicable requirements of their on-site assessment significantly, provided they meet all the eligibility criteria of one of the SAQs. This means any on-site assessment from 31 March relying on FAQ 1331 and the SAQ eligibility criteria, will need to use the updated eligibility criteria that apply at that point in time. This would also apply to assessments that have already begun, that are scheduled to complete after that switch-over date. Merchants that previously expected to only need a solution for their parent pages that included an embedded TPSP’s iframe, now need a solution that covers their whole site to be able to meet the revised eligibility criteria.

It’s important to remember that requirements 6.4.3 and 11.6.1 were published as best practices in PCI DSS v4.0 on March 31st, 2022, and merchants have used those 3 years to plan, budget, and implement those new requirements to protect against attacks from malicious scripts. Given the relatively last-minute nature of this update, the safest path for a merchant is to understand how the protection they had put in place to secure the parent page can now be applied to their whole site, and validate with their assessor that this would allow them to meet the new eligibility criteria.

And for the future? Where requirements 6.4.3 and 11.6.1 are already in place, but the future SAQ A eligibility criteria are not met, the merchant, with support and guidance from their assessor, can determine which PCI DSS requirements are applicable. If they previously met the eligibility criteria for current SAQ A, then the applicable requirements could reasonably be expected to be fairly similar to those in the future SAQ A, but expanded to cover the whole site.

Jscrambler is here to help. For ISAs and QSAs please join the QSA Alliance Program to gain access to additional SAQ A enablement. Or fill out our hotline and work directly with Gareth Bowker and John Elliott.

The PCI SSC announced a new Self-assessment Questionnaire A (SAQ A) version today. This update removes the new requirements introduced in PCI DSS v4 designed to combat e-skimming attacks (6.4.3 and 11.6.1) and introduces new eligibility criteria that the merchant must confirm to be able to validate their compliance using this SAQ:

“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

From a security perspective, this is a positive change. It requires merchants of all sizes to confirm that not only their payment pages and parent pages are secure but also that their website is not susceptible to attacks from web skimmers that could impact their e-commerce system. This aligns with the types of incidents we have been observing, where web skimmers are often deployed site-wide.

Additionally, this change may encourage merchants to expand the scope of their website monitoring—from focusing solely on securing payment data to protecting all types of data. It could also aid in detecting fraud and phishing attacks. Monitoring tools such as Jscrambler’s Webpage Integrity provide a comprehensive set of features to harden and secure entire websites.

The Challenge of Timing

The timing of this change is a surprise, as we are just two months away from the March 31st deadline when the new requirements were to become mandatory. Some organizations that previously limited their assessments to the SAQ A scope may now find themselves ineligible and may need to consider, for instance, SAQ A-EP instead. Discovering that they must now comply with 100 additional requirements is certainly not ideal. To avoid this, organizations will likely want to ensure they remain eligible for the new SAQ A.

The best way to do so—and to confirm that a site is not susceptible to script-based attacks—is by implementing site-wide page integrity monitoring. This enables organizations to confidently verify that no skimmers are present on their websites.

Ambiguity vs. Simplicity

While requirements 6.4.3 and 11.6.1 provided a clear and structured approach, the new eligibility criteria is more outcome-focused. However, on the bright side, this change simplifies compliance, as organizations are no longer explicitly required to maintain an inventory of scripts, authorize each version, or review every update. Instead, they must confirm that first- and third-party scripts on their site do not make the site susceptible to attacks that could affect payments, including iframed payment forms.

This surely applies not only to silent skimming attacks but also to double-entry skimming attacks, where an end user is tricked into entering payment details twice caused by an attacker’s error message or by manipulated form behavior.

How Jscrambler Can Help

At Jscrambler, we are committed to working with all industry stakeholders to help organizations stay protected from attacks targeting e-commerce systems. Although the timing of this change presents challenges, Jscrambler’s Webpage Integrity can help organizations swiftly adapt and ensure merchants can meet the SAQ A eligibility criteria and are able to continue to assess and report their compliance using the limited number of requirements within SAQ A.

Get in touch with us to see how we can help you meet the new eligibility criteria.