PCI-DSS v4.0 Password Requirements: What Changed in 2024

PCI-DSS v4.0 overview

PCI-DSS (Payment Card Industry Data Security Standard) version 4.0 was released in March 2022 and became the sole enforceable version in March 2024 when v3.2.1 retired. It governs any organisation that stores, processes, or transmits payment cardholder data — effectively any business that accepts credit or debit card payments directly.

Version 4.0 made the most significant changes to authentication requirements in the standard's history. The headline change: minimum password length increased from 7 characters to 12 characters. But the password-related changes go deeper than that headline number.

What changed from v3.2.1

Requirement 8 in full

Requirement 8 governs "Identify Users and Authenticate Access to System Components." The password-specific sub-requirements are:

• 8.3.6: Passwords must be at least 12 characters long (or if the system does not support 12, a minimum of 8 with documented compensating control)
• 8.3.6 continued: Passwords must contain both numeric and alphabetic characters (v4.0 also recommends but does not strictly mandate uppercase + special)
• 8.3.7: Passwords cannot be the same as any of the last 4 passwords used
• 8.3.9: Passwords for user accounts must be changed at least every 90 days, unless alternative controls are in place
• 8.3.11: Where passwords are used as authentication for system/application accounts, manage these accounts via: change on schedule based on risk, change as soon as possible after compromise, change at each use (for use-once credentials)
• 8.2.6: Inactive accounts must be removed or disabled within 90 days
• 8.2.7: Accounts used by third parties must be managed and monitored

A critical note on Requirement 8.3.9: PCI-DSS v4.0 acknowledges NIST 800-63B's guidance on mandatory rotation in its supplemental guidance, noting that organisations may use risk-based approaches as an alternative to 90-day rotation if they implement compensating controls. However, this requires formal documentation and QSA (Qualified Security Assessor) approval. For most organisations, 90-day rotation for user accounts accessing the Cardholder Data Environment (CDE) remains the safer path.

MFA requirements (expanded)

The most significant change in v4.0 beyond password length is the expansion of MFA requirements. Under v3.2.1, MFA was required for remote access and non-console administrator access. Under v4.0:

• Requirement 8.4.2: MFA is required for all access into the CDE — not just remote access. This means employees accessing payment systems from inside the corporate network now require MFA.
• Requirement 8.4.3: MFA is required for all remote network access originating from outside the entity's network.

What counts as MFA under PCI-DSS v4.0:

• Two of: something you know (password), something you have (hardware token, authenticator app), something you are (biometric)
• Authenticator apps (TOTP) satisfy the "something you have" factor
• SMS OTP is technically permitted but discouraged due to SIM swap vulnerabilities
• Push notification (Duo, Microsoft Authenticator) satisfies the requirement
• Hardware keys (YubiKey, FIDO2) are the most robust option and fully compliant

Service accounts and system passwords

Requirement 8.6 introduced new controls for system and application accounts — passwords used by automated processes rather than humans. These are frequently overlooked but represent significant risk (hardcoded credentials, shared service accounts, never-rotated API keys).

PCI-DSS v4.0 requirements for service accounts:

• Interactive logins must be disabled for service accounts where possible
• Where interactive login is enabled, it must be logged, monitored, and justified
• Service account passwords must be at least as strong as user passwords (12+ characters)
• Service account passwords must be changed when the associated personnel change or when compromise is suspected
• Passwords must not be hardcoded in scripts or configuration files — use secrets management systems

Vendor default passwords

Requirement 2.2.2 requires that vendor default passwords are changed before any system component is deployed in the production environment. This applies to:

• Network equipment: routers, switches, firewalls
• Point-of-sale terminals and payment hardware
• Database management systems
• Operating system default accounts
• Application default credentials

Default credentials are consistently in the top attack vectors for CDE compromises. The Mirai botnet, which caused the 2016 Dyn DDoS attack, was almost entirely powered by default credentials on IoT devices. In the payment environment, default credentials on POS systems and network devices remain a common breach vector.

Audit and logging requirements

Requirement 10 covers logging. Authentication-related logging requirements:

• Log all individual user access to cardholder data
• Log all actions by individuals with root or administrative privileges
• Log all invalid logical access attempts
• Log all changes to authentication mechanisms including creation, deletion, and modification
• Retain logs for at least 12 months, with 3 months immediately available for analysis
• Use time-synchronisation technology (NTP) to ensure audit log timestamps are reliable

Compliance timeline

PCI-DSS v4.0 became the only valid version in March 2024. All organisations in scope must be fully compliant. Key dates:

Some requirements in v4.0 were marked as "future-dated" — meaning organisations had until March 2025 to implement them. As of 2025, all requirements including the future-dated ones are in effect.

Implementation checklist

1. Update all authentication systems to enforce 12-character minimum (or 15-character minimum if passphrases are supported)
2. Ensure complexity: at minimum numbers + letters; aim for upper + lower + numbers + special characters
3. Configure 90-day rotation for all user accounts that access the CDE
4. Enforce password history: block reuse of last 4 passwords
5. Set account lockout to trigger after 10 failed attempts
6. Implement MFA for all access into the CDE (not just remote access)
7. Implement MFA for all remote access into the cardholder data environment
8. Audit and change all vendor default passwords across all in-scope systems
9. Implement secrets management for service account credentials — no hardcoded passwords
10. Configure authentication event logging on all in-scope systems
11. Ensure log retention: 12 months total, 3 months immediately accessible
12. Review and disable or remove inactive accounts every 90 days
13. Document any deviations with formal compensating controls