PCI DSS v4.0: What Changed and How to Prepare

PCI DSS v4.x represents the most significant overhaul of the Payment Card Industry Data Security Standard since its inception. Released by the PCI Security Standards Council (PCI SSC) in March 2022, v4.0 replaced PCI DSS v3.2.1 as the mandatory standard on March 31, 2024. But the real compliance cliff arrived on March 31, 2025 — when the "future-dated" requirements that were previously best practices became mandatory for all assessments. Note that PCI DSS v4.0.1 (June 2024) is now the only active version, having superseded v4.0 when v4.0 retired on March 31, 2025. If your organization processes, stores, or transmits cardholder data and you have not addressed these requirements, you are now operating out of compliance.

This guide breaks down what changed, what the future-dated requirements actually demand, and how to approach compliance from a practitioner's perspective — not a checkbox auditor's perspective. At Fortress MSSP, we conduct network penetration testing and web application security assessments for organizations subject to PCI DSS. What follows reflects real-world implementation experience, not theoretical compliance guidance.

What Changed From PCI DSS v3.2.1 to v4.0

PCI DSS v4.x introduced 64 new requirements — 13 effective immediately at the March 2024 transition and 51 future-dated requirements that became mandatory on March 31, 2025 (of the 64, roughly 11 apply only to service providers). The structural philosophy shifted in three fundamental ways:

• Outcome-based requirements: v4.0 moves away from prescriptive "do X" mandates toward "achieve Y outcome." This gives organizations flexibility but also requires demonstrating that your approach actually achieves the security objective — not just that you followed a script.
• Customized approach: Organizations can now satisfy requirements using alternative controls if they can demonstrate equivalent or superior security through a customized validation. This replaces the old compensating controls framework with something more rigorous.
• Continuous compliance: v4.0 explicitly requires that security controls are maintained continuously, not just validated once per year at assessment time. Requirement 12.3.2 mandates targeted risk analyses to determine the frequency of periodic activities — no more defaulting to "annual" for everything.

Key Timeline

• March 2022: PCI DSS v4.0 published
• March 31, 2024: v3.2.1 retired; v4.0 becomes mandatory
• March 31, 2025: All future-dated requirements become mandatory

If you completed your last assessment under v3.2.1 before March 2024, your next assessment must be conducted entirely under v4.0 — including all future-dated requirements that are now in full effect.

The Future-Dated Requirements: What Became Mandatory in March 2025

The future-dated requirements represent the most operationally demanding changes in v4.0. These are the requirements that organizations had two years to implement and are now fully enforceable. Here are the ones that cause the most compliance failures in practice:

Authenticated Internal Vulnerability Scanning (Req. 11.3.1.2)

This is the single requirement that catches the most organizations off guard. Previously, internal vulnerability scans could be unauthenticated — essentially a network-level port scan with service fingerprinting. v4.0 now requires authenticated scanning, meaning your vulnerability scanner must log into target systems to evaluate installed software versions, configurations, missing patches, and local vulnerabilities that are invisible from the network layer.

The practical impact is significant. Unauthenticated scans see a host only from the outside, so they miss vulnerabilities that are exposed only once you have valid credentials — missing OS and application patches, insecure local configurations, and outdated client-side software. Authenticated (credentialed) scans log in to each host and inspect installed packages, patch levels, and configuration directly, producing a substantially more complete and accurate vulnerability picture. That gap is precisely what attackers exploit after gaining initial access, which is why credentialed internal scanning is the expected baseline under PCI DSS v4.0.1 (Req. 11.3.1.2). You need credentialed scan policies for Windows (domain or local admin), Linux (root or sudo-capable), network devices (privileged EXEC), and databases. This requires coordination with system administrators, credential management, and scan account hardening to prevent those credentials from becoming an attack vector themselves.

Web Application Firewall or Equivalent (Req. 6.4.2)

v4.0 requires that all public-facing web applications are protected by a web application firewall (WAF) or an equivalent automated technical solution that detects and prevents web-based attacks. This was a best practice under v3.2.1 — it is now mandatory. The WAF must be actively running, configured to block or generate alerts, and kept current with threat intelligence.

The "or equivalent" language is important. The PCI SSC recognizes that a WAF is not the only way to protect web applications, but the alternative must provide equivalent detection and prevention capabilities. In practice, most QSAs expect to see a WAF deployed. If you are running an alternative solution, be prepared to justify it thoroughly during your assessment. Our web application security engagements frequently include WAF validation — testing whether the WAF actually blocks the attacks it claims to detect.

Multi-Factor Authentication for All CDE Access (Req. 8.4.2)

v3.2.1 required MFA only for remote access into the cardholder data environment (CDE) and for non-console administrative access. v4.0 expands this to all access into the CDE, including local console access and access from within the internal network. Every user — administrators, application service accounts with interactive login capability, and operators — must authenticate with MFA when accessing CDE systems.

This has major architectural implications. Organizations that relied on network segmentation plus single-factor authentication for internal CDE access must now deploy MFA infrastructure that covers those access paths. Solutions include RADIUS/TACACS+ integration for network devices, PAM (Privileged Access Management) solutions for servers, and conditional access policies for application-layer access. Service accounts that require interactive login are not exempt — though accounts that only perform machine-to-machine communication without interactive login are excluded.

Targeted Risk Analysis (Req. 12.3.1)

This is a philosophical shift in how PCI DSS defines "periodic." Under v3.2.1, most periodic requirements defaulted to annual or quarterly cadences. v4.0 requires a targeted risk analysis (TRA) to justify the frequency of each periodic activity. If your vulnerability scanning is quarterly but your risk profile suggests monthly is appropriate, you need to document why quarterly is sufficient — or increase your cadence.

The TRA must be documented, approved by management, and performed at least annually (or when the environment changes significantly). It must identify the assets and threats relevant to the requirement, evaluate the likelihood and impact of threats, and justify the frequency based on that analysis. Generic risk assessments do not satisfy this — the analysis must be targeted to each specific requirement where frequency is determined by the entity. Our NIST Cybersecurity Framework implementation guide covers risk analysis fundamentals that directly apply here.

Automated Log Review Mechanisms (Req. 10.4.1.1)

Manual log review was acceptable under v3.2.1. v4.0 now requires automated mechanisms to perform audit log reviews. This means SIEM deployment, log aggregation with correlation rules, or equivalent automated analysis. Your QSA will ask to see the automated review configurations, the alerting rules, and evidence that alerts are investigated and resolved. The days of a quarterly log review spreadsheet are over.

Payment Page Script Management (Req. 6.4.3)

This requirement directly addresses Magecart-style attacks — malicious JavaScript injected into payment pages to skim cardholder data. v4.0 requires that all scripts loaded on payment pages are managed: inventoried, authorized, integrity-verified. You must maintain a list of all scripts executing on your payment pages, justify why each script is needed, and implement a mechanism to detect unauthorized modifications. Content Security Policy (CSP) headers, Subresource Integrity (SRI) attributes, and commercial script monitoring solutions all address this requirement.

Scope Reduction Through Network Segmentation

The single most effective strategy for reducing PCI DSS compliance burden is scope reduction through network segmentation. Every system that connects to, processes, or could impact the security of the CDE is in scope. Without segmentation, your entire network is in scope — every workstation, every server, every printer.

Effective segmentation requires more than VLANs. PCI DSS v4.0 requires that segmentation controls are validated through penetration testing at least annually (Req. 11.4.5) — and every six months for service providers (Req. 11.4.6). The penetration test must specifically validate that segmentation controls prevent out-of-scope networks from accessing the CDE. This is not a vulnerability scan — it is an active attempt to bypass your segmentation controls. If a penetration tester can pivot from an out-of-scope VLAN into your CDE, your segmentation has failed and your scope expands accordingly.

Practical segmentation architectures typically involve:

• Dedicated CDE VLAN(s) with firewall-enforced boundaries — not just ACLs on a Layer 3 switch
• Jump servers / bastion hosts as the sole administrative entry point into CDE systems, with MFA enforced
• Microsegmentation within the CDE to limit lateral movement between cardholder data processing systems
• Out-of-band management networks for CDE device administration, physically or logically separated from production traffic
• Explicit deny-all egress rules from the CDE, with specific allowlisting for required business communication

Our architecture hardening practice frequently helps organizations design and validate segmentation architectures that withstand both QSA scrutiny and actual penetration testing.

Encryption Requirements

PCI DSS v4.0 maintains and strengthens encryption requirements across two domains:

Data in Transit

Requirement 4.2.1 mandates strong cryptography for PAN (Primary Account Number) transmission over open, public networks. v4.0 clarifies that TLS 1.2 is the minimum acceptable version, with TLS 1.3 recommended. SSL and early TLS (1.0, 1.1) are explicitly prohibited. Certificates must be valid, current, and signed by a trusted CA. Self-signed certificates in production CDE environments will result in a finding.

Data at Rest

Requirement 3.5.1 mandates that stored PAN is rendered unreadable using strong cryptographic algorithms (AES-256, RSA 2048+) with proper key management. v4.0 adds requirement 3.5.1.2, which mandates disk-level or partition-level encryption for PAN storage only on removable media — for fixed storage (servers, SANs), disk encryption alone is not sufficient. You need database-level, column-level, or application-level encryption. This catches organizations that relied solely on BitLocker or LUKS full-disk encryption for their database servers.

Key Management

Cryptographic key management (Req. 3.6 and 3.7) remains one of the most commonly failed requirement areas. Keys must be generated using strong random number generators, stored securely with strict access controls, rotated at the end of their defined cryptoperiod, and retired/replaced when integrity is suspected to be compromised. Split knowledge and dual control for key management operations are mandatory. Document your key management procedures thoroughly — QSAs audit this aggressively.

Vulnerability Management Cadence

v4.0 changes the vulnerability management game in several ways:

• Internal vulnerability scans: At least quarterly and after significant changes, with authenticated scanning now mandatory (Req. 11.3.1.2)
• External vulnerability scans: Quarterly by an ASV (Approved Scanning Vendor), with passing results required (Req. 11.3.2)
• Critical and high-severity vulnerabilities: Must be addressed based on the targeted risk analysis, but the expectation is remediation within 30 days for critical and within a risk-justified timeframe for high. v4.0 no longer prescribes a fixed remediation window — your TRA determines it, but it must be defensible.
• Penetration testing: Internal and external penetration testing at least annually and after significant changes (Req. 11.4). Service providers must test every six months. Segmentation validation must be included.

The shift to authenticated scanning is operationally significant. If you are not already running credentialed scans, expect your vulnerability counts to increase dramatically when you transition — and plan your remediation capacity accordingly. See our cybersecurity ROI guide for frameworks on justifying the additional tooling and staffing investment.

The Customized Approach

PCI DSS v4.0 introduces the customized approach as a formal alternative to the defined approach (following the requirement as written). Under the customized approach, an organization can implement an alternative control that meets the stated objective of the requirement, even if it does not follow the specific prescribed method.

This is not a loophole. The customized approach requires:

• A documented customized approach objective
• A detailed description of the controls implemented
• A risk analysis demonstrating that the alternative achieves equal or greater security
• Validation by the QSA, who must independently test the control's effectiveness
• More documentation, not less — the customized approach matrix must be completed for each requirement

In practice, the customized approach is most useful for organizations with mature security programs that have implemented controls exceeding PCI DSS minimums but in architecturally different ways. It is not appropriate for organizations struggling to meet baseline requirements. Your QSA must agree that the customized approach is viable for each specific requirement — they have the authority to reject it.

Service Provider-Specific Requirements

Service providers face additional requirements under v4.0 that do not apply to merchants:

• Penetration testing every six months (Req. 11.4.6) — not annually
• Segmentation validation every six months (Req. 11.4.5) — not annually
• Intrusion detection/prevention on all inbound and outbound traffic (Req. 11.5.1.1)
• Failures of critical security controls must be detected and responded to promptly (Req. 10.7.2) — automated alerting when security controls fail, with documented response procedures
• Support customer requests for MFA (Req. 8.5.1) — if you provide access to customer cardholder data environments, you must offer MFA

The six-month cadence for penetration testing and segmentation validation is particularly demanding. Service providers need to establish a continuous testing rhythm, not an annual project. This is where a dedicated penetration testing partner with PCI DSS experience becomes essential — you need consistent methodology, comparable results, and testing teams that understand your environment's evolution between assessments.

Practical Compliance Roadmap

If you are approaching PCI DSS v4.0 compliance — or remediating gaps discovered in your first v4.0 assessment — here is a prioritized approach based on where we see organizations fail most often:

Phase 1: Scope and Segment (Weeks 1-4)

• Map all cardholder data flows — ingestion, processing, storage, transmission, and destruction
• Identify every system, network segment, and third party that touches or could affect CHD
• Implement or validate network segmentation to minimize CDE scope
• Engage a penetration tester to validate segmentation controls

Phase 2: Authentication and Access (Weeks 3-6)

• Deploy MFA for all CDE access paths — remote, internal, console, administrative
• Implement password requirements: minimum 12 characters (PCI DSS v4.0.1 Req. 8.3.6, up from the prior 7-character minimum), complexity enforced
• Deploy PAM solution for privileged access with session recording
• Audit and remove unnecessary accounts and standing privileges

Phase 3: Vulnerability Management (Weeks 4-8)

• Deploy authenticated vulnerability scanning with credentialed policies for all in-scope platforms
• Establish remediation SLAs based on targeted risk analysis
• Schedule ASV external scans and address any failing results
• Commission internal and external penetration testing

Phase 4: Monitoring, Logging, and Detection (Weeks 6-10)

• Deploy SIEM or equivalent automated log analysis for all CDE systems
• Configure alerting for security events: authentication failures, privilege escalation, unauthorized access attempts
• Implement payment page script inventory and integrity monitoring (Req. 6.4.3)
• Deploy or validate WAF for all public-facing web applications in the CDE

Phase 5: Documentation and Risk Analysis (Weeks 8-12)

• Perform targeted risk analyses for all requirements with entity-determined frequency
• Document all policies, procedures, and standards — v4.0 expects role-specific security awareness training
• Complete the customized approach matrix for any requirements using alternative controls
• Conduct a pre-assessment gap analysis or engage your QSA for a readiness review

For a broader compliance perspective that complements PCI DSS, see our SOC 2 compliance checklist — many of the organizational controls overlap significantly.

Common Assessment Failures

Based on our penetration testing and compliance support engagements, these are the most frequent PCI DSS v4.0 findings:

• Insufficient segmentation: VLANs without firewall enforcement, overly permissive inter-VLAN routing, flat networks labeled as "segmented"
• Missing authenticated scanning: Organizations still running unauthenticated internal scans and treating them as compliant
• MFA gaps: MFA deployed for remote access but not for internal or console access to CDE systems
• Undocumented targeted risk analyses: Organizations defaulting to annual cadences without the required TRA documentation
• Payment page script sprawl: Third-party JavaScript on payment pages without inventory, authorization, or integrity verification
• Key management documentation gaps: Encryption deployed but key rotation schedules, split knowledge procedures, and key custodian assignments not documented
• WAF in detection-only mode: WAF deployed but configured to log, not block — QSAs will cite this as a finding

Getting Started

PCI DSS v4.0 compliance is not a project — it is an operational posture. The organizations that succeed treat it as continuous security improvement, not annual audit preparation. If you are unsure where your gaps are, start with a scoping exercise and segmentation validation. From there, prioritize the future-dated requirements that became mandatory in March 2025, because those are where QSAs are focusing their attention right now.

View our pricing for penetration testing, vulnerability management, and compliance support packages, or schedule a consultation to discuss your PCI DSS v4.0 compliance posture with our team. We bring practitioner-level expertise — experienced engineers who understand both the technical controls and the assessment process — to help you achieve and maintain compliance without the overhead of building it all in-house.