PCI DSS 8.3.7: Individuals are not allowed to submit a new password/passphrase that is the same as any
PCI DSS v4.0.1 control 8.3.7: 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
Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
Summary
A new password cannot be any of the previous four.
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.7 | Examine system configuration settings to verify that password parameters are set to require that new passwords/passphrases cannot be the same as the four previously used passwords/passphrases. |
A fixed number read from configuration, so it is one of the quickest controls to pass or fail. The trap is not the number: it is what sits next to it. A history of four with no minimum password age is defeated in a minute, because a user can change the password five times in a row and land back on the one they started with. Nothing in this control mentions minimum age, which is why it is worth stating here rather than discovering it in a review. History also has to be enforced wherever the password lives, so any system with its own credential store needs the setting individually, not just the directory. It interacts with 8.3.9: where passwords are the only factor and change every 90 days, a history of four is one year of reuse protection at most.
What to prepare
- Password policy configuration for every system holding credentials, not only the primary directory.
- The minimum password age setting alongside the history setting.
- Evidence for applications with their own password stores, which are checked separately.
How to implement it
1. Set a minimum age of at least one day. It is what makes the history mean anything, and it is a one-line change.
2. Set history higher than four where the platform allows. Four is the floor, not a target, and a larger history costs nothing.
3. Enumerate the systems with their own password policy. The directory is usually correct and the standalone application is usually at its default.
4. Check the value rather than the policy document. The procedure examines system configuration settings, so that is the only artefact that counts.
Where this commonly fails
- History enforced with no minimum age, so the requirement is satisfied in configuration and defeated in practice.
- Applications with their own credential stores left at vendor defaults.
- A documented policy of four with the setting never applied.
- Users appending an incrementing digit, which the history check cannot see and which is a reason to prefer length over rotation where 8.3.9 allows it.
Related controls
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.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.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.6 · All controls · 8.3.8 →
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.