The New PCI Password Rules: 12 Characters and Beyond

PCI DSS 4.0 raises the minimum password length from seven characters to 12. Under Requirement 8.3.6, passwords must be at least 12 characters, or at least eight if a system can't support 12, and must contain both letters and numbers. The change is future-dated: it's a best practice until March 31, 2025, and until then the seven-character minimum from PCI DSS 3.2.1 still applies. Length is only part of the update. The standard also changes how password rotation works, adds new obligations for service providers, and introduces specific rules for application and system accounts.

Here's what each requirement says, when it applies and how to prepare.

What are the PCI DSS 4.0 password requirements?

The password rules sit mostly in Requirement 8.3 (user authentication) and 8.6 (application and system accounts). "Applies now" means the requirement is in force in any assessment against PCI DSS 4.0. Version 3.2.1 remains available until it's retired on March 31, 2024.

Some of these requirements note that they aren't intended to apply to user accounts on point-of-sale terminals that can access only one card number at a time to facilitate a single transaction. Check the applicability notes for each requirement against your environment.

What does Requirement 8.3.6 require?

Requirement 8.3.6 applies whenever passwords or passphrases are used as authentication factors for user access to in-scope system components. That includes a password that's one factor in a multi-factor login, not only password-only access. Once it takes effect, each password must:

• Be at least 12 characters long, or at least eight characters if the system doesn't support 12
• Contain both numeric and alphabetic characters

The eight-character fallback is for systems that genuinely can't handle 12. It isn't a general option. If you rely on it, document which systems are affected and why, and expect your assessor to ask.

The change reflects how passwords are actually attacked. When password hashes are stolen, attackers can try guesses offline at high speed, and each extra character multiplies the work involved. The standard refers throughout to "passwords/passphrases", so a long passphrase is a perfectly good way to comply.

How do you prepare for the 12-character minimum?

Start now rather than in early 2025. Password policy is usually enforced in more places than people expect.

1. Inventory where passwords are enforced. Include directory services, local accounts on servers and workstations, network devices, databases, cloud consoles, and in-house or third-party applications within scope.
2. Find the systems that can't support 12 characters. Decide whether to upgrade, replace or document them under the eight-character fallback.
3. Update your authentication policy. Requirement 8.3.8 requires you to document your authentication policies and communicate them to users, including guidance on choosing strong passwords.
4. Plan the rollout. Enforce the new minimum at the next password change for each account, and make sure every in-scope account has picked up the new rule well before March 31, 2025. Agree the approach with your assessor.
5. Reduce reliance on passwords. Wider use of multi-factor authentication reduces risk and, as the next section shows, removes the 90-day rotation obligation.

Do PCI passwords still have to change every 90 days?

Only in some cases. Requirement 8.3.9 applies when a password is the only authentication factor for user access. In that case you must do one of two things:

• Change the password at least once every 90 days, or
• Analyze the security posture of accounts dynamically and determine access to resources automatically in real time.

The second option is new in 4.0 and applies now. It suits organizations whose access decisions already take account of signals such as device health, location and behavior. Your assessor will expect evidence that the analysis works, not just a description of it.

That's narrower than 3.2.1, whose 90-day rule applies to user passwords generally. It also brings PCI DSS closer to NIST Special Publication 800-63B, which advises against forcing arbitrary periodic password changes when there's no sign of compromise.

MFA changes the picture further. From March 31, 2025, Requirement 8.4.2 requires MFA for all access into the cardholder data environment (CDE). After that, password-only access should mostly be limited to in-scope systems outside the CDE, which is where 8.3.9 will matter most.

What are the rules on password history and first-use passwords?

Two requirements carry over from 3.2.1 with little change.

Requirement 8.3.7 stops users from setting a new password that matches any of their last four. Configure this wherever passwords are set, not only in your main directory.

Requirement 8.3.5 covers passwords issued by administrators or help desks. First-time and reset passwords must be unique to each user, and the user must be forced to change them immediately after first use. A standard reset password shared across users doesn't meet this.

Pair these with Requirement 8.3.3, which requires you to verify a user's identity before changing any authentication factor. A reset process that doesn't confirm who's asking undermines everything else in this list.

What changes for service providers?

Service providers have two extra requirements covering their customers' accounts.

Requirement 8.3.10 applies now. If customer users access cardholder data with a password as their only factor, you must give them guidance on changing their passwords periodically, and on when and under what circumstances to change them.

Requirement 8.3.10.1 is future-dated to March 31, 2025. Where a password is the only factor for customer user access, you must either make customers change it at least once every 90 days or use dynamic analysis of account security posture, mirroring 8.3.9.

For many service providers, the simpler route is to offer and encourage MFA for customer accounts. That removes the single-factor condition that triggers these requirements.

How do the rules apply to application and system accounts?

PCI DSS 4.0 adds Requirement 8.6 for accounts used by systems and applications rather than people, such as service accounts, database connection accounts and integration accounts. All three sub-requirements are future-dated to March 31, 2025.

8.6.1: Interactive login

If an application or system account can be used for interactive login, you must:

• Prevent interactive use unless it's needed for an exceptional circumstance
• Limit interactive use to the time that circumstance requires
• Document the business justification
• Get explicit management approval
• Confirm the individual's identity before granting access
• Make every action attributable to an individual user

8.6.2: No hard-coded passwords

Passwords for application and system accounts that can be used for interactive login must not be hard-coded in scripts, configuration or property files, or bespoke and custom source code. In practice, this means retrieving credentials at runtime from a secrets store and removing them from code repositories and deployment files.

8.6.3: Protection against misuse

Passwords for application and system accounts must be:

• Changed periodically, at a frequency set by a targeted risk analysis under Requirement 12.3.1, and whenever compromise is suspected or confirmed
• Complex enough for how often you change them

The trade-off is explicit. A password you change rarely should be long and random. Since nobody has to type these passwords, there's little reason not to generate them that way.

Start with an inventory of application and system accounts, including who owns each one, where its credentials are stored and whether it can log in interactively. That inventory also supports Requirement 7.2.5, which covers how access for these accounts is assigned and managed.

Frequently asked questions

Does the 12-character minimum apply to passwords used with MFA?

Yes. Requirement 8.3.6 applies to any password used as an authentication factor for user access, including one that's part of a multi-factor login. MFA mainly affects 8.3.9's rotation requirement, not password length.

What happens if a system can't support 12 characters?

Use at least eight characters, with letters and numbers, on that system. Document the limitation, and consider whether the system should be upgraded or replaced.

Are passphrases acceptable?

Yes. The requirements refer to "passwords/passphrases" throughout. A long passphrase that also meets the character-type rule is often easier for people to remember than a short, complex password.

Can we drop 90-day password changes now?

Only if you're assessed against PCI DSS 4.0, since 3.2.1 keeps the broader 90-day rule. Under 4.0, you can drop it where the password isn't the only authentication factor, or where you've implemented dynamic analysis of account security posture under 8.3.9. Where users log in with a password alone and have no dynamic analysis, the 90-day change remains.

Key takeaways

• The 12-character minimum (Requirement 8.3.6) becomes mandatory on March 31, 2025. Until then, seven characters is the floor.
• The 90-day rotation rule applies only to single-factor password access, and dynamic posture analysis is an alternative you can use now.
• Rules on password history, unique first-use passwords and lockout continue, with lockout now allowing up to 10 attempts.
• Service providers face a future-dated rotation requirement for customer passwords used as the only factor (8.3.10.1).
• Application and system accounts need an inventory, no hard-coded credentials and risk-based password changes by March 31, 2025.