PCI DSS 8.3.6: If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity
PCI DSS v4.0.1 control 8.3.6: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 8.3.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.3
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
- A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
- Contain both numeric and alphabetic characters.
Summary
Passwords must be at least 12 characters and mix letters and numbers, unless the system genuinely cannot support 12, in which case eight is the floor.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.3.6 | Examine system configuration settings to verify that user password/passphrase complexity parameters are set in accordance with all elements specified in this requirement. |
A single procedure, and it examines system configuration settings rather than your policy. A password standard that says 12 characters while the identity provider is configured to enforce eight fails this control. Note the shape of the exception: eight characters is permitted only where the system does not support 12, which is a technical limitation you should be able to demonstrate, not a preference.
What to prepare
- Exported configuration from every authentication system showing the enforced minimum length and complexity, not the written policy.
- A list of every system where users authenticate into the CDE, including any that authenticate locally rather than through the identity provider.
- For any system enforcing eight characters, evidence that it cannot support 12.
How to implement it
1. Change the configuration, then evidence the configuration. This control is tested against settings. Update the identity provider, the directory, and any application enforcing its own password policy, then export each one.
2. Find the systems that bypass your identity provider. Legacy applications with local accounts, network device logins, and database users are the usual gaps, and each enforces its own rules.
3. Treat the eight-character exception as a documented exception. If a system cannot do 12, record which system, why, and what compensates. An undocumented eight-character minimum simply reads as non-compliance.
4. Remember this only applies where passwords are the factor under 8.3.1. If a system uses multi-factor or phishing-resistant authentication, read 8.3.1 first to see what actually applies to it.
Where this commonly fails
- The policy document says 12 characters and the identity provider is still set to the old 7-character rule from v3.2.1.
- The main directory is compliant but a legacy application with local accounts is not, and nobody listed it as an authentication system.
- Service and application accounts overlooked, when 8.6 covers them separately and they often have the weakest credentials of all.
Related controls
This control refers to 8.3.1.
Others in section 8.3:
| Control | What it requires |
|---|---|
| 8.3.1 | All user access to system components for users and administrators is authenticated via at least… |
| 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission… |
| 8.3.3 | User identity is verified before modifying any authentication factor |
| 8.3.4 | Invalid authentication attempts are limited… |
| 8.3.5 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user… |
| 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any… |
| 8.3.8 | Authentication policies and procedures are documented and communicated to all users… |
| 8.3.9 | If passwords/passphrases are used as the only authentication factor for user access… |
| 8.3.10 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users… |
| 8.3.10.1 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either… |
| 8.3.11 | Where authentication factors such as physical or logical security tokens, smart cards… |
← 8.3.5 · All controls · 8.3.7 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.