PCI DSS 4.0

PCI DSS 4.0 retains the same twelve requirement domains as previous versions but introduces significant changes in how requirements are interpreted and evidenced.

‍

The customised approach is a new compliance pathway introduced in 4.0. Previously, all entities followed a defined approach with prescriptive controls. The customised approach allows entities to implement alternative controls that achieve the same security objective through different means, provided they document and validate the alternative approach through a targeted risk analysis. This gives security teams more flexibility to implement controls appropriate to their specific technology and risk environment rather than following a prescriptive checklist.

‍

Authentication requirements are significantly strengthened in 4.0. Requirement 8 now mandates multi-factor authentication (MFA) for all access to the cardholder data environment, not just remote access as in 3.2.1. Password minimum length increases to 12 characters. Phishing-resistant authentication methods (passkeys, hardware tokens) are recommended for high-privilege access. These requirements reflect the evolution of credential-based attacks since the previous standard.

‍

Requirement 6 (secure systems and software) is expanded to address web-facing payment pages more explicitly. Requirement 6.4.3 addresses the security of payment page scripts: merchants must maintain an inventory of all scripts on payment pages, authorise each script, and assure its integrity. Requirement 11.6.1 requires a change- and tamper-detection mechanism for payment page content and HTTP headers. This targets Magecart-style skimming attacks that inject malicious JavaScript onto payment pages to steal cardholder data.

‍

E-commerce merchants are required to implement an automated technical solution to detect and alert on changes to the HTTP headers and payment page content, addressing the growing threat of supply chain attacks via third-party scripts embedded in payment pages.

PCI DSS 4.0's scope expansion to web-facing payment pages and third-party scripts directly addresses the most prevalent attack vector in e-commerce cardholder data theft: Magecart and related skimming attacks. These attacks compromise payment pages by injecting JavaScript that intercepts card data as customers type it, without requiring access to the merchant's servers or databases. Version 3.2.1 did not address this attack vector adequately; 4.0's script integrity requirements close the gap.

‍

The customised approach reflects the reality that prescriptive controls designed for traditional IT architectures do not always map cleanly to cloud-native, containerised, and microservices-based payment environments. Organisations using modern architectures can now document how their implementations achieve equivalent security outcomes, rather than implementing controls that were designed for a different technology generation.

‍

The full MFA requirement for cardholder data environment access reflects a decade of evidence that passwords alone are insufficient protection against credential-based attacks. Ransomware operators, internal threat actors, and external attackers routinely exploit password-only authentication to access cardholder data environments. Mandatory MFA for all access significantly raises the cost of these attacks.