PCI DSS 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
PCI DSS v4.0.1 control 8.3.5: 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 are set and reset for each user as follows:
- Set to a unique value for first-time use and upon reset.
- Forced to be changed immediately after the first use.
Summary
A first or reset password is unique to that user and must be changed the moment it is first used.
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.5 | Examine procedures for setting and resetting passwords/passphrases (if used as authentication factors to meet Requirement 8.3.1) and observe security personnel to verify that passwords/passphrases are set and reset in accordance with all elements specified in this requirement. |
Two elements, and both are about the window between issuing a credential and the user owning it. Unique rules out a formula: a starting password built from the name, the date, or a company pattern is predictable across every account issued the same way, which is the failure this bullet exists for. Forced to be changed immediately after the first use has to be enforced by the system, not requested in the covering email, and the procedure observes security personnel performing a reset, so the enforcement is watched rather than asserted. Note that the whole control is conditional on passwords being used to meet 8.3.1, which is what its related field points at.
What to prepare
- The procedure for issuing and resetting, showing how the value is generated.
- The system setting that forces the change at first use, for each system that issues credentials.
- Staff available to be observed performing a reset.
- How the credential reaches the user, since a unique value sent insecurely is a different exposure.
How to implement it
1. Generate randomly. It costs nothing, removes the argument about whether a pattern counts as unique, and is visible in the observation the procedure requires.
2. Set the change-at-first-use flag, and check it is set. Most directories have it and it is frequently left off for convenience during bulk onboarding, which is exactly when many accounts are created at once.
3. Give the temporary credential a short life. Nothing in the control requires it, and it closes the window where an unclaimed account sits with a known password.
4. Deliver it out of band. A unique password emailed to a mailbox the user cannot yet reach is a problem you will hit anyway, and solving it properly also improves the reset path.
Where this commonly fails
- A standard starting password used for everyone, which fails uniqueness however complex it is.
- A pattern derived from the user's name or start date, which is unique and predictable at the same time.
- The forced change requested in the email and not enforced by the system.
- Bulk-created accounts issued without the flag, because the batch process skipped it.
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.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity… |
| 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.4 · All controls · 8.3.6 →
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.