PCI DSS 4.0 went live in March 2024. If you process credit cards, you're now being assessed against a new standard—whether you're ready or not.
The Payment Card Industry Data Security Standard (PCI DSS) is the global security standard for any organization that stores, processes, or transmits cardholder data. Version 4.0 represents the most significant update since the standard was created, and it fundamentally changes how organizations approach payment card security.
Here's what actually changed, what's required now versus later, and the mistakes we're seeing organizations make.
TL;DR: The Biggest Changes
If you're short on time, here's what matters most:
- Authentication requirements are stricter. MFA is now required for all access to the cardholder data environment (CDE), not just remote access. Password requirements increased to 12 characters minimum.
- Targeted risk analysis replaces the one-size-fits-all approach. You now define the frequency of certain activities (like log reviews) based on your risk, not arbitrary timelines.
- Customized approach is a new validation option. You can meet objectives using controls that aren't explicitly listed in the standard—if you can prove they work.
- Some requirements have extended deadlines. 64 new requirements are "best practice" until March 31, 2025, then become mandatory.
- More focus on ongoing security. The standard now emphasizes security as a continuous process, not an annual checkbox.
Timeline: What's Required Now vs. Future-Dated
PCI DSS 4.0 has a two-phase implementation timeline that's causing confusion for a lot of organizations.
Phase 1: Effective Now (Since March 31, 2024)
All organizations must comply with PCI DSS 4.0. You can no longer assess against version 3.2.1—it's officially retired.
The immediate requirements hit organizations in a few key areas. Authentication got tighter across the board with Requirement 8 changes. Every requirement now needs documented roles and responsibilities—something many organizations had informally but never wrote down. Encryption and key management requirements were updated to close loopholes that some companies were exploiting. There are new rules around phishing detection and protection, and the standard clarified what service providers are actually responsible for (which clears up confusion that's existed for years).
Phase 2: Future-Dated Requirements (March 31, 2025)
Here's where it gets tricky. 64 requirements are currently "best practice" but become mandatory on March 31, 2025. The PCI Council gave organizations extra time because these requirements often need new tools, new processes, or both.
The big ones that catch people off guard are automated log review (you can't just have a human manually check logs anymore), authenticated vulnerability scanning (your scanner needs credentials to actually see what's vulnerable), and payment page script management (every JavaScript file on your checkout page needs to be inventoried and monitored). WAF is no longer optional for public-facing apps—if you've been relying on the "code review" alternative, that door is closing.
If you haven't started working on these, you're running out of time. Some of these requirements need 6+ months to implement properly.
Key Changes by Requirement Area
Authentication Changes (Requirement 8)
Requirement 8 got the biggest overhaul. Here's what changed:
MFA Everywhere
Under 3.2.1, multi-factor authentication was only required for remote access to the CDE and administrative access. Under 4.0, MFA is required for all access into the CDE (Requirement 8.4.2).
This is a bigger change than it sounds. It's not just your VPN anymore—it's every system in the cardholder data environment. The help desk person who pulls up a customer's last four digits? MFA. The developer who accesses the payment database for troubleshooting? MFA. Your third-party payment processor's support team? They need MFA too. Console access counts now, not just remote connections. Organizations that thought they were done with MFA rollout are discovering they've got gaps.
Stronger Passwords
Requirement 8.3.6 increases minimum password length from 7 to 12 characters (or 8 characters if the system doesn't support 12). Passwords must contain both numeric and alphabetic characters.
Password Change Frequency
Here's where it gets interesting. Requirement 8.3.9 says passwords must be changed every 90 days—unless you implement a mechanism that dynamically analyzes account security and determines when a change is needed based on risk. This is an example of the new flexibility in 4.0.
Service Account Management
Service accounts have always been a weak point for security, and the PCI Council finally addressed it. Requirement 8.6.1-8.6.3 cracks down on how organizations manage service accounts and application credentials.
The days of service accounts with passwords that never change are over. Interactive login needs to be limited—these accounts should only be used for their intended automated purposes. Passwords need to change periodically based on your risk analysis (not a fixed schedule, but you need to justify whatever frequency you choose). And that database password hardcoded in your config file from 2019? That's a finding now. Passwords can't be embedded in scripts or application code.
Encryption and Cryptography Updates
Disk-Level Encryption No Longer Sufficient
Requirement 3.5.1.2 clarifies that disk-level or partition-level encryption alone is not sufficient to render PAN unreadable. This has always been the intent, but it's now explicit. If you're relying solely on BitLocker or FileVault for stored card data, you need additional controls.
Hashing Requirements
Requirement 3.5.1.1 specifies that one-way hashes used to render PAN unreadable must use keyed cryptographic hashes. Unkeyed hashes are no longer acceptable.
TLS 1.2 Minimum
While this was already effectively required, 4.0 makes it explicit: TLS 1.2 or higher is required for all transmissions of cardholder data (Requirement 4.2.1).
Key Management
Requirement 3.6.1.1 adds documentation requirements for cryptographic architecture, including algorithms, protocols, and key strengths in use.
Vulnerability Management
Authenticated Internal Scanning
Requirement 11.3.1.2 (future-dated to March 2025) requires authenticated internal vulnerability scanning. Your scans must use credentials that allow the scanner to see vulnerabilities that wouldn't be visible to an unauthenticated scan.
Critical Vulnerability Timeline
Requirement 6.3.3 requires that critical and high-severity vulnerabilities be addressed based on targeted risk analysis. The old "install critical patches within one month" is replaced by a risk-based approach.
External ASV Scans
Requirement 11.3.2 adds requirements for managing scan results. If you fail an ASV scan, you need to rescan after addressing vulnerabilities—and keep records of the resolution process.
Targeted Risk Analysis (New Concept)
Targeted risk analysis is one of the most significant additions in PCI DSS 4.0. It's defined in Requirement 12.3.1 and referenced throughout the standard.
What It Is
Think of targeted risk analysis as the PCI Council saying "we trust you to make intelligent decisions, but you need to show your work." Instead of dictating that everyone review logs daily or scan for malware weekly, 4.0 lets you determine what makes sense for your environment.
But there's a catch. You need to document your reasoning. A targeted risk analysis considers what threats the activity is meant to address, how likely those threats are in your specific environment, what the impact would be if something went wrong, and how much risk your organization is willing to accept. It's not just picking a number—it's building a defensible argument.
Where It's Required
The standard references targeted risk analysis in dozens of places, which means you'll be writing quite a few of these. How often do you scan for malware? That depends on your risk analysis. How frequently do you inspect point-of-interaction devices for tampering? Risk analysis. Log review frequency, service account password rotation, vulnerability remediation timelines—all of these now require documented justification rather than following a prescribed schedule.
Why It Matters
This is a major shift from prescriptive requirements to risk-based decisions. Under 3.2.1, the standard might say "review logs daily." Under 4.0, you determine the appropriate frequency based on your risk analysis. This gives you flexibility but also accountability—you need to document your reasoning and it needs to be defensible.
Customized Approach (New Flexibility Option)
The customized approach is entirely new in 4.0. It allows organizations to meet security objectives using controls that differ from the defined requirements.
How It Works
For each requirement that supports the customized approach (not all do), you can:
- Identify the security objective the requirement is trying to achieve
- Implement alternative controls that meet that objective
- Document your approach and evidence that it's working
- Have it validated by your assessor
When to Use It
The customized approach works best for organizations that already have mature security programs. Maybe you've got a control that accomplishes the security objective better than what the standard prescribes, or the defined requirement just doesn't fit your architecture. If you can prove your alternative works, you can use it.
When Not to Use It
Don't treat the customized approach as an escape hatch for requirements you find inconvenient. Assessors will see through that immediately. If you're avoiding a control because you don't want to implement it, that's not what this is for. You also need serious documentation and testing capabilities to prove your alternative actually works. And some requirements don't allow customization at all—they're defined approach only.
Assessor Requirements
QSAs validating customized approaches need additional training and experience. Not every assessor is qualified to validate customized implementations.
PCI DSS 3.2.1 vs. 4.0: Key Differences
| Area | PCI DSS 3.2.1 | PCI DSS 4.0 |
|---|---|---|
| MFA Scope | Remote access and admin only | All access to CDE |
| Password Length | 7 characters minimum | 12 characters minimum |
| Password Changes | Every 90 days | Every 90 days OR dynamic analysis |
| Vulnerability Scans | Unauthenticated acceptable | Authenticated required (future-dated) |
| Log Reviews | Daily review required | Frequency based on targeted risk analysis |
| Compliance Validation | Defined approach only | Defined OR customized approach |
| WAF Requirement | WAF or code review option | WAF required for public-facing apps (future-dated) |
| Risk Analysis | General annual risk assessment | Targeted risk analysis for specific activities |
| Script Management | Not explicitly required | Payment page scripts must be authorized and integrity-checked |
| Anti-Phishing | General awareness training | Technical anti-phishing mechanisms required |
Common Mistakes We're Seeing
After helping organizations navigate the 4.0 transition, these are the mistakes that keep coming up:
Treating future-dated requirements as optional
"Best practice until March 2025" doesn't mean "we'll worry about it later." Many of these requirements—like authenticated vulnerability scanning and script integrity monitoring—require tool procurement, implementation, and testing. If you start in February 2025, you won't make it.
Assuming MFA implementation is simple
The expanded MFA requirements (8.4.2) affect more systems than most organizations realize. Every system in the CDE needs MFA, including legacy applications that may not support it natively. Figure out your MFA gaps now.
Copying someone else's targeted risk analysis
Your targeted risk analyses need to reflect your actual environment, threats, and risk tolerance. Using a template or copying from another organization won't cut it. Assessors will ask how you determined your frequencies—you need to be able to explain your reasoning.
Ignoring the customized approach entirely
Some organizations could benefit significantly from the customized approach but default to the defined approach because it's familiar. If you have mature security controls that accomplish the requirement's objective differently, the customized approach might reduce your compliance burden.
Confusing customized approach with compensating controls
They're not the same. Compensating controls are for when you can't meet a requirement due to legitimate constraints. The customized approach is for meeting the security objective through alternative means when you could meet the defined requirement but have a better way.
Not updating documentation
PCI DSS 4.0 requires documented roles and responsibilities for every requirement. If your documentation still references 3.2.1, you're already non-compliant. Update your policies, procedures, and responsibility matrices.
Frequently Asked Questions
When does PCI DSS 4.0 take effect?
PCI DSS 4.0 is effective now. As of March 31, 2024, all assessments must be conducted against PCI DSS 4.0. Version 3.2.1 was retired and can no longer be used for compliance validation.
Can I still assess against PCI DSS 3.2.1?
No. PCI DSS 3.2.1 was retired on March 31, 2024. All assessments—whether self-assessment questionnaires (SAQs) or QSA-led assessments—must use PCI DSS 4.0.
What is targeted risk analysis in PCI DSS 4.0?
Targeted risk analysis is a documented assessment used to determine the frequency of specific security activities. Instead of prescribing fixed frequencies (like "review logs daily"), PCI DSS 4.0 requires organizations to analyze their risk and determine appropriate frequencies. This must be documented and include consideration of threats, likelihood, potential impact, and the organization's risk tolerance.
What's the difference between the defined approach and customized approach?
The defined approach is the traditional method: you implement the controls as specified in the requirement and test them accordingly. The customized approach allows you to meet the security objective using alternative controls—but requires additional documentation, risk analysis, and validation that your controls are effective.
Which requirements are future-dated until March 2025?
64 requirements are future-dated until March 31, 2025. Key ones include authenticated internal vulnerability scanning (11.3.1.2), automated log review mechanisms (10.4.1.1), payment page script management (6.4.3), anti-phishing mechanisms (5.4.1), and WAF requirements for public-facing web applications (6.4.2).
Need Help With PCI DSS 4.0?
The transition to PCI DSS 4.0 is more than an annual checkbox exercise. Between expanded MFA requirements, targeted risk analyses, and future-dated requirements coming due in March 2025, there's real work to be done.
We offer a PCI DSS 4.0 Snapshot that determines your SAQ type, maps your card data flows, and identifies every gap in your current controls against 4.0 requirements. Fixed price, 10 business days, clear answers.
If you're working through security questionnaires from customers asking about your PCI compliance, or you need to get your cyber insurance evidence together, we can help with that too.
The bottom line: PCI DSS 4.0 is here and it's mandatory. The biggest changes are around authentication (MFA everywhere), flexibility (targeted risk analysis and customized approach), and new technical requirements (script integrity, authenticated scanning, anti-phishing). 64 requirements become mandatory in March 2025. If you haven't started preparing for those, now is the time.