PCI DSS v4.0: The Complete Guide to Future-Dated Requirements

What 'Future-Dated' Means in PCI DSS v4.0

When the PCI Security Standards Council (PCI SSC) released PCI DSS v4.0 in March 2022, it introduced a transition mechanism that had not been used in previous major versions. Certain new requirements were designated as "best practice until March 31, 2025." This meant organizations were encouraged to implement them immediately but would not be assessed against them until after that date.

As of March 31, 2025, every future-dated requirement is now mandatory. There is no additional grace period. Qualified Security Assessors (QSAs) are required to evaluate these requirements during assessments, and non-compliance will result in findings.

The rationale for the phased approach was practical: many of the future-dated requirements demand significant technical and operational changes. The PCI SSC gave organizations roughly three years to plan, budget, and implement. That runway has now closed.

Organizations that deferred these requirements are in a difficult position. They must now implement the changes under assessment pressure rather than at their own pace. Those that treated the future-dated period as a planning window, not a deferral period, are in much better shape.

Targeted Risk Analysis (Requirement 12.3.1)

One of the most consequential future-dated requirements is the formalization of targeted risk analysis (TRA). Under PCI DSS v4.0, any requirement that allows organizations to define their own frequency or approach, rather than prescribing a fixed interval, must be supported by a documented targeted risk analysis.

What this means in practice:

PCI DSS v4.0 introduced flexibility in several areas where v3.2.1 prescribed rigid timelines. For example, instead of mandating quarterly internal vulnerability scans for every environment, v4.0 allows organizations to determine scanning frequency based on risk. However, this flexibility comes with a documentation requirement: you must perform a formal targeted risk analysis that justifies the frequency you chose.

A targeted risk analysis under Requirement 12.3.1 must include:

• Identification of the assets being protected and the threats to those assets
• Analysis of the likelihood and impact of each identified threat
• Justification for the frequency or approach chosen based on the analysis
• Approval by management responsible for the area being assessed
• Review at least once every 12 months, and upon significant changes to the environment

Common pitfall: Many organizations assumed they could simply document "we chose quarterly because that is what we always did" and satisfy the requirement. That is not sufficient. The TRA must demonstrate actual analysis, not just restate the previous default. Assessors are looking for evidence that the organization evaluated its specific threat landscape and made a deliberate, risk-informed decision.

Where TRA applies: Requirement 12.3.1 is referenced throughout the standard. Any requirement that includes language like "at the frequency defined in the entity's targeted risk analysis" requires a corresponding TRA. This affects log review frequency, security awareness training cadence, password change intervals, vulnerability scanning schedules, and more.

Organizations need a repeatable TRA methodology and should consider building a TRA template that can be applied consistently across all applicable requirements. The Budget Planner can help estimate the effort involved in standing up this process.

Authenticated Vulnerability Scanning (Requirement 11.3.1.2)

PCI DSS v4.0 now requires that internal vulnerability scans be performed with authentication. This is a significant departure from v3.2.1, where unauthenticated scanning was common practice for many organizations.

Why this matters:

Unauthenticated vulnerability scans only see what an external attacker without credentials would see. They miss a large class of vulnerabilities that are only detectable when the scanner can log in to the system, read configuration files, check installed software versions, and inspect settings that are not exposed on network-facing services.

Industry data consistently shows that authenticated scans detect 40-60% more vulnerabilities than unauthenticated scans of the same environment. The PCI SSC recognized this gap and made authenticated scanning mandatory for internal scans.

Implementation requirements:

• Internal vulnerability scans must use credentials sufficient to identify vulnerabilities at the system level (operating system, installed software, configuration settings)
• Where authenticated scanning is not technically feasible for a particular system, the entity must document the systems excluded and the reasons, and implement additional controls to compensate
• Scan credentials must be managed securely; scanning accounts should follow least-privilege principles and their credentials should be stored and rotated according to the organization's credential management policies

Common implementation challenges:

Credential management at scale is the primary obstacle. Organizations with hundreds or thousands of systems need a systematic approach to provisioning, distributing, and rotating scan credentials. Many scanning tools support credential vaults and API-based credential retrieval, which reduces the operational burden.

Legacy systems that do not support standard authentication mechanisms present another challenge. For these systems, organizations must document the limitation and implement compensating controls, such as more frequent manual reviews or enhanced monitoring.

Testing scan coverage is critical. After implementing authenticated scanning, compare the results against previous unauthenticated scans to verify that the additional depth is being achieved. If authenticated scans are not returning significantly more findings, the credentials may not have sufficient access. Organizations that combine authenticated vulnerability scanning with regular penetration testing gain the most complete picture of their security posture.

Web Application Firewall Requirements (Requirement 6.4.2)

Requirement 6.4.2 mandates that all public-facing web applications must be protected by an automated technical solution that continuously detects and prevents web-based attacks. In practice, this means deploying a web application firewall (WAF) or equivalent technology.

What changed from v3.2.1:

PCI DSS v3.2.1 (Requirement 6.6) offered a choice: deploy a WAF in front of public-facing web applications, or conduct application vulnerability assessments at least annually. That either/or option no longer exists. Under v4.0, a WAF or equivalent automated solution is required regardless of whether you also perform application security testing.

Requirements for the solution:

• Must be installed in front of all public-facing web applications
• Must detect and prevent web-based attacks, at minimum covering the OWASP Top 10 attack categories
• Must be actively running, configured to either block attacks or generate alerts that are immediately investigated
• Must be kept current with threat intelligence and updated to address new vulnerabilities
• Configuration must be reviewed at least once every 12 months

Implementation considerations:

Cloud-native WAF services (AWS WAF, Azure WAF, Cloudflare WAF) have lowered the barrier to entry significantly. Most can be deployed in front of web applications within hours and include managed rule sets that cover the OWASP Top 10 out of the box.

The more challenging aspect is tuning. A WAF that generates excessive false positives will be bypassed by operations teams or set to detection-only mode, neither of which satisfies the requirement. Invest time in tuning rule sets against your specific application traffic patterns before switching to blocking mode.

Organizations with complex web application architectures (microservices, APIs, single-page applications with backend APIs) need to ensure coverage extends to all public-facing endpoints, not just the primary web application. API gateways with WAF capabilities may be needed alongside traditional WAF deployments.

Custom-built web applications that use non-standard protocols or content types may require additional WAF configuration. Test thoroughly after deployment to confirm that legitimate application functionality is not impaired. Periodic penetration testing of your WAF configuration helps validate that rules are effective against real-world attack techniques, not just known signatures.

Encrypted Passwords and Multi-Factor Authentication Expansion

PCI DSS v4.0 introduced two significant changes to authentication requirements that took effect with the future-dated deadline.

Password/Passphrase Encryption in Transit and at Rest (Requirement 8.3.2)

All passwords and passphrases must be rendered unreadable during storage using strong, one-way hashing with a unique salt, and must be encrypted during transmission. While most modern applications already hash stored passwords, the explicit requirement for encryption during transmission catches organizations that transmit credentials over internal networks without TLS, use legacy protocols that send passwords in cleartext, or rely on network segmentation as a substitute for transport encryption.

Every authentication flow, including internal service-to-service authentication, LDAP binds, database connections, and API authentication, must encrypt credentials in transit. Assess your full authentication topology, not just user-facing login pages.

Multi-Factor Authentication for All CDE Access (Requirement 8.4.2)

PCI DSS v3.2.1 required MFA for remote access and administrative access to the cardholder data environment (CDE). PCI DSS v4.0 expands this to require MFA for all access to the CDE, including local, on-premises access by all personnel.

This expansion affects:

• Administrators accessing CDE systems from within the corporate network
• Application support staff who connect to CDE databases or servers
• Operations personnel who manage CDE infrastructure
• Any individual, including third parties, who access CDE components for any reason

Implementation requirements for MFA:

• Must use at least two of the three standard authentication factor categories (knowledge, possession, inherence)
• The authentication factors must be independent; compromise of one factor must not affect the integrity of the other
• MFA must be applied at the system or application level; network-level MFA (VPN) does not satisfy the requirement if users can then access CDE systems without additional authentication
• Replay resistance and session binding are expected of modern MFA implementations

Common challenges:

Legacy systems within the CDE that do not natively support MFA require compensating controls or architectural changes. Options include deploying a privileged access management (PAM) solution that enforces MFA before proxying connections, or replacing legacy systems with MFA-capable alternatives.

Service accounts present a nuanced challenge. While service-to-service authentication is generally handled through certificates or API keys rather than interactive MFA, organizations must ensure that no interactive access to CDE systems bypasses MFA requirements.

Additional Future-Dated Requirements Worth Noting

Beyond the headline items, several other future-dated requirements demand attention:

Requirement 5.3.3 -- Anti-malware for removable media: Anti-malware solutions must be configured to perform automatic scans when removable electronic media is inserted, connected, or logically mounted. Organizations that allow USB devices in CDE environments need to enforce this technically, not just through policy.

Requirement 5.4.1 -- Anti-phishing mechanisms: Technical controls must be in place to detect and protect personnel against phishing attacks. This goes beyond security awareness training (which remains required) and demands email filtering, URL analysis, domain authentication (DMARC, DKIM, SPF), and similar automated protections.

Requirement 6.3.2 -- Software inventory: Organizations must maintain an inventory of bespoke and custom software, including third-party components, to facilitate vulnerability and patch management. This is essentially a software bill of materials (SBOM) requirement, and it must be kept current.

Requirement 10.7.2 -- Failures of critical security controls: Failures of critical security control systems must be detected, alerted, reported, and addressed promptly. This requires monitoring of log collection mechanisms, IDS/IPS, file integrity monitoring, anti-malware, access controls, network segmentation controls, and audit log review mechanisms. If any of these stop functioning, the organization must have automated detection and a defined response process.

Requirement 11.6.1 -- Payment page tamper detection: E-commerce merchants must implement a mechanism to detect unauthorized modifications to the HTTP headers and content of payment pages as received by the consumer's browser. This addresses supply chain attacks like Magecart, where attackers inject skimming scripts into payment pages. Solutions include Content Security Policy (CSP) headers, Subresource Integrity (SRI) tags, and specialized client-side security monitoring tools.

Requirement 12.6.3.1 -- Security awareness training content: Security awareness programs must address threats and vulnerabilities relevant to the entity's environment, including phishing, social engineering, and evolving attack techniques. Training content must be reviewed and updated at least annually. Generic, checkbox training programs no longer suffice.

Timeline of PCI DSS v4.0 Milestones

Understanding where we are in the PCI DSS v4.0 lifecycle helps contextualize current obligations:

March 2022: PCI DSS v4.0 published. Organizations begin evaluating changes.

March 2024: PCI DSS v3.2.1 officially retired. All assessments must be conducted against v4.0. The v4.0.1 minor revision was released to correct errata and clarify guidance.

March 31, 2025: All future-dated requirements become mandatory. QSAs must assess organizations against the complete v4.0 requirement set.

Ongoing (2025-2026): First full assessment cycle under the complete v4.0 standard. Assessors evaluate future-dated requirements for the first time in formal assessments. Expect QSAs to pay close attention to targeted risk analyses, authenticated scanning evidence, and MFA deployment scope.

2026 and beyond: The PCI SSC has signaled that a v4.1 revision is under consideration to incorporate lessons learned from initial v4.0 assessments. The Regulatory Radar tracks emerging updates.

Organizations currently in their assessment window should prioritize closing any remaining gaps in future-dated requirements. Those approaching their next assessment should conduct a gap assessment immediately to identify areas where implementation work is still needed. If your organization also maintains a SOC 2 report, our guide on SOC 2 for Startups covers strategies for managing multiple compliance frameworks efficiently.

How to Prepare: A Practical Roadmap

Whether you are fully compliant with the future-dated requirements or still closing gaps, a structured approach prevents wasted effort and assessment surprises.

1. Gap assessment against the full v4.0 requirement set. Compare your current state against every requirement, including former future-dated items. Prioritize gaps by assessment timeline (when is your next assessment?) and implementation complexity.

2. Build your targeted risk analysis library. Identify every requirement in v4.0 that references a targeted risk analysis. Create TRA documentation for each one using a consistent methodology. This is often the fastest way to close multiple gaps with a single operational investment.

3. Validate authenticated scanning coverage. Run authenticated vulnerability scans across your CDE and compare results against previous unauthenticated scans. Verify that credential access is sufficient to detect system-level vulnerabilities. Document any systems excluded from authenticated scanning and the compensating controls in place.

4. Verify WAF deployment and configuration. Confirm that all public-facing web applications and APIs are behind a WAF or equivalent solution. Review rule sets, tuning, and logging. Ensure the solution is in blocking mode (not just detection) and that rules are updated regularly.

5. Audit MFA deployment scope. Map every access path to CDE systems and verify that MFA is enforced for each one. Pay special attention to local access, database connections, and administrative tools that may have been excluded under v3.2.1 requirements.

6. Review authentication architecture. Verify that all credential transmission is encrypted, including internal service-to-service authentication. Audit password storage mechanisms for proper hashing and salting.

7. Engage your QSA early. Do not wait for the formal assessment to discover gaps. Schedule a pre-assessment readiness review with your QSA to identify any interpretation differences before they become findings.

Top Floor provides PCI DSS readiness assessments and remediation support tailored to v4.0's expanded requirements. For organizations managing PCI DSS alongside other frameworks, our Compliance as a Service offering handles cross-framework control mapping and ongoing evidence management. Use the Budget Planner to scope your compliance investment, or contact our team to discuss your assessment timeline.

Related Reading

Compliance does not end with PCI DSS. These articles cover related frameworks and strategies that strengthen your overall security and compliance posture:

• SOC 2 for Startups in 2026 -- Many organizations that process cardholder data also need SOC 2 reports for their customers. This guide covers how to get SOC 2 ready without derailing your business.
• Penetration Testing Beyond Compliance -- PCI DSS v4.0 raises the bar on security testing requirements. Learn how to get strategic value from your penetration testing program, not just a checkbox.
• Virtual CISO Guide -- For organizations without a full-time security leader, a vCISO can drive PCI DSS compliance alongside your broader security strategy.

Need help closing PCI DSS v4.0 gaps before your next assessment? Contact Top Floor to schedule a readiness review.