PCI DSS 4.0.1: A Cybersecurity Blueprint by the Industry, for the Industry

The PCI DSS concentrates its regulations on ‘what’ rather than ‘how’ but remains one of the best cybersecurity standards available. Using the new version 4.0.1 as the lens, we discuss the PCI success story.

PCI DSS 4.0 was introduced in 2022. It was a major upgrade to the existing version 3.2.1. To allow time for both PCI and the regulated entities to understand and implement the necessary requirements, some of the proposals were marked as best practices and future dated.

The existing version 3.2.1 was retired on March 31, 2024. Version 4.0 became the only active version of DSS, but still had some concerns. These were discussed in November 2024 and rapidly rectified. On March 31, 2025, the corrected and active version became DSS 4.0.1.

DSS is unusual if not unique among security regulations. “The entire payment industry came together (card brands, banks, merchants, service providers, etc.) to confront a growing threat. It wasn’t regulators forcing action; it was the industry saying, ‘We can fix this’,” explains Monica Landen, CISO at Diligent. “Long before data privacy or government regulations, PCI DSS proved that an industry led standard could drive real, tangible improvements in security. I would love to see more of this across other industries.”

This explains the great strength of DSS. It is by industry for industry and contains no distraction from user security (beyond the users’ right not to suffer from industry insecurity). When governments get involved in regulating for cybersecurity, they invariably try to marry strong business security with protecting user rights. These two concepts are not a natural fit. They’re like mismatched pieces of a jigsaw puzzle; and forcing them together leads to overcomplication.

The EU’s AI Act is an example of overcomplicated regulation. While – in general – US regulations tend to safeguard innovation and companies, the EU is heavily focused on user rights and protections: with requirements defined by bureaucrats rather than AI experts. As a result, nobody wins.

On March 28, 2025, Bart De Witte (founder of the Hippo AI Foundation and now CEO and founder at startup Isaree (building an operating system for medical AI) commented on LinkedIn: “The EU Commission made it illegal to build AI startups.” He compares the cost of conforming to the AI Act with the funds available to startups and concludes that the ‘Brussels bureaucrats’ have only “cemented Big Tech’s monopoly (only they can afford this)” and have “guaranteed Europe’s AI irrelevance”.

This will not happen when a regulation is defined by the industry it regulates rather than by bureaucratic impositions. This is the strength of PCI DSS.

DSS conformance is only required for companies involved in processing, storing or transmitting credit or debit card data. It nevertheless provides good security advice to all companies – but since it does not (by design) try to impose security on or for the user, its use will not ensure compliance with government regulations such as GDPR and the AI Act.

Advertisement. Scroll to continue reading.

It is useful, therefore, to consider the philosophy and approach taken by the PCI in formulating its DSS.

The making of 4.0.1 is more than usually complex. Version 4.0 became mandatory on March 31, 2024. But it received negative feedback about the template provided to the assessors around two of the major additions being introduced: specifically, 6.4.3 and 11.6.1 intended to reduce the risk of e-skimming attacks during e-commerce transactions. Adam Bush, MD at Schellman, says, “It was too long. There was too much redundancy – areas where we were checking boxes and basically confirming the same thing over and over again. We suggested a reformatting of the template.”

Adam Bush, MD at Schellman — Adam Bush, Managing Director at Schellman

The ‘we’ in this instance was an E-commerce Guidance Task Force formed by PCI with expertise from PCI SSC staff, payment brand representatives, members of the Board of Advisors and Technical Advisory Board, the Global Executive Assessor Roundtable, (GEAR), and the Small Merchant Business Task Force. Bush is a member of GEAR.

PCI took the advice and rapidly produced a new template, but because it was a change to the mandated version, they had to issue an errata version. This is what became mandatory for the regulated entities on March 31, 2025. “It’s not a significant change,” explains Bush. “It was significant to the template, but not significant to the underlying controls and what’s required of everyone.” What it demonstrates, however, is the speed and efficiency with which a standard developed by the industry for the industry can correct its own weaknesses.

The focus on securing the industry rather than the user can be seen by looking closer at 4.0.1’s treatment of three current and major security concerns: MFA, encryption, and AI.

MFA

MFA controls are not new, but have been extended. “PCI DSS 4.0.1 extends MFA beyond just administrators, to all accounts accessing cardholder data,” comments Piyush Pandey, CEO at Pathlock. “It also requires secure MFA implementation and configuration.”

Landen further explains, “MFA is now required for access to the cardholder data environment and not just for VPN or remote access.” She adds that she would like to see emphasis on ‘phishing resistant’ MFA.

In short, says Vini Merlin, product manager at Oasis Security, “MFA requirements have expanded beyond remote access to include all access to the cardholder data environment (CDE). Additionally, organizations must conduct regular PCI DSS scope access reviews to ensure proper access controls.”

Not everyone is happy with the extent of the extensions. “Mobile devices are commonly used in MFA workflows,” comments Krishna Vishnubhotla, VP product strategy at Zimperium. “There are no explicit requirements asking the systems to ensure they do not send OTP to compromised mobile devices. Since most financial services are accessed through mobile apps, malware is quite common for stealing credentials. By not requiring ‘device attestation’ bad actors are able to steal credentials and OTPs, resulting in account takeovers and fraud.”

So, is not requiring phishing resistant MFA nor device attestation a failing in the PCI DSS regulation? Probably not, if you consider the PCI’s own mandate. “It’s a rather bold assumption to consider that a card user requires MFA to use a personal card,” explains Bush. “The user of a card can be very risky over personal security. That user can leave cards in a wallet, lying on the table, on a seat on public transport.”

If a card is lost or stolen, no amount of MFA can prevent contactless card fraud or card not present fraud. But protecting personal cards is the responsibility of the users, not the PCI – which has no authority over users. Their cards and their phones are their own personal property. PCI DSS, continues Bush, sets and enforces standards for the payment card industry: “the requirements are written for merchants once they are the holder or custodian of the users’ credit card information.” There is no attempt to tell users what to do.

While this explains the absence of device attestation as part of the MFA requirement, the avoidance of specifying a particular type of MFA to be used by the industry (such as phishing resistant) can be better understood by looking at the DSS rules on encryption.

Encryption

The encryption requirements specified in 4.0.1 have been extended. “To ensure secure data transmission, TLS 1.2 or higher is now required, while SSL and early TLS versions are strictly prohibited due to security vulnerabilities,” explains Merlin. “Encryption at rest is also strengthened – if disk-level encryption is used, organizations must implement additional controls to ensure Primary Account Numbers (PANs) remain unreadable. Secure key management and strong cryptographic algorithms are essential for maintaining compliance.”

But the basic encryption of data has not changed. It is simply a requirement for ‘strong encryption’, with no attempt to define what constitutes strong encryption. On the surface, this appears surprising since NIST has spent most of the last decade developing stronger encryption; and the NSA is insisting that, from 2017, US national security systems can only purchase new products that include these new NIST standardized encryption algorithms.

However, traditionally, PCI tries not to be overly prescriptive. It defines what must be achieved rather than how it must be achieved. There are good reasons for this. What offered good security last week may not offer good security next week; and what is good for one company may not be so good for another. In encryption, a strong algorithm this week could become a weak algorithm overnight if it is cracked. But the requirement for strong encryption remains a valid requirement regardless of the state of individual algorithms.

“It’s an issue that has been evaluated by the council,” explains Bush. The value of specific security controls and systems can change rapidly, and it affects far more than encryption alone. “So, DSS requires that regulated bodies constantly monitor their technology and security controls against what’s happening in the real world. Is what has been used for the last few years still adequate? Is the encryption being used still strong, or has it been broken. Is it time to change from AES 128 to AES 256? PCI solves this problem by putting the liability back on the implementors, while the assessors can say ‘yes’ this is adequate today, or ‘no’ this is no longer adequate.”

The same basic principle applies to MFA. It is on the implementer to install MFA, and the assessor to judge the implementation, including whether the MFA in this instance should be phishing resistant MFA, if that hasn’t been implemented.

Artificial Intelligence

The use of artificial intelligence is a complex area that is only just being seriously integrated into DSS – remember that the original 4.0 was released back in 2022, the same year that ChatGPT began upending the world as we know it. PCI was aware of AI, but more as a contained ML function within different security products. It had no real understanding of publicly available LLMs.

“Version 4.0.1 does not prescriptively add anything around AI,” says Bush, “and the council has only just begun writing guidance on the use of AI.” Within the last month it published a document on how it could be used by assessors, such as Bush himself. It is reasonable to use AI on black or white assessments like finding open ports; but perhaps not reasonable to allow it to make judgmental calls on whether a control is or is not necessary.

But the council gives no definitive guidance on whether a merchant or service provider should be using AI. “I can tell you the attitude toward AI is ‘it’s nothing new’. This is still a machine that is referencing code that was written either by a human or by some other artificial intelligence,” he continues. “It’s still software running on a server somewhere. It’s still ones and zeros – and we already have a secure framework that says how things should be operating.”

Wearing my Nostradamus hat, he adds, “I would suggest that the council is not going to issue anything hugely revelatory on how we should be assessing AI deployment in merchant environments. My guess is that it’s going to be ‘nothing new here’; we have a robust set of security controls and frameworks that AI also falls pretty squarely within.”

And remember, by not regulating for the user, DSS can avoid getting bogged down in esoteric and subjective concerns over ethics.

For the moment, the only new requirement discusses the regulated entities’ use of third-party AI implementations, and is more focused on vendor-related risks than AI per se. “While PCI DSS v4.0.1 does not explicitly regulate AI,” comments Merlin, “organizations must vet their AI vendors, ensuring these tools do not inadvertently store, process, or transmit card holder data outside of a controlled PCI DSS-compliant environment. AI-driven fraud detection, automation tools, and customer service platforms must be assessed for compliance risks to prevent unintentional data exposure.”

This is a continuation of the council’s traditional approach – put liability for doing the right thing on the regulated entities, and then use the assessors to assess whether the actions are valid and conform to the spirit of the regulation.

4.0.1 is a major new version of PCI DSS – but it remains true to the council’s long standing principles. The correct way to secure one company might not be the correct way to secure another. For this reason, DSS primarily specifies required outcomes rather than precise methods of implementation. One requirement is that the regulated entities continually monitor the performance of their own security policies in achieving those outcomes, while the assessors are there to judge whether it is valid.

At the same time, the standard remains strictly within its purview: by the industry for the industry. It has no remit on how users behave with their own payment cards and phones and cannot – and consequently does not attempt – to regulate user behavior.

For the industry itself, Landen comments, “The implications come down to more effort and cost. For mature security organizations, this will not be a heavy lift. For less mature organizations, however, there will likely be an ongoing operational overhead including skilled people, process, and technology to comply with these new requirements.”

DSS version 4.0.1 provides an excellent baseline or checklist for improving the security of companies. In this sense it is a huge benefit to cybersecurity. But it must be understood that complying with DSS does not imply compliance with the more bureaucratic regulations such as GDPR and the AI Act.