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.
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.
| Control area | Current PCI DSS v4.0.1 rule | What it means in practice |
| Password length and composition | At least 12 characters, or eight if the system does not support 12; both alphabetic and numeric characters. | Check actual system settings, not only the written policy. |
| First use and resets | A unique value is set for first use and after reset, then changed immediately after first use. | Help-desk and admin reset workflows need to match the policy. |
| Password history | A new password cannot be the same as any of the previous four. | Configure the system to enforce it instead of relying on users. |
| Failed attempts | Lock the user ID after no more than 10 failed attempts; lockout lasts at least 30 minutes or until identity is confirmed. | The control needs both a threshold and a safe unlock process. |
| Single-factor password use | Where 8.3.9 applies, change the password at least every 90 days or use dynamic account-security analysis to determine access in real time. | The 90-day rule is not a blanket rule for every password in scope. |
| MFA coverage | MFA is required for specified administrative, CDE, and external remote access. | Map the access path before deciding which MFA rule applies. |
| MFA implementation | Use at least two different factor types, require all factors to succeed, prevent replay, and prevent bypass except tightly controlled temporary exceptions. | A login screen that asks twice for the same kind of factor is not enough. |
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.
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.
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.
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:
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.
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:
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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
Fix authentication gaps before they become assessment findings
Q-Sec supports PCI DSS scoping, readiness, remediation planning, evidence preparation, security testing, and ongoing security controls around the systems in scope.
Explore PCI DSS Compliance ServicesAt 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.
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.
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.
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.
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.
A new password or passphrase cannot be the same as any of the previous four used by that individual.