SAQ A Changes in 2025: Why 6.4.3 and 11.6.1 Were Removed and What Replaced Them

In January 2025 the PCI Security Standards Council published a revised SAQ A for PCI DSS v4.0.1. It removes requirements 6.4.3 and 11.6.1, which cover payment page scripts and tamper detection, along with requirement 12.3.1 where it supported 11.6.1. In their place is a new eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce system(s).

The revised SAQ A takes effect on March 31, 2025, the same day the October 2024 version retires. The requirements themselves remain in PCI DSS. What changes is how SAQ A merchants validate, and that shift puts more weight on a confirmation that the SAQ doesn't explain how to make.

What changed in SAQ A in January 2025?

The Council's announcement on January 30, 2025 described the changes as a response to stakeholder feedback about the new e-commerce requirements in v4.0.1. The revision does three things:

• Removes requirements 6.4.3 and 11.6.1 from the questions SAQ A merchants answer.
• Removes requirement 12.3.1 as it applied to 11.6.1. That targeted risk analysis was only needed if a merchant wanted to run 11.6.1 checks less often than every seven days.
• Adds an eligibility criterion requiring the merchant to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce system(s).

The existing e-commerce criteria stay in place. All elements of the payment pages or forms delivered to the customer's browser must still originate only and directly from a PCI DSS compliant third-party service provider (TPSP) or payment processor.

Key dates

If you complete an SAQ A before March 31, you'll still use the October 2024 version. In that version, 6.4.3 and 11.6.1 remain best practice until the same date, so the practical effect for SAQ A merchants is that the two requirements never become mandatory questions on their questionnaire.

Why were 6.4.3 and 11.6.1 removed from SAQ A?

SAQ A is for merchants that have completely outsourced their account data functions to validated third parties. Many of them are small businesses using a payment provider's embedded form or a redirect to the provider's hosted page.

In our experience, 6.4.3 and 11.6.1 were a heavy lift for those merchants. Building a justified script inventory, putting every script under authorization and integrity controls, and running change and tamper detection on the pages that host a payment form takes skills and tooling that many small merchants don't have in-house.

The Council has been clear that the change affects compliance reporting only. The underlying requirements stay in PCI DSS, and the risk they address hasn't gone anywhere.

What replaced them? The new eligibility criterion

Eligibility criteria work differently from requirements. You don't answer "In Place" or "Not Applicable" against them. Either you meet every criterion and can use SAQ A, or you don't and need a different validation path.

The new criterion reads: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).

Two details stand out:

• It refers to your site, not only your payment page. The removed requirements focused on payment pages. The criterion's wording is broader.
• It doesn't say how to confirm it. The SAQ doesn't list methods, evidence or a testing procedure. The merchant makes the confirmation, and acquirers or assessors may ask what it was based on.

Our advice is to treat the confirmation as something you should be able to explain and support with documents, not a box you tick.

What should iframe merchants do now?

If your checkout page embeds your payment provider's form in an inline frame (iframe), the new criterion lands most directly on you. The form comes from the provider, but the page around it is yours, and scripts on that page can interfere with what the customer sees and interacts with.

PCI DSS v4.0.1, published in June 2024, already drew this line for 6.4.3 and 11.6.1. Its applicability notes say those requirements apply to scripts in the merchant's page that hosts an embedded payment form, while scripts inside the provider's embedded form are the provider's responsibility. That same split is a sensible way to think about the new criterion.

Practical steps that give you a defensible basis for the confirmation:

1. Reduce what runs on pages hosting the form. Remove analytics, marketing tags and widgets that don't need to be on checkout. Fewer scripts means less to explain.
2. Know what remains. Keep a simple list of the scripts on those pages, where they come from and why they're needed.
3. Control changes. Restrict who can add scripts, including through tag managers, and route checkout page changes through change approval.
4. Use browser-side controls. A Content Security Policy that limits script sources, and Subresource Integrity for scripts that don't change, both make unauthorized scripts harder to introduce.
5. Ask your payment provider. Find out what protections its embedded solution offers against interference from the hosting page and how it must be implemented for those protections to work. Get the answer in writing.
6. Document your basis. Record which of these measures you rely on and keep that record with your SAQ.

If you had already started building 6.4.3 and 11.6.1 controls, don't tear them out. They remain the clearest evidence that your site isn't exposed to script attacks.

What should redirect merchants do now?

If your site sends customers to the provider's hosted payment page through a redirect or link, your exposure is smaller. Earlier SAQ A guidance already let redirect merchants mark 11.6.1 as not applicable.

The new criterion's wording, though, doesn't separate redirect merchants from iframe merchants. It refers to the merchant's site. The page that sends customers to your provider is still yours, and an unauthorized change to that page or to where its payment link points is still a risk you own.

A proportionate approach for redirect merchants:

• Limit who can edit the page and the link that start the payment journey.
• Keep third-party scripts on that page to a minimum.
• Consider a Content Security Policy for the site.
• Check periodically that the payment link points where it should.
• Ask your acquirer whether it expects a documented basis for your confirmation.

What if you can't confirm the criterion?

Then you aren't eligible for SAQ A. Talk to your acquirer about which validation method applies. For many e-commerce merchants that will be SAQ A-EP, which includes 6.4.3 and 11.6.1 in full.

Remember that acquirers and payment brands decide how their merchants validate. Some may ask for more than the SAQ does, so check before assuming the removal applies to you unchanged.

Frequently asked questions

Are 6.4.3 and 11.6.1 gone from PCI DSS?

No. Both remain in PCI DSS v4.0.1 and become mandatory on March 31, 2025. Merchants validating with SAQ A-EP, SAQ D or a Report on Compliance must still meet them.

Does the new criterion apply only to merchants that use iframes?

The criterion's wording doesn't make that distinction. It refers to the merchant's site and e-commerce systems. Iframe merchants have the most direct exposure, but redirect merchants shouldn't assume they're exempt without checking with their acquirer.

Do SAQ A merchants still need a targeted risk analysis?

Not for 11.6.1 once the January 2025 SAQ A is in effect, since both 11.6.1 and the related 12.3.1 question were removed. Merchants using other SAQs still need one if they run 11.6.1 checks less often than every seven days.

Does our payment provider's Attestation of Compliance cover this?

Not on its own. The provider's AOC covers the services it provides. The new criterion is about your site, and you're the one making the confirmation. Written information from your provider about its embedded solution can support that confirmation, but it doesn't replace it.

Next steps

• Check which SAQ A version your next submission will use based on its completion date.
• If you use an iframe, review the scripts on pages that host the payment form and write down the basis for your confirmation.
• If you use a redirect, lock down the page and link that start the payment journey.
• Ask your acquirer how it expects the new criterion to be supported, and watch for further guidance from the Council.
• Keep any 6.4.3 and 11.6.1 work you've already done. It is the strongest support for the confirmation you'll be making.