PCI-DSS v4.0 Raised the Password Bar. Here's What You Missed.

The headline number: 7 became 12

PCI-DSS v3.2.1 required a minimum password length of 7 characters. That requirement was published in 2018, when most security guidance still treated complexity as the primary lever for password strength. PCI-DSS v4.0, which became the sole enforceable version in March 2024, raised that minimum to 12 characters.

Seven to twelve sounds like a modest change. In practice, it is a significant operational shift for organisations whose authentication systems were built against the v3.2.1 baseline — particularly legacy healthcare payment systems, point-of-sale infrastructure, and older enterprise applications that have character length limits baked into their database schemas.

The change that matters more: MFA scope

The 12-character minimum got the headlines. The more impactful change was buried in Requirement 8.4.2.

Under v3.2.1, multi-factor authentication was required for remote access and non-console administrative access. That meant your VPN, your admin panels, your remote desktop connections.

Under v4.0, MFA is required for all access into the Cardholder Data Environment — not just remote access. Employees working inside the office, on the corporate network, accessing payment systems, now need a second factor.

For many organisations, this means rolling out MFA to a much broader population of users on a much tighter timeline than they planned for. The complexity is compounded by the variety of authenticator types that qualify: TOTP apps, push notifications, hardware tokens, and (reluctantly) SMS OTP all satisfy the requirement. But SMS is increasingly viewed as inadequate by security-conscious QSAs, and organisations that implement it now may face pressure to migrate again as the standard evolves.

What auditors will actually check

Based on QSA guidance and early v4.0 audit cycles, here are the specific controls auditors are scrutinising most closely:

• Password length enforcement at the system level, not just policy. A written policy saying "passwords must be 12+ characters" is not sufficient. The authentication system must enforce it technically. If your legacy POS can still accept a 7-character password, you have a finding.
• MFA coverage for all CDE access paths. Auditors will map every access path into the CDE — not just the obvious ones. Internal workstations, application-level access, batch processing accounts that can interactively log in, all of it.
• Service account credential management. Requirement 8.6 is new and catches many organisations off guard. Service account passwords stored in configuration files, environment variables, or version control are findings. Secrets management systems (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) are the expected solution.
• Vendor default password removal. Requirement 2.2.2 has always existed but is now examined more rigorously. Every network device, every piece of payment hardware, every database with a default credential in scope must have that credential changed before deployment.

The passphrase exception (underused)

One change in v4.0 that most organisations have not noticed: passphrases are now explicitly permitted. Requirement 8.3.6's guidance text acknowledges that a 15+ character passphrase satisfies the intent of the password strength requirement.

This matters for usability. In environments where users resist 12-character complex passwords (clinical staff, warehouse workers, retail associates), a passphrase like violet-marble-funnel-sunrise is significantly more usable and meets the requirement. The 15-character minimum for passphrases versus 12 for passwords reflects that passphrases typically use smaller character pools (dictionary words).

Timeline: where are we now

All v4.0 requirements, including those originally marked as "future-dated" (which had a March 2025 deadline), are now in full effect. There are no remaining grace periods. If you are scheduled for a QSA assessment and have not updated to v4.0 controls, you will have findings.

The most common issues we see in organisations still catching up:

• Legacy web application login forms enforcing 7 or 8 character minimums hardcoded in HTML validation
• VoIP systems and building access systems in the CDE scope with default credentials
• Service account passwords in .env files committed to private Git repositories
• MFA deployed for VPN but not for internal CDE access

What to do this week

If you have not yet audited your authentication controls against PCI-DSS v4.0 Requirement 8, the highest-priority actions:

1. Inventory every system in your CDE scope that accepts passwords
2. For each system, verify technical enforcement of 12+ character minimum (not just policy)
3. Map every access path into the CDE — internal and remote — and verify MFA coverage
4. Search version control and configuration management for credentials in plaintext
5. Run a scan against all in-scope systems for vendor default credentials

The PassGeni PCI-DSS preset generates 12-character minimum credentials with full character set complexity, ready to use for any in-scope system.