PCI DSS 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
PCI DSS v4.0.1 control 8.3.10.1: 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
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer 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
Service providers only: where a password is the only factor for customer user access, it changes every 90 days, or you 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.10.1 | Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access, inspect system configuration settings to verify that passwords/passphrases are managed in accordance with ONE of the elements specified in this requirement. |
The enforcement counterpart to 8.3.10, which is guidance. 8.3.10 asks you to tell customers when to change; this one puts an obligation on the outcome, and it is the same either/or as 8.3.9 applies to your own users. Two consequences follow. The condition is still that a password is the only factor, so offering customers multi-factor authentication and having them use it removes the requirement entirely, which is both less work and a better product. And where the condition does apply, guidance alone is not enough: something has to make the change happen or determine access dynamically.
What to prepare
- Which customer access paths to cardholder data are single-factor.
- The password age configuration enforced on those paths.
- If relying on the second option, the system performing the analysis and evidence that access decisions actually follow from it.
How to implement it
1. Establish the condition before configuring anything. If customer access already uses a second factor this control does not apply, and forcing 90-day changes on customers is a support burden bought for nothing.
2. Offer multi-factor authentication to customers. It removes this control and 8.3.10 together, and it is the change customers benefit from rather than tolerate.
3. Enforce it rather than requesting it. The distinction from 8.3.10 is that this is an outcome, so a reminder email is guidance and not enforcement.
4. If you claim the dynamic option, show the access decision. Posture analysis that produces a risk score without determining access does not meet the wording.
Where this commonly fails
- Meeting 8.3.10 with guidance and assuming it covers this control, which asks for the change itself.
- Rotation forced on all customers including those already using multi-factor authentication, where the control does not apply.
- A legacy customer integration that authenticates with a password alone and was never counted.
- A merchant applying this to itself, when it is a service provider requirement.
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.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.11 | Where authentication factors such as physical or logical security tokens, smart cards… |
← 8.3.10 · All controls · 8.3.11 →
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.