PCI DSS 8.3.9: If passwords/passphrases are used as the only authentication factor for user access
PCI DSS v4.0.1 control 8.3.9: 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 the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
- Passwords/passphrases are changed at least once every 90 days, OR
- The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
Summary
If a password is the only thing standing between a user and access, either change it every 90 days or run a system that judges account posture in real time.
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.9 | If passwords/passphrases are used as the only authentication factor for user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the elements specified in this requirement. |
This is the control most often applied where it does not apply. The 90-day change is conditional: it bites only where passwords are the only authentication factor for user access. Where multi-factor authentication is in place for that access under 8.4.1 to 8.4.3, this control is satisfied without any rotation at all. Entities routinely rotate everything quarterly out of habit inherited from earlier versions, which costs users something and buys nothing the standard asks for. The requirement is also an either/or, and the procedure says to verify one of the elements: the second option, dynamic analysis of account posture driving real-time access decisions, is a genuine alternative rather than an aspiration, though it is a substantial capability to evidence.
What to prepare
- A list of access paths, marked with whether they are single-factor or multi-factor.
- Password age configuration for the single-factor ones.
- If relying on the second option, the system performing the analysis and evidence that access decisions follow from it.
How to implement it
1. Work out where the control applies before configuring anything. The list of genuinely single-factor user access is usually shorter than expected, and it is the only place rotation is required.
2. Prefer removing the condition to meeting it. Adding a second factor to a single-factor path satisfies this control and improves several others at the same time.
3. Do not rotate what does not need rotating. Frequent forced changes push users toward predictable patterns, which is why the standard narrowed the requirement, and 8.3.7 cannot detect an appended digit.
4. If you choose the second option, be able to show the decision. Posture analysis that produces a dashboard rather than an access outcome does not meet the wording, which requires access to be automatically determined.
Where this commonly fails
- Rotating every password in the estate on the assumption that 90 days is universal.
- Missing an actual single-factor path, such as a legacy application or an appliance that cannot do MFA, which is where the control genuinely applies.
- Claiming the dynamic-analysis option with a tool that reports risk but does not determine access.
- MFA present at the perimeter and absent for a direct internal path, leaving that path single-factor and unrotated.
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.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.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.8 · All controls · 8.3.10 →
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.