The Payment Card Industry Data Security Standard version 4.0 represents the most significant overhaul of payment security requirements in over a decade. Released by the PCI Security Standards Council in March 2022, PCI DSS v4.0 introduced sweeping changes to how merchants and service providers must protect cardholder data.
While PCI DSS v3.2.1 was officially retired on March 31, 2024, many of the new requirements in v4.0 were designated as future-dated, meaning organizations had additional time to implement them. That grace period ends on March 31, 2025. After that date, all v4.0 requirements become mandatory, and assessors will evaluate organizations against the complete standard.
If your organization has not yet completed the migration, this guide outlines what you need to address and how to prioritize the remaining work.
What Changed in PCI DSS v4.0
PCI DSS v4.0 is not an incremental update. It reflects a fundamental shift in how the PCI Council approaches payment security, moving from a prescriptive checkbox model toward a more flexible, risk-based framework.
The Customized Approach
One of the most significant changes is the introduction of the Customized Approach as an alternative to the traditional Defined Approach. Under the Customized Approach, organizations can meet security objectives using controls that differ from the standard requirements, provided they can demonstrate that their alternative approach achieves the same security outcome.
This is a major departure from previous versions, where compliance meant implementing specific, prescribed controls. The Customized Approach gives mature organizations flexibility but also demands more rigorous documentation and evidence.
Enhanced Authentication Requirements
PCI DSS v4.0 significantly strengthens authentication requirements. Multi-factor authentication is now required for all access to the cardholder data environment, not just remote access. Password requirements have been updated to reflect current best practices, with a minimum length of 12 characters for system-generated passwords and increased complexity requirements.
Targeted Risk Analysis
Several requirements now mandate targeted risk analyses to determine the frequency of specific security activities. Rather than prescribing that vulnerability scans must occur quarterly, for example, v4.0 requires organizations to conduct a risk analysis to determine the appropriate scanning frequency based on their threat landscape and risk profile.
Future-Dated Requirements You Must Complete
The following requirements were future-dated in v4.0 and become mandatory on March 31, 2025. These are the areas that require immediate attention.
Web Application Security (Requirement 6.4.3)
Organizations must implement a solution that detects and prevents web-based attacks against payment pages. This goes beyond traditional web application firewalls. The requirement specifically addresses client-side attacks, including script injection, formjacking, and Magecart-style skimming attacks.
To comply, you need a mechanism that monitors and controls the scripts executing on your payment pages. This may involve implementing a Content Security Policy, deploying client-side protection tools, or using subresource integrity to verify script integrity.
Script Management on Payment Pages (Requirement 6.4.2)
All scripts that load and execute on payment pages must be inventoried, authorized, and monitored. Each script must have a documented business justification, and an integrity mechanism must be in place to detect unauthorized modifications.
This requirement directly targets the growing threat of supply chain attacks through third-party scripts. If your payment pages load analytics, chat widgets, or advertising scripts, each one must be explicitly authorized and monitored.
Enhanced Logging and Monitoring (Requirement 10.7)
Organizations must implement automated mechanisms to detect and alert on failures of critical security control systems. This includes failures of intrusion detection systems, file integrity monitoring, anti-malware solutions, access control mechanisms, and audit logging systems.
The emphasis is on automated detection. Manual log review alone is no longer sufficient for monitoring the health of your security infrastructure.
Anti-Phishing Mechanisms (Requirement 5.4.1)
Organizations must implement automated anti-phishing mechanisms to protect personnel against phishing attacks. This includes deploying email filtering technologies, DMARC, DKIM, and SPF, as well as web-based anti-phishing protections.
Authenticated Vulnerability Scanning (Requirement 11.3.1.1)
Internal vulnerability scans must now be performed with authentication. Unauthenticated scans miss a significant percentage of vulnerabilities because they cannot see what is running behind login pages or on authenticated services. This requirement ensures that vulnerability assessments provide a more complete picture of your security posture.
Encryption of Sensitive Authentication Data (Requirement 3.5.1.2)
Disk-level or partition-level encryption is no longer acceptable as the sole method for protecting stored account data on removable electronic media. You must implement additional encryption layers or alternative controls to protect sensitive data beyond full-disk encryption.
Migration Priorities
With the March 2025 deadline approaching, organizations should prioritize their migration efforts based on complexity and risk.
Immediate Priority — Client-Side Security
Requirements 6.4.2 and 6.4.3 addressing payment page script management and web-based attack protection represent the most significant technical challenge for many merchants. These requirements may require deploying new security tools, inventorying third-party scripts, and implementing monitoring mechanisms that many organizations do not currently have.
High Priority — Authentication and Access
Expanding MFA to all CDE access and updating password policies are operationally intensive but well-understood activities. Begin with an inventory of all access points to your cardholder data environment and implement MFA systematically.
Medium Priority — Monitoring and Detection
Enhanced logging, automated alerting for control failures, and authenticated vulnerability scanning may require updates to your SIEM, vulnerability management tools, and monitoring infrastructure. Plan for tool upgrades and configuration changes.
Common Migration Challenges
Organizations migrating to PCI DSS v4.0 frequently encounter several challenges that can delay compliance.
Scope creep: The expanded requirements may bring systems and processes into scope that were previously excluded. Conduct a thorough scoping exercise before beginning your migration to avoid surprises.
Third-party dependencies: Many future-dated requirements depend on capabilities provided by payment processors, hosting providers, or security vendors. Engage your service providers early to understand their v4.0 compliance timelines and any changes to shared responsibilities.
Documentation gaps: The Customized Approach and targeted risk analysis requirements demand significantly more documentation than previous versions. Organizations that took a minimal documentation approach under v3.2.1 will need to invest time in building comprehensive documentation.
Resource constraints: The scope of changes in v4.0 may exceed the capacity of internal security teams. Consider engaging external consultants to supplement your team during the migration.
Maintaining Compliance Post-Migration
Completing the migration is not the end of the journey. PCI DSS v4.0 emphasizes continuous compliance over point-in-time assessments.
- Implement continuous monitoring: Move beyond annual assessments to ongoing security monitoring and control validation.
- Conduct targeted risk analyses: Regularly reassess the frequency and scope of security activities based on your evolving threat landscape.
- Update your SAQ or ROC documentation: Ensure your compliance documentation reflects v4.0 requirements and the controls you have implemented.
- Train your team: Ensure that personnel responsible for payment security understand the new requirements and their roles in maintaining compliance.
How eShield Consulting Supports PCI DSS v4.0 Migration
eShield Consulting provides end-to-end PCI DSS v4.0 migration support for merchants and service providers. Our consultants help organizations assess their current compliance posture against v4.0 requirements, identify gaps, and develop practical remediation plans.
We specialize in the technically complex aspects of v4.0 migration, including client-side payment page security, authenticated vulnerability scanning programs, and the documentation required for the Customized Approach. Our team has guided organizations across the United States, Australia, and the Middle East through successful PCI DSS transitions.
Frequently Asked Questions
When did PCI DSS v3.2.1 expire?
PCI DSS v3.2.1 was retired on March 31, 2024. All assessments conducted after that date must use PCI DSS v4.0.
What happens if I miss the March 2025 deadline for future-dated requirements?
After March 31, 2025, all v4.0 requirements are mandatory. Organizations that have not implemented the future-dated requirements will be found non-compliant during their next assessment. This can result in increased transaction fees, fines from card brands, and potential loss of the ability to process card payments.
Can I use the Customized Approach for all requirements?
The Customized Approach is available for most requirements, but some are excluded. Your Qualified Security Assessor can help you determine which requirements are eligible for the Customized Approach and whether it is appropriate for your organization.
Do I need new tools to comply with PCI DSS v4.0?
Many organizations will need to deploy additional tools, particularly for client-side payment page protection (Requirements 6.4.2 and 6.4.3), authenticated vulnerability scanning, and automated security control monitoring. Evaluate your current toolset against v4.0 requirements to identify gaps.
How does PCI DSS v4.0 affect e-commerce merchants?
E-commerce merchants face particular impact from the client-side security requirements. If your checkout process involves scripts executing in the customer’s browser, you must inventory, authorize, and monitor those scripts. This is a significant change for merchants who rely on third-party payment forms, analytics, or marketing scripts on their checkout pages.
