PCI DSS Password and Authentication Requirements Under v4.0.1

PCI DSS v4.0.1 puts password and authentication controls in Requirement 8. The current rules are broader than a password policy: they cover account identity, password strength, resets, failed logins, multi-factor authentication (MFA), and the way authentication systems themselves are protected.

For human users, passwords generally need at least 12 characters when they are used as an authentication factor, or at least eight characters if the system cannot support 12. They also need both alphabetic and numeric characters. MFA is required for defined access into the cardholder data environment (CDE) and for remote access that could reach or affect it.

The part that still causes confusion is password rotation. PCI DSS does not simply say that every password everywhere must change every 90 days. The answer depends on whether the password is the only authentication factor, where the system sits in scope, and whether the organization uses the alternative dynamic account-security analysis allowed by Requirement 8.3.9.

PCI DSS password and authentication requirements at a glance

Requirement 8 has a lot of small rules, and reading them one by one can make the whole thing feel more complicated than it is. This table gives the practical version first. The exact assessment wording still comes from PCI DSS v4.0.1.

PCI SSC lists PCI DSS v4.0.1 as the current standard. The detailed standard and the applicable SAQ or ROC remain the source for exact requirement wording and testing procedures.

For the wider structure of scope, validation, and all 12 requirement groups, see our PCI DSS requirements guide.

How long do PCI DSS passwords need to be?

The current minimum is 12 characters when passwords or passphrases are used as authentication factors. If a system genuinely cannot support 12 characters, PCI DSS allows a minimum of eight. The password also needs both alphabetic and numeric characters.

This was one of the future-dated v4.x changes that became mandatory on 31 March 2025. So a policy that still says "minimum seven characters" is now behind the standard, even if nobody remembered to update the document after the technical setting changed.

There is an important scope limit here. Requirement 8.3.6 is written for passwords and passphrases used as authentication factors for human users. Its applicability notes do not treat application and system accounts the same way; those accounts have their own requirements in section 8.6. Mixing the two is an easy way to create a policy that looks simple but does not match the standard.

Does PCI DSS still require password changes every 90 days?

Sometimes. It is not a universal 90-day rotation rule anymore.

Requirement 8.3.9 applies when passwords or passphrases are used as the only authentication factor for user access in the single-factor situations covered by that requirement. In that case, the organization can either change them at least every 90 days or dynamically analyze the security posture of the account and automatically determine access to resources in real time.

PCI SSC clarified in FAQ 1590 that 8.3.9 does not apply to in-scope system components where MFA is used. That distinction matters because teams sometimes keep forcing 90-day changes across every account simply because "PCI says so," even when that is not what the current requirement says.

There is a similar service-provider requirement, 8.3.10.1, for customer user access when a password is the only factor. Again, the choice is a 90-day change or the defined dynamic account-security analysis.

That dynamic account-security analysis is not the same thing as PCI DSS targeted risk analysis. If you are working on TRA under Requirement 12.3, our PCI DSS risk assessment guide covers that process separately.

What does PCI DSS require for password resets, reuse, and failed logins?

A strong password policy can still fail in the small operational details. Requirement 8 expects the reset process, password history, and lockout behavior to work in the system, not just appear in a procedure.

The main controls are straightforward:

• First-time and reset passwords are unique to the user and must be changed immediately after first use.
• Users cannot choose a new password that matches any of their previous four passwords.
• A user ID is locked after no more than 10 invalid authentication attempts.
• The lockout lasts at least 30 minutes or until the user's identity is confirmed.
• Authentication factors must be protected with strong cryptography during transmission and storage.

The last point is easy to miss because it is not really a "password complexity" setting. It is about what happens to the credential after the user creates it. PCI SSC confirmed in a 2025 FAQ that strong cryptographic hashing can meet the intent for protecting stored passwords when it is implemented properly.

What are the PCI DSS MFA requirements?

MFA under PCI DSS is tied to the access path. The simplest way to get it wrong is to write "MFA enabled" in a policy and assume that covers every route into the CDE.

Requirement 8.4 separates several situations:

• Non-console administrative access into the CDE requires MFA under Requirement 8.4.1.
• Access into the CDE is covered by Requirement 8.4.2, with a specific v4.0.1 exception for user accounts authenticated only with qualifying phishing-resistant authentication.
• Remote network access originating outside the entity's network that could access or impact the CDE requires MFA under Requirement 8.4.3, including personnel and third-party access.
• Scope matters here. A remote user connecting to a properly segmented part of the network that cannot access or affect the CDE is not the same as a remote user whose path can reach payment systems.

That is why the CDE and PCI DSS scope guide should be the next stop if the boundary is unclear. Authentication design starts with knowing which systems are in the CDE, which systems are connected to it, and which systems can affect its security.

Can passkeys replace MFA for PCI DSS?

For one part of Requirement 8, yes. For the other parts, not by themselves.

PCI SSC confirmed in FAQ 1595 that synced passkeys implemented according to FIDO2 can qualify as phishing-resistant authentication and can be used as a single factor in place of MFA for Requirement 8.4.2.

But FAQ 1596 draws a line around administrative access and external remote access. For Requirements 8.4.1 and 8.4.3, phishing-resistant authentication still needs another authentication factor to meet the MFA requirement.

This is one of those details that is easier to understand as an access-path problem than as a product question. "We use passkeys" is useful information, but it does not tell an assessor which requirement is being met until the account, access path, factor type, and CDE relationship are clear.

What does PCI DSS expect from the MFA system itself?

Requirement 8.5 looks past the MFA checkbox and asks whether the implementation can be misused or bypassed.

The MFA system needs to use at least two different types of authentication factors, require successful authentication with all factors before access is granted, and resist replay attacks. Users, including administrators, should not be able to bypass MFA unless there is a documented, management-authorized exception for a limited period.

That is worth testing. A technically enabled MFA product can still have forgotten fallback routes, old VPN profiles, emergency accounts, or service-desk processes that quietly turn it into single-factor access when somebody is in a hurry.

What should a PCI DSS password policy actually cover?

A policy does not need to repeat Requirement 8 line by line. It needs to tell people how the organization implements the rules in its own environment.

A useful policy normally makes these points clear:

• Which users, systems, and authentication methods are in scope.
• Minimum password length and composition settings, including any legacy system that cannot support 12 characters.
• How first-use and reset credentials are issued and forced to change.
• Password history and failed-login lockout settings.
• Where single-factor authentication is still permitted and how the 90-day or dynamic-analysis requirement is handled.
• Which access paths require MFA and which factor types are approved.
• How temporary MFA bypasses or emergency-access exceptions are approved, time-limited, and recorded.
• How application and system accounts are handled separately from human-user passwords.
• Who reviews authentication settings and what evidence is retained for the PCI DSS assessment.

This is also where "the policy says one thing, the identity platform does another" tends to show up. For PCI DSS, the configured control and the documented process have to tell the same story.

What evidence should be ready for a PCI DSS assessment?

Requirement 8 evidence is usually a mix of configuration, account samples, procedures, and observed login behavior. The assessor is trying to confirm that the rules exist and that real users cannot quietly work around them.

Typical evidence can include:

• Password and authentication policies and procedures.
• Identity-platform or system settings showing password length, composition, history, lockout, and reset behavior.
• MFA configuration for administrative, CDE, and external remote access paths.
• Samples of user accounts and role assignments showing unique identification and appropriate access.
• Records for temporary MFA bypasses or authentication exceptions, including approval and expiration.
• Evidence that first-use or reset passwords are unique and require immediate change.
• Documentation for any legacy system using the eight-character exception because 12 characters are not supported.
• Evidence for the 90-day password-change process or dynamic account-security analysis where Requirement 8.3.9 applies.
• Configuration and process evidence for application and system accounts where section 8.6 applies.

For the assessment-level view of how evidence is selected, tested, remediated, and documented in SAQ, ROC, and AOC work, see our PCI DSS audit and assessment guide.

How does authentication connect to logging and PCI DSS scope?

Authentication does not sit in a separate corner of the PCI program. The account might be managed in an identity platform outside the CDE, while the login gives access to a server inside it. That identity system can still matter to PCI scope because it can affect access to the CDE.

Our PCI DSS Requirement 10 guide covers the other half of that story: logging successful and failed access, administrative activity, credential changes, and the evidence needed to reconstruct who did what.

The connection matters during incidents too. A strong password setting helps prevent account compromise, but the team still needs to see suspicious login attempts, privilege changes, unexpected MFA behavior, and access from unusual locations or systems.

A practical way to check Requirement 8

You do not need to start with a giant spreadsheet. Pick one real access path into the CDE and follow it from the person to the system.

• Identify the user, account, authentication method, and system being accessed.
• Confirm whether the system is in the CDE, connected to it, or capable of affecting its security.
• Check whether the path is administrative, internal non-console access, or remote access from outside the network.
• Look at the actual password and MFA configuration, not only the policy document.
• Test a reset, failed-login lockout, and any permitted recovery or bypass route.
• Check what gets logged and whether the evidence can be tied back to the individual user.
• Record the gap while you still remember what you found and who owns the fix.

Do that for the main access patterns and the weird ones people only use during outages. The weird ones are often where old credentials and bypasses survive.

Final thoughts: Password rules are only useful when the access path makes sense

Requirement 8 is easier to manage when the team stops treating it as a password-policy exercise. The real job is to identify the person, protect the authentication factors, require stronger authentication where the access risk calls for it, and keep enough evidence to show that the setup works.

Start with the CDE boundary and real login paths. Then check the settings, the reset process, MFA coverage, exceptions, and logging. Most authentication gaps become much less mysterious once somebody follows an actual account from sign-in to the system it can reach.

Frequently asked questions about PCI DSS password requirements

What is the minimum password length for PCI DSS v4.0.1?

At least 12 characters when passwords or passphrases are used as authentication factors. If the system cannot support 12, PCI DSS allows a minimum of eight. Alphabetic and numeric characters are required.

Does PCI DSS still require password rotation every 90 days?

Not for every account. Where Requirement 8.3.9 applies to single-factor password access, use a 90-day change or the allowed dynamic account-security analysis. The requirement does not apply where MFA is used for those components.

Does PCI DSS require MFA for everyone?

MFA is required for defined access into the CDE and for remote access that could reach or affect it. The exact rule depends on the user, access path, and whether the access is administrative, internal, or external.

Can a passkey replace MFA under PCI DSS?

For Requirement 8.4.2, qualifying FIDO2 phishing-resistant passkeys can be used as a single factor. For administrative access under 8.4.1 and external remote access under 8.4.3, another factor is still required.

How many failed login attempts does PCI DSS allow?

The user ID must be locked after no more than 10 invalid attempts. The lockout lasts at least 30 minutes or until the user's identity is confirmed.

Can PCI DSS users reuse old passwords?

A new password or passphrase cannot be the same as any of the previous four used by that individual.