PCI DSS 4.0 Compliance Technical Guide: What Changed, New Requirements, and Implementation Priorities

PCI DSS 4.0 introduced changes across all 12 requirements, but the most significant technical changes are concentrated in Requirement 6 (application security), Requirement 8 (authentication), and Requirement 11 (testing).

Philosophy changes: The most important conceptual change in 4.0 is the introduction of the Customized Approach, which allows organizations to meet the intent of a requirement through alternative controls rather than the prescribed defined approach. This addresses a longstanding criticism of PCI DSS: prescriptive requirements that do not accommodate modern architectures and lead to technical debt as organizations implement specific legacy controls to satisfy literal requirement text.

Requirement 8 (Authentication) - Major changes:

• MFA is now required for all access into the cardholder data environment (CDE), not just remote access. This significantly expands MFA scope for organizations that previously only required MFA for VPN or external access.
• Service accounts, application accounts, and system accounts must be reviewed annually and managed with documented justification for their need
• Password requirements updated: minimum 12 characters (up from 7), requiring numeric and alphabetic characters. Historical password requirements (no reuse of last 4 passwords) strengthened.
• Phishing-resistant authentication mechanisms (FIDO2, certificate-based authentication) are recommended for user accounts in the CDE

Requirement 6 (Application Security) - Major changes:

• Requirement 6.4.1-6.4.3: New requirements for managing scripts on payment pages (e.g., JavaScript on e-commerce checkout pages). Organizations must maintain an inventory of all scripts on payment pages, implement a method to confirm script integrity (Subresource Integrity), and maintain a policy addressing changes to scripts.
• Requirement 6.3.2: Maintain an inventory of bespoke and custom software components, with a process to identify and address new vulnerabilities
• Requirement 6.5: Deploy automated technical solutions for protection against common web attacks (OWASP Top 10) or conduct manual security reviews equivalent to automated WAF functionality

Requirement 11 (Testing) - Major changes:

• Internal vulnerability scans now must be performed using authenticated scanning
• Penetration tests must now include testing of all network segmentation controls (segmentation testing)
• New requirement: deploy automated mechanisms to detect and protect against phishing attacks targeting users in the CDE

The expansion of MFA requirements to all access into the CDE is the single most operationally challenging change in PCI DSS 4.0 for most organizations. Understanding the scope and implementation options is essential for compliance planning.

Who is affected:

• All users accessing the CDE: system administrators, application developers with production access, security team members accessing CDE logs, support staff accessing cardholder data
• All access methods: direct console access, remote desktop, SSH, web application access, API access with human-in-the-loop
• Service accounts are subject to separate controls but not to MFA per se (MFA is designed for human authentication)

What counts as MFA: PCI DSS 4.0 defines MFA as using at least two of: something you know (password/PIN), something you have (hardware token, authenticator app), something you are (biometric). Software OTP authenticators (Google Authenticator, Microsoft Authenticator) satisfy the "something you have" factor. Hardware FIDO2 keys satisfy both "something you have" and provide phishing resistance.

Implementation options by access type:

Windows Server/desktop access: Require MFA for RDP access using Windows Hello for Business, Duo Security RDP gateway, or CyberArk with MFA integration. For domain-joined systems, configure Conditional Access policies requiring MFA for CDE-scoped systems.

SSH access to Linux systems: Deploy SSH certificate-based authentication with a CA that requires MFA for certificate issuance, or integrate SSH access through a PAM solution (CyberArk, BeyondTrust, HashiCorp Vault) that enforces MFA at the session checkout stage.

Web application access: Require MFA through your identity provider (Okta, Entra ID, Ping) with Conditional Access policies scoped to CDE applications. SAML or OIDC federation with MFA enforcement at the IdP satisfies Requirement 8.4 for web access.

Database access: Direct database connections from human users must go through an authenticated gateway (PAM session broker, bastion host with MFA) rather than direct connection strings. This is often the highest-effort implementation because legacy database workflows may rely on direct connections that must be re-architected.

Documentation requirements: Document the MFA implementation for each access type, including: which MFA factors are accepted, how MFA is enforced at the access control point, and how the control would be tested. This documentation is required evidence for QSA assessment.

Requirements 6.4.1 through 6.4.3 address a real attack vector: JavaScript injection on payment pages (Magecart-style attacks) that capture payment card data before it reaches the merchant's payment processor. These requirements apply specifically to organizations with payment pages hosted on their own infrastructure.

6.4.1: Payment page script inventory Maintain a documented inventory of all scripts loaded on payment pages. For each script, document: the script name, version, source URL or hosting location, business justification for the script's presence on the payment page, and the method used to verify the script's integrity.

Practical implementation: conduct a scan of your payment page HTML and all embedded resources. Document every JavaScript file loaded, including third-party scripts from analytics providers, A/B testing tools, chat widgets, and tag managers. Reduce third-party script exposure on payment pages to the minimum necessary for payment processing.

6.4.2: Method to confirm script authorization For each script on the payment page, implement a method to verify it has not been tampered with. Options:

• Subresource Integrity (SRI): Add integrity attributes to <script> tags that load third-party scripts. The browser verifies the script hash matches the declared value before executing.

<script src="https://cdn.example.com/payment.js"
  integrity="sha384-[hash_value]"
  crossorigin="anonymous">
</script>

• Content Security Policy (CSP): Implement a strict CSP header that allows script execution only from explicitly whitelisted sources. Use nonce-based CSP for inline scripts.
• Script monitoring: Deploy a client-side script monitoring solution (Reflectiz, Featurespace, PerimeterX) that detects new or modified scripts on payment pages in real time.

6.4.3: Script change management Establish a documented process for authorizing, reviewing, and deploying changes to payment page scripts. Any new script addition or modification to an existing script must go through a formal change approval process that includes security review. Unauthorized scripts detected by monitoring must trigger an incident response workflow.

6.3.2: Bespoke software inventory Maintain an inventory of all custom-developed and third-party software components (libraries, dependencies) used in payment applications. For each component, document the current version, known vulnerabilities, and the process for receiving and acting on vulnerability notifications. This requirement drives SBOM (Software Bill of Materials) adoption for payment application development teams.

PCI DSS 4.0 strengthened several testing requirements, with particular impact on penetration testing scope and vulnerability scanning methodology.

Requirement 11.3: Penetration testing PCI DSS has always required annual penetration testing and testing after significant changes. Version 4.0 adds:

Segmentation testing: Organizations using network segmentation to reduce PCI scope must test segmentation controls at least every 6 months and after any changes to segmentation. The test must verify that systems outside the CDE cannot reach systems inside the CDE through the segmentation controls. This is a significant operational requirement for organizations that define their CDE narrowly based on network segmentation.

External vs internal pen test distinction: Requirements now explicitly require both external (from an external network perspective) and internal (from within the internal network) penetration testing. Many organizations previously conducted only external testing; 4.0 makes internal testing mandatory.

Penetration testing methodology: The testing must cover the application layer (OWASP testing guide methodology), network layer, and the CDE boundary. Test reports must include: test scope, methodology, findings, and evidence of remediation for vulnerabilities identified.

Requirement 11.3.1.1: Authenticated internal vulnerability scanning Internal vulnerability scans must now use authenticated scanning that provides the scanner with valid credentials to assess each target system. Unauthenticated scanning produces significantly fewer findings and misses the vast majority of host-based vulnerabilities. This requirement aligns with industry best practice that most organizations should already be following.

Requirement 11.6.1: Payment page change detection New requirement (was future-dated, mandatory from March 2025): deploy a mechanism to detect unauthorized changes to payment pages. This overlaps with the 6.4.x script monitoring requirements. Solutions: client-side script monitoring tools, server-side change detection (comparing page content against a known-good baseline), or web application firewall rules that alert on new script injections.

QSA vs SAQ implications: For merchants using SAQ (Self-Assessment Questionnaire) rather than QSA-led assessments, the applicable SAQ type determines which Requirement 11 controls apply. SAQ A merchants (card data fully outsourced to a third party) have minimal Requirement 11 obligations. SAQ D merchants (full data environment) must satisfy all Requirement 11 controls.

The Customized Approach is PCI DSS 4.0's most significant structural innovation, allowing organizations to implement alternative controls that meet the security objective of a requirement rather than the prescriptive defined approach.

When to consider the Customized Approach: The Customized Approach is appropriate when: your existing architecture or technology stack achieves the requirement's security objective through a different mechanism than the defined approach prescribes, implementing the defined approach would require rearchitecting working security controls that already provide equivalent or superior protection, or your organization has mature security controls that exceed the defined approach in specific areas.

The Customized Approach is not:

• A risk acceptance mechanism for non-compliance
• An easier path to compliance than the defined approach
• Available for use without QSA review and documentation

Customized Approach documentation requirements: For each requirement addressed via Customized Approach, the organization must produce:

1. A Customized Approach Objective Statement describing the security objective the control must achieve
2. A Controls Matrix detailing the specific controls implemented and how they achieve the security objective
3. A Testing Procedure describing how the effectiveness of the controls can be tested
4. Evidence that the controls are operating as designed

The QSA must review and validate Customized Approach controls independently. The QSA cannot simply accept the organization's assertion that the controls are equivalent.

Practical examples of Customized Approach use:

• An organization using hardware security keys (FIDO2) exclusively for CDE authentication may use the Customized Approach to demonstrate that their phishing-resistant MFA exceeds the defined approach's requirements while implementing it differently than specified
• An organization with an extensive runtime application self-protection (RASP) deployment may use Customized Approach for Requirement 6.4 web application security requirements, demonstrating that RASP provides equivalent or superior coverage to a WAF

Should you use Customized Approach? For most organizations, the defined approach is simpler to implement, document, and audit. The Customized Approach adds significant documentation overhead and requires QSA validation of the alternative controls methodology. Use it only when the defined approach requires implementing controls that would genuinely degrade your security posture or create significant architectural disruption without commensurate security benefit.

Over 90 percent of merchants use Self-Assessment Questionnaires (SAQs) rather than QSA-led assessments. Selecting the right SAQ type and reducing scope through tokenization and hosted payment pages are the primary compliance burden management strategies.

SAQ types and their applicability:

SAQ A: For merchants who have fully outsourced all cardholder data functions to PCI DSS-validated third parties. Payment pages are fully hosted by the third party (iframe or redirect); the merchant's systems never touch card data. Only 22 requirements. This is the lowest-compliance-burden option for e-commerce merchants.

SAQ A-EP: For e-commerce merchants who redirect customers to a third-party payment processor but have a script running on the checkout page that affects the payment page security (even indirectly). The 6.4.x script security requirements apply. More requirements than SAQ A.

SAQ B: For merchants using imprint machines or standalone dial-out terminals not connected to any other system. Limited applicability in 2025.

SAQ B-IP: For merchants using IP-connected standalone payment terminals that are isolated from other systems. Limited scope.

SAQ C: For merchants whose payment application is connected to the internet but not storing cardholder data. Moderate scope.

SAQ D (Merchant): For merchants storing cardholder data or not qualifying for other SAQ types. Full requirement set applies. Significant compliance burden.

SAQ D (Service Provider): For service providers storing, processing, or transmitting cardholder data on behalf of merchants. Full requirement set with additional service provider requirements.

Scope reduction via tokenization: Replacing primary account numbers (PANs) with tokens in internal systems removes those systems from PCI scope, potentially allowing a downgrade from SAQ D to a lower-scope SAQ type. Evaluate tokenization at the payment gateway level: modern payment gateways return a token rather than the PAN after authorization, eliminating the need for any internal systems to process or store actual card numbers.

Scope reduction via payment page outsourcing: Migrating to a hosted payment page or iframe-based checkout where the payment page is fully hosted and rendered by a PCI DSS-certified third party removes the merchant's web servers from CDE scope and typically qualifies the merchant for SAQ A, reducing compliance requirements by over 80 percent.