💳 PCI-DSS v4.0 Password Requirements: What Changed and How to Comply
PCI-DSS v4.0 Password Requirements: What Changed and How to Comply
The Payment Card Industry Data Security Standard (PCI-DSS) v4.0, released in March 2024 and mandatory from March 2025, introduced significant changes to password and authentication requirements. This guide covers exactly what changed, what's still the same, and practical steps to achieve compliance.
What Stayed the Same
Before diving into the changes, here's what PCI-DSS v4.0 carries forward from v3.2.1 without modification: - Passwords must be at least 7 characters in length - Passwords must contain both numeric and alphabetic characters - Users must change default vendor passwords before deploying systems - Group, shared, or generic passwords must be disabled or documented - Vendor-supplied defaults must be changed (passwords, SNMP community strings, etc.)
What Changed in PCI-DSS v4.0
1. Multi-Factor Authentication Expansion (Requirement 8.4)
PCI-DSS v4.0 significantly expands MFA requirements. Previously, MFA was only required for remote access to the cardholder data environment (CDE) and non-console administrative access. Now:
- MFA is required for ALL access to the CDE (requirement 8.4.2)
- This includes employees, contractors, and third parties
- MFA must use at least two of three factors: something you know (password), something you have (token/phone), something you are (biometric)
2. Passphrase Support (Requirement 8.3.6)
V4.0 explicitly allows passphrases (sequences of words) as an alternative to traditional complex passwords. This is a huge usability improvement: - Passphrases can be up to 64 characters or longer - Passphrases don't need the same complexity requirements (mixed case, numbers, special chars) - Length is prioritized over complexity — making them both more secure and easier to remember
3. Risk-Based Authentication (Requirement 8.3.10 — New)
New requirement that doesn't mandate specific technical controls but expects organisations to: - Analyse authentication logs for anomalies - Implement adaptive authentication based on risk level - Review and respond to failed authentication attempts
4. Password Rotation Relaxed (Requirement 8.3.9)
Previously required password changes every 90 days. V4.0 removes mandatory periodic rotation for user passwords: - Only change passwords if there's evidence of compromise or if the user forgets their password - This aligns with NIST SP 800-63B guidance that periodic password changes reduce security (users choose weaker passwords more frequently)
Practical Compliance Steps
| Step | Action | Timeline |
|---|---|---|
| 1 | Enable MFA for all CDE access | Immediate |
| 2 | Update password policy to support passphrases (min 12 chars) | Within 30 days |
| 3 | Remove mandatory 90-day password rotation | Within 30 days |
| 4 | Deploy adaptive authentication monitoring | Within 90 days |
| 5 | Review and update security awareness training for new requirements | Within 60 days |
Common Compliance Pitfalls
- Shared service accounts: Don't forget to secure MFA or strong password policies for shared accounts used by applications
- Legacy systems: Older payment terminals may not support passphrases — document compensating controls
- Third-party vendors: Ensure vendors accessing your CDE also comply with v4.0 requirements
Bottom line: PCI-DSS v4.0 represents a shift toward risk-based, MFA-first security rather than rigid password rotation. Use passphrases, enable MFA everywhere, and monitor for anomalies.
PCI-DSS v4.0 Password Requirements: What Changed and How to Comply
The Payment Card Industry Data Security Standard (PCI-DSS) v4.0 introduced the most significant overhaul of authentication and password requirements since the framework's inception. With v3.2.1 fully retired and v4.0 (and the subsequent v4.0.1 clarifications) now mandatory, organizations handling cardholder data must understand exactly what changed. The updates reflect modern threat realities, aligning more closely with NIST guidance while raising the bar for both human and machine credentials.
Stronger Password Length and Complexity
Under v4.0, the minimum password length increased from seven characters to at least twelve characters for user accounts. Where a system cannot technically support twelve characters, a minimum of eight is permitted, but this exception must be documented and justified. Passwords must still contain both numeric and alphabetic characters, preserving complexity requirements while emphasizing length as the primary defense against brute-force and credential-stuffing attacks.
- Minimum length raised to 12 characters (8 only where systems cannot support more)
- Passwords must include both letters and numbers
- Length is now prioritized as the strongest protective factor
Changes to Password Rotation Rules
One of the most welcomed changes addresses password expiration. The traditional 90-day rotation requirement remains a baseline, but v4.0 now permits organizations to forgo periodic password changes entirely if they implement dynamic risk-based analysis. Specifically, if account access is automatically evaluated in real time and access is granted only after analyzing the security posture of the resource, forced rotation is no longer required. This aligns PCI-DSS with NIST 800-63B, which discourages arbitrary password changes that lead users to choose weaker, predictable variations.
Multi-Factor Authentication Expansion
MFA requirements expanded considerably. Previously, MFA was mandated only for remote network access and administrative access into the cardholder data environment (CDE). Under v4.0, MFA is now required for all access into the CDE, regardless of whether the user is remote or on-site, administrator or standard user. The standard also clarifies that MFA implementations must be resistant to replay attacks and cannot be bypassed by any users, including administrators, unless specifically documented and authorized.
- MFA required for all CDE access, not just remote or admin
- MFA systems must resist replay attacks
- Authentication factors must remain independent of one another
Protecting Service and System Accounts
A major new focus is on application and system accounts—often called service accounts or machine identities. These non-human credentials were historically overlooked but are now explicitly addressed. Passwords for these accounts must be changed periodically and whenever there is suspicion of compromise. Interactive login for such accounts must be restricted, and their use must be tightly governed to prevent misuse as a backdoor into sensitive systems.
How to Achieve Compliance
Meeting these requirements demands a coordinated effort across identity management, infrastructure, and policy. Organizations should begin with a thorough inventory of all accounts that touch the CDE, including human users, administrators, and automated service accounts. From there, technical controls can be aligned to the new thresholds.
- Update password policies in directory services to enforce 12-character minimums
- Deploy phishing-resistant MFA across every CDE access point
- Evaluate whether risk-based authentication can replace forced rotation
- Implement a managed solution for rotating and vaulting service account credentials
- Document all exceptions, compensating controls, and technical limitations
- Train staff on new authentication procedures to reduce help-desk friction
Preparing for Ongoing Assessment
Because v4.0 emphasizes continuous security rather than point-in-time checks, compliance teams should treat password governance as an ongoing program. Logging authentication events, monitoring for anomalous access, and periodically reviewing account inventories will help maintain readiness between formal assessments. Engaging a Qualified Security Assessor early can clarify how the customized approach—a new v4.0 option—might apply to unique environments. Ultimately, these password and authentication changes push organizations toward stronger, more resilient identity practices that protect cardholder data while reducing the burden of outdated, counterproductive rules.