It is hard to believe when we set out in the mid-2000s to create a global set of requirements to protect payment data that two decades later, the Payment Card Industry Data Security Standard (PCI DSS) would still be globally recognized and as relevant as ever.

A key to the success of the standard is recognizing how risks to payment data have evolved and adjusting accordingly and in a manner that is considerate of market readiness to implement.

Truth be told, of the more than sixty new requirements, many of the concepts—such as the ubiquitous use of Multi Factor Authentication (MFA) and encrypting Sensitive Authentication Data (SAD) throughout the entirety of the payment transaction lifecycle—were discussed more than 10 years ago but never codified due to concerns about the technical readiness of all organizations to achieve them.

Fast forward to today and we recognize that threats and vulnerabilities are increasingly introduced at an accelerated pace, requiring more investment in security to maintain prior levels of trustworthiness.

I liken it to the marine maps that have evolved over the past few centuries as the seas became more commonly explored. (Although the depths of the ocean remain mostly a mystery.) As areas of risk became known, ship routes changed to provide the safest travel of cargo to its destinations. So too has PCI DSS adapted to address risk for payment workloads and the vessels through which transactions process.

PCI DSS v4 explores several new themes that have emerged, putting PCI DSS into less charted areas than ever before and I’d like to explore some of those.

Most notably, we’ll focus on some of the upcoming changes (effective March 31, 2025) that may require additional planning well in advance. In this article, I’ll share my thoughts on:

• Expanded scope into consumer browsers
• More accountability for third-party services
• Increased requirements for authentication
• Flexibility in the ability to demonstrate requirements have been met (“New approach to validating requirements have been met”)

Payment Pages on Consumer Browser – Why is it needed and Why is it new

If you attended any of the PCI Community Meetings from 2016-2021 and heard my talks, this may not come as much of a surprise: one of the emerging risks we had identified at the PCI Council was a shift to attack the e-Commerce channel after groups like Magecart began targeting downstream suppliers of merchant websites.

This was a natural maturation of fraud to e-Commerce as card-present transactions became more secure from chip and mobilepay techniques that reduced the opportunity to perpetrate fraud.

Data breaches that exposed payment data from merchant websites such as British Airways, Virgin Airlines, Ticketmaster and elsewhere were the result of criminals targeting third-party code supplied to websites, and that code was more difficult to directly monitor.

While there were prior expectations to prevent exploitable code (like Javascript) sent to browsers directly from the merchant, the reality is most webpages include runtime code derived from many sources and/or use iFrame elements for payment processing, which could lead to additional risk.

To address this and other risks, PCI DSS v4 has the following new requirements [paraphrased]:

• Req 6.3.2 Inventory of bespoke and custom software and third-party software components is maintained to facilitate vulnerability and patch management
• Req 6.4.3: Requires management of all payment page scripts loaded and executed in the customer’s browsers
• Req 11.6.1: Deploy mechanisms to detect changes or unauthorized modification of security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser

Now there is a need to control the potential risk by identifying and managing risk of all software components—regardless of source—and specifically to manage the integrity of the payment page scripts within the consumer’s browsers as well as to monitor for anomalies from HTTP headers returned by the consumer’s browser. 

This expands the scope from former PCI DSS assessments and is an important area to be aware of as criminals increasingly target them. While there are many methods to accomplish this, I highly recommend using validated software like Client-side Defense from HUMAN Security. (In the interest of full disclosure, HUMAN sponsored this writing but I believe in their approach, as does Coalfire, which recently published a whitepaper (PDF) about the solution). 

Third-party services

The next set of new requirements may require new conversations with third-party services currently being deployed in your environment.

This shouldn’t be much of a surprise given the focus on supply chain security in every industry. In recent months, we’ve read about various third-parties exposing customer or employee data as a result of not enough due diligence for the services offered. Multiple credit unions, telecommunication companies and security vendors, all in categories of heightened security, have disclosed that they were compromised by third-party providers.

• Appendix A1: Additional Requirements for Multi-Tenant Service Providers. There is an entire new section of requirements dedicated to certain service providers to logically separate customer’s data environments, and expectations to have documented audit logs and incident response in a timely manner if there is suspicion of compromise.
• Req 11.4.7: (Multi-tenant service providers only.) Support is required for customers’ external penetration testing which may mean revisiting SLAs
• Req 11.5.1.1: (Service providers only.) The use of techniques to detect or prevent intrusion is required to detect, alert, prevent, and address malware communication.
• Req 12.5.2.1: (Service providers only.) Documentation and confirmation of the PCI DSS scope must be done every six months and with any significant change to the environment.

These types of PCI requirements are becoming increasingly common in other frameworks and legislation. While the final technical requirements from ESA are yet to be published as of the time of this writing, elements of European acts such as the Digital Operational Resiliency Act (DORA) and the EU Cybersecurity Act have expectations to independently test the security of service providers. And similar work is being evaluated in the United States, Asia and elsewhere.

I’ll add one additional requirement that is not service provider-specific but may have relevance for those environments:

• Req 3.3.2. SAD is not stored electronically prior to completion of auth and uses strong cryptography. 

While not exclusive to third-parties, this requirement impacts cloud queuing services and point-of-sale processing devices that may be outsourced and necessitate discussions as well. I’d also encourage exploring Confidential Computing and what cloud providers offer for secure enclaves to help address this requirement by keeping payloads encrypted but still able to operate with the data.

Authentication

The quick adoption of GenAI (you didn’t think you’d read an article in 2024 without reference to AI, did you?) is creating many new opportunities to manipulate or circumvent traditional form factors of authentication.

Bad actors—with help from sources such as WolfGPT, FraudGPT, PoisonGPT, etc.—have increased the ease, and therefore the volume, of malicious activity. In fact, in a Slashnext report published last quarter, there was a 1,265% increase in phishing due to GPT capabilities. And we’ve seen the use of deepfake AI to convince the wire transfer of millions of dollars because staff thought they were speaking live with their CFO.

As such, several new requirements were introduced to improve or extend authentication techniques. A few more significant changes include [paraphrased]:

• Req 5.4.1: New processes for detecting and protecting personnel from phishing attacks 
• Req 8.4.2 ALL access into payment environments requires MFA
• Req 11.3.1.2: Internal vulnerability scans must be performed by authenticated scanning.

Ok, I stretched a little on the last requirement, but it is an important change to show the integrity of how internal vulnerability scans will be expected to run in the future.

Final Thoughts

The latest revisions to the PCI DSS standard are the most significant in more than a decade in the size, complexity and expansion of scope.

Beyond what I’ve described above, there are dozens of other new requirements that will take time to evaluate, and I encourage anyone preparing for the March 31, 2025 deadline to begin immediately to look at whether existing practices meet all of the new requirements.

I’d encourage taking your time reading the standards and considering how the changes will need to be implemented. There should most likely be adjustments in upcoming Reports of Compliance and associated assessments.

For those that have been following PCI standards for a long time, know that the spirit and intent has not changed. The ‘true north’ that you have navigated with to protect payment data wherever it is stored, processed or transmitted remains.

Secondly, I’d encourage exploring where you can confidently apply automation both to manage security threats but also to keep up with all the documentation requirements that come with maintaining compliance.

Lastly, I’d encourage you to prioritize the requirements above as you begin your voyage into your 2025 PCI DSS compliance. Check out this product applicability guide by Coalfire, a prominent QSAC, to read more about PCI DSS 4’s consumer browser requirements and learn how HUMAN can help.

The thoughts in this article are from Troy Leach alone. While Mr. Leach is the former Chief Technology Officer and Chief Standards Architect for the PCI Security Standards Council, for any current and official position on PCI DSS v4 Requirements, please refer to official guidance directly from the PCI Security Standards Council.