The Payment Card Industry Security Standards Council (PCI SSC) just announced a change to Self Assessment Questionnaire A (SAQ A). The change eliminates two (2) requirements relevant to eCommerce sites, 6.4.3 and 11.6.1, that are designed to prevent and detect tampering with payment page scripts. While this appears to make compliance easier, and SAQ A eCommerce merchants may be celebrating this change, there's a catch: a new line in the eligibility criteria needs to be met to qualify for SAQ A, and failure to meet this requirement could drastically increase the number of applicable requirements. 

For any merchant with a payment channel that they intended to assess using SAQ A, TrustedSec recommends using one (1) or more of the following options to remain eligible:

• Implement requirements 6.4.3 and 11.6.1 as if this change was never made.
• Get assurances from the processor that their iFrame is not susceptible to script-based attacks when installed properly.
• Develop and implement an alternative method of confirming that the eCommerce site is not susceptible to attacks from scripts, for example:
  • Conduct web application testing specifically to demonstrate that malicious insertion of or tampering with scripts is not feasible on the eCommerce site.
  • Deploy and configure a Web Application Firewall (WAF) to protect the site from script-based attacks.

Read on for more details on which organizations are affected, the nuances of the change, and the potential solutions.

Another Guidance Update (March 10, 2025)

PCI SSC released an information supplement with more requirement 6.4.3 and 11.6.1 guidance on March 10, 2025. This additional guidance does not change our understanding of requirements 6.4.3 and 11.6.1 or the advice given in this post but offers some more helpful information that organizations implementing these requirements should review. No further updates to this post have been made because of the new guidance.

Guidance Update (March 04, 2025)

PCI SSC released FAQ 1588 to address the changes to SAQ A on Feb 28, 2025, a few weeks after the changes to SAQ A were published and this post went live. Although the guidance hasn’t led to any major changes in our understanding of the new SAQ A, this post has been revised to reflect the additional guidance.

Key points of the new guidance include:

• Scope:
  • The new eligibility criterion only applies to merchant pages hosting embedded payment pages or forms—i.e., iFrames—and does not apply to redirects or links to payment pages.
  • Providers of third-party scripts that are not related to payment processing and cannot impact the security of account data are not considered third-party service providers.
• Eligibility:
  • Implementing requirements 6.4.3 and 11.6.1 is sufficient to meet the new SAQ A eligibility criterion.
  • The techniques to meet the new eligibility criterion are not limited to implementing requirements 6.4.3 and 11.6.1, so alternatives, including the penetration testing and WAF solutions as described below, may be sufficient to meet the eligibility criteria (this is up to an individual QSA’s discretion).
  • A new path to meet the new eligibility criterion via the payment processor’s attestation is described in detail in the Solutions section below.

What this guidance does not completely clear up is whether requirements 6.4.3 and 11.6.1 (or alternatives) must be applied to the entire site or just the page that hosts the iFrame. While the new eligibility criterion still says “site”, the guidance states that requirements 6.4.3 and 11.6.1 would protect the merchant’s “web page”.

It is the opinion of this QSA that implementing requirements 6.4.3 and 11.6.1 only on the page that hosts the iFrame is sufficient to meet the new eligibility criterion. However, PCI SSC has been clear that guidance does not override the requirements as written in the PCI DSS and SAQs, so other QSAs may disagree and require that it be implemented site-wide.

As a QSA, we and many of our clients are confused and frustrated by this change to SAQ A only a few weeks before the future-dated requirement deadline. PCI SSC normally asks for stakeholder commentary on changes to help identify and clear up confusion, similar to what we have experienced for the past few weeks, before final publication. In this case, it’s hard to understand why PCI SSC would remove requirements 6.4.3 and 11.6.1 from the SAQ only to then recommend implementing requirements 6.4.3 and 11.6.1 as a way to meet the new eligibility criterion. If the intent was to add alternatives to requirements 6.4.3 and 11.6.1, this could have been accomplished with much more clarity by adding the option for alternatives in the SAQ A notes on those requirements rather than complicating the eligibility criteria.

Applicability

The short version is: this change affects any merchant that has an eCommerce payment channel that qualifies for SAQ A because the payment page or form is embedded in an iFrame, including merchants with SAQ A-qualifying eCommerce channels that complete a Report on Compliance (ROC) rather than an SAQ.

Merchants that meet certain eligibility criteria can use shorter SAQs that omit certain PCI DSS requirements instead of complying with and assessing the full list of up to 234 PCI DSS controls (not counting the Early SSL/TLS or Designated Entity appendices). SAQ A is the short form for merchants that have outsourced all payment card processing to a PCI DSS-compliant third-party service provider so that the merchant does not store, process, or transmit any electric account data on their own systems or premises. Typically, this is a merchant that has outsourced telephone payments to a third-party call center and/or outsourced their eCommerce payment page to a third party in such a way that all elements of the payment form are delivered to the consumer browser from the third party. SAQ A allows for a drastic reduction in applicable requirements with only 21 (soon to be 19) controls, of which 15 (soon to be 13) only apply to outsourced eCommerce sites, and eight (8) only apply to the few merchants that still handle paper records that contain card data.

Merchants that are required to complete a ROC rather than an SAQ (usually due to high transaction volume or a breach) but have a payment channel that otherwise meets the eligibility criteria for SAQ A are affected by this change. PCI SSC FAQ 1331 allows merchants with channels that meet the eligibility criteria for shorter SAQs (including SAQ A) to use those SAQs as a guide to applicable controls for those channels they complete the ROC. Merchants that continue to meet the new eligibility criteria for their eCommerce channel(s) would be able to mark requirements 6.4.3 and 11.6.1 not applicable for those channels with the proper documentation in their ROC.

The requirements themselves and the eligibility change are specific to merchants using SAQ A for eCommerce payment channels, so they do not affect merchants that use SAQ A but do not have any outsourced eCommerce payment channels.

This change does not affect merchants that were not already eligible for SAQ A; they will still need to implement requirements 6.4.3 and 11.6.1 if they have an eCommerce site. Service providers are never eligible for SAQ A or the other reduced applicability SAQs and are also not affected by this change.

There are three (3) main ways that merchants outsource their eCommerce payment channels to qualify for SAQ A:

• Set up an iFrame within their own eCommerce site so consumer browsers load the payment page from the third-party service provider
• Set up a redirect on their own eCommerce site so consumer browsers are redirected to the third-party payment page
• Completely outsource the entire eCommerce site to the third-party so the merchant no longer has their own eCommerce site

In the current version of SAQ A, requirements 6.4.3 and 11.6.1 both apply only to the web page or site that includes the third-party embedded payment page or form, i.e., an iFrame. This means that both of these requirements were already not applicable to eCommerce merchants that use a redirect or completely outsource their eCommerce site. FAQ 1588 states that the new eligibility criterion only applies in this same context and is not applicable to merchants using redirects to the payment page or completely outsourcing their eCommerce site.

The Change

Merchants that meet the new eligibility criteria for SAQ A will no longer need to implement requirements 6.4.3 or 11.6.1, but merchants that do not meet the new eligibility criteria will need to comply with many additional PCI DSS requirements and individually justify any requirements that they believe are not applicable to their environment. This is a heavy price to pay for eliminating two (2) requirements from SAQ A.

Requirements 6.4.3 and 11.6.1 are scheduled to go into effect on April 01, 2025 and previously applied to merchants that are eligible for SAQ A. A new version of SAQ A that includes the new eligibility criteria but omits these requirements has been published and will take effect on April 01, 2025. This means that all eCommerce merchants that want to use SAQ A must meet the new eligibility criteria by that date.

Many merchants have been struggling to meet requirements 6.4.3 and 11.6.1, so SAQ A eCommerce merchants may be excited to see this change. Some merchants have already started implementing technologies like a Content Security Policy (CSP) on their website or contracting third-party services to meet these requirements. Merchants shouldn't immediately abandon these compliance efforts, however, because they may still be relevant to the new eligibility criteria, which reads 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).”

The new eligibility criterion addresses malicious scripts, much like requirements 6.4.3 and 11.6.1, but is much more vague than the omitted requirements. Rather than meeting the specific control points of the previous requirements, merchants must now prove to themselves or their QSAs the nebulous concept that their site is "not susceptible" to attacks.

Requirements 6.4.3 and 11.6.1 only applied to the specific page that includes the embedded payment form in the current version of SAQ A, while this new criterion applies to “their site”. This implies that whatever solution is used to meet the new eligibility criteria must be implemented across the merchant’s entire site rather than just the page with the embedded form. This is somewhat contradicted by FAQ 1588, which states that implementing requirements 6.4.3 and 11.6.1 to protect the merchant’s “web page” from scripts is sufficient to meet the new eligibility criterion.

This ambiguity may lead to confusion as various stakeholders throughout the PCI community (including merchant personnel and QSAs) will have different interpretations of what qualifies as "not susceptible". Merchants may be surprised at the start of an assessment or after a breach when a QSA or forensic investigator informs the merchant that they are not eligible for SAQ A because they did not address the risk of web skimming attacks, which are becoming increasingly common (e.g., Magecart). The merchant would be left scrambling to either meet the eligibility criteria or implement many more applicable requirements (including 6.4.3 and 11.6.1). 

There will likely be as many opinions on what qualifies as "not susceptible" as there are people implementing and assessing PCI DSS requirements. Determining eligibility for SAQ A, including whether a solution is sufficient to meet the eligibility criterion and whether it should be implemented site-wide or just on the page hosting the iFrame, will require a conversation between merchants and their QSAs, or some deep research for merchants that don't use a QSA.

Solutions

Organizations may continue implementing the controls described in requirements 6.4.3 and 11.6.1. PCI DSS v4.0 was finalized and published on March 31, 2022, so the intervening three (3) years should have provided merchants with plenty of time to implement these controls prior to the April 01 deadline. Continuing with existing plans seems like the easiest path to remain eligible for SAQ A. Merchants that have been putting off implementation of requirements 6.4.3 and 11.6.1 until their next annual assessment is due should read the blog post on Playing Games with PCI Compliance Deadlines and review PCI SSC FAQ 1176.

FAQ 1588 introduces the option to get the payment processor to provide some confirmation that their iFrame solution includes techniques to protect your page from script attacks when implemented according to their instructions. Failure to follow the instructions would render the merchant ineligible for SAQ A. Taking this approach effectively adds the following hurdles:

• Get the processor to provide a suitable confirmation in writing.
• Get and follow the instructions for implementing the iFrame from the processor.
• If not self-assessing, show the confirmation and instructions to the QSA, and demonstrate that the instructions have been followed.

FAQ 1588 is clear that implementing requirements 6.4.3 and 11.6.1 is not the only way to protect the page from scripts. Alternative solutions to meeting the new eligibility criteria could include conducting a web application assessment specifically to confirm that script-based attacks on the merchant’s site cannot affect the eCommerce systems or deploying a WAF specifically configured to detect and block script based attacks. Merchants must be able to justify why the alternative solution they implement is sufficient to meet the new eligibility criterion.

In theory, a payment channel that no longer qualifies for SAQ A under the new criteria would be eligible for SAQ A-EP, which has not changed. This is another SAQ for outsourced eCommerce that is normally used when the payment form comes from the merchant’s web server rather than a third-party web server. SAQ A-EP is much larger than SAQ A with 128 requirements for eCommerce sites plus eight (8) more requirements for merchants that handle paper records with card data.

Further, requirements 6.4.3 and 11.6.1 are both in SAQ A-EP, and implementing these requirements is a potential way to meet the new eligibility criteria. Thus, a merchant with a payment channel that will no longer be eligible for SAQ A should focus on implementing these requirements on the eCommerce site to remain eligible for SAQ A rather than the much greater burden of implementing the remaining controls in SAQ A-EP or the rest of PCI DSS.

Implementing Requirements 6.4.3 and 11.6.1

For merchants that want to continue implementing requirements 6.4.3 and 11.6.1, either as a way to meet the eligibility criteria for SAQ A or because they are no longer eligible for SAQ A, PCI SSC has promised a new guidance document specific to these requirements in the next few weeks. TrustedSec has a few suggestions for implementing these requirements while waiting for the new PCI SSC guidance.

The scenario these requirements are trying to address is the possibility of a new malicious script being inserted in the payment page or existing scripts on the payment page being modified to take malicious actions. For an SAQ A-eligible outsourced eCommerce site, the malicious action is typically the skimming of card data that should be entered directly into the processor's site via an iFrame. An example of how scripts accomplish this is by hiding the processor's iFrame from the consumer and instead presenting a scripted malicious payment form that sends the card data to the attacker while also submitting it via the hidden processor iFrame.

Requirement 6.4.3 is meant to prevent the insertion of malicious scripts into a site and tampering with authorized scripts. The controls necessary to meet this requirement should be implemented as part of the site's development process. Requirement 6.4.3 has three (3) specific controls:

• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

A CSP is a key tool to confirm that scripts are authorized and have integrity. This is a W3C standard that is widely supported in modern browsers. It is essentially an allowlist that permits the consumer's browser to only load content (including scripts) from authorized sources. A new version of the CSP standard is currently in draft status.

As per the PCI DSS guidance for requirement 6.4.3, this requirement applies to scripts loaded from third- and fourth-parties in addition to scripts loaded from the merchant's own payment page. However, from the merchant's perspective, it does not apply to scripts loaded by the processor's iFrame (compliance for scripts within the iFrame is the processor's responsibility). An attacker that comprises a third- or fourth-party script (including a processor’s scripts) could potentially affect many merchants' sites simultaneously, so this is a tempting attack vector. Subresource Integrity (SRI) is another tool (and W3C standard) that can be used to ensure third- and fourth-party content (including scripts) has not been manipulated. SRI allows cryptographic hashes to be assigned to script tags so consumer browsers can verify the integrity of the scripts.

Merchants often struggle with third- and fourth-party script integrity because these scripts may legitimately change without notification to the merchant, which renders the SRI hashes invalid and will generate errors in the consumer's browser. Requirement 6.4.3 only applies to the payment page (not other pages on the same site), so merchants should strongly consider removing all unnecessary scripts from the payment page. This makes it easier to implement SRI and comply with requirement 6.4.3 and increases security by reducing the attack surface.

Requirement 11.6.1 complements requirement 6.4.3 by implementing monitoring controls to detect whether the authorization and integrity controls from requirement 6.4.3 have failed. Requirement 11.6.1 also has three (3) specific controls:

• Alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is configured to evaluate the received HTTP headers and payment pages.
• The mechanism functions are performed as follows:
  • At least weekly
  or
  • Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

It's important to note that this requirement specifies "as received by the consumer browser". This is meant to be a client-side check so it can detect malicious attacks that may be occurring after the page has been transmitted by the web server, e.g., in a content delivery network (CDN), or on pages that are dynamically assembled from multiple sources. A simple script that periodically loads the page and checks specific header, CSP, and SRI parameters could be sufficient to meet this requirement. The reporting mechanism built into CSP can also be used.

Requirement 11.6.1, like requirement 6.4.3, only applies to the payment page so reducing the number of scripts within the payment page can reduce the compliance burden. 

Various third-party services also claim to be able to meet requirements 6.4.3 and 11.6.1 on behalf of the merchant. TrustedSec does not take a position on whether any of these services are sufficient to meet the requirements at this time.

Next Steps

SAQ A eCommerce merchants must now determine how to meet the new eligibility criteria and have until March 31, 2025 to implement their solution or the necessary PCI DSS controls if they will no longer be eligible for SAQ A.

TrustedSec recommends working with a QSA who understands the eligibility criteria and the types of evolving script-based attacks that merchant websites face well in advance of the compliance deadline to avoid surprises during an assessment or breach investigation.

TrustedSec has a staff of experienced QSAs available to help with any questions.

This post was originally published on February 6, 2025 and has been updated to reflect changes in PCI DSS SAQ A.