Customise Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.

No cookies to display.

PCI Security Standards Council Makes an Unexpected U-Turn

When the PCI Security Standards Council (PCI SSC) released PCI DSS v4.0, one of the most notable changes was the introduction of two new requirements—6.4.3 and 11.6.1—designed to mitigate client-side exploits such as Magecart attacks and other vulnerabilities that could expose cardholder data. Given that JavaScript is the dominant client-side scripting language of the Web, these measures were intended to strengthen security on payment pages.

The new requirements were:

  • 6.4.3 – Ensuring the authorization and integrity of all scripts loaded on payment pages.
  • 11.6.1 – Implementing a change and tamper detection mechanism to alert on modifications to scripts and HTTP headers.

 

Recognising the complexity of implementation—particularly for e-commerce merchants—the PCI SSC had initially future-dated these requirements to take effect after March 31, 2025. However, in an unexpected shift, the Council has now removed these requirements from SAQ A—the self-assessment questionnaire used by e-commerce merchants who fully outsource payment processing to a third party.

PCI-Security-Standards-1

What Does This Change Mean for E-Commerce Merchants?

At first glance, many e-commerce businesses may welcome this decision, particularly those that had already begun investing time and resources into meeting these requirements. However, are they truly off the hook?

Let’s take a closer look.

  • For Merchants Using Full-Page Redirects: The original requirements never applied to merchants who redirect customers to a payment page fully hosted by a Payment Service Provider (PSP). Since the payment page belongs to the PSP, the PSP remains responsible for compliance with 6.4.3 and 11.6.1. This requirement still stands—the removal only affects SAQ A, not PCI DSS v4.0 itself.
  • For Merchants Using I-Frames or Hosted Fields: Previously, merchants who embedded PSP-hosted payment fields via I-frames or hosted fields were required to comply with 6.4.3 and 11.6.1. With the recent change, these merchants might assume they are exempt from these security controls. However, there’s a significant caveat.

A New Requirement in SAQ A

While PCI SSC has removed 6.4.3 and 11.6.1 from SAQ A, they have introduced a new eligibility criterion:

Merchants must confirm that their site is not susceptible to attacks from scripts that could compromise their e-commerce system(s).

The PCI SSC does not specify how merchants should verify or demonstrate compliance with this criterion. Additionally, for SAQs validated by a Qualified Security Assessor (QSA), there is no clear guidance on how this requirement should be evidenced.

This raises an important question—if there were a simple way to verify script security, why were 6.4.3 and 11.6.1 introduced in the first place?

What Should Merchants Do Now?

Until the PCI SSC provides further clarification, merchants may need to take proactive measures to demonstrate compliance with the new SAQ A eligibility criterion. Potential methods of validation could include:

  • Web application security testing
  • Vulnerability scanning
  • Regular script integrity checks


At 1 Sequence Cyber we are closely monitoring updates from the PCI SSC and will keep our clients informed as further guidance becomes available. If you have any concerns about your compliance status or need assistance, feel free to reach out to us

Contact Us Today

📧  Email: contact@1sequencecyber.com
📞  Phone: 020 3130 1723
📍  Address: 381 Acorn House, Midsummer Boulevard, Milton Keynes, MK9 3HP

Share: