PCI DSS 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
PCI DSS v4.0.1 control 8.3.10: 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 to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users including:
- Guidance for customers to change their user passwords/passphrases periodically.
- Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
Summary
Service providers only: if your customers reach cardholder data with a password alone, tell them when and why to change it.
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 | Additional testing procedure for service provider assessments only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, examine guidance provided to customer users to verify that the guidance includes all elements specified in this requirement. |
Service providers only, and it is a guidance obligation rather than an enforcement one. The control asks that you provide customer users with guidance on changing passwords periodically and on when and under what circumstances to change them. The procedure examines the guidance itself, so the artefact is a document you give customers, not a setting on your platform. It applies only where a password is the only factor for customer user access to cardholder data, which means offering customers multi-factor authentication and having them use it removes the condition, the same way 8.3.9 works for your own users. Merchants reading this are on the receiving side: it is reasonable to ask a provider for this guidance during the due diligence in 12.8.3.
What to prepare
- The guidance as customers actually receive it, whether that is onboarding material, in-product help or the terms.
- Evidence it reaches customer users rather than only the customer's account manager.
- Confirmation of which customer access paths are single-factor.
How to implement it
1. Cover both bullets explicitly. Periodic change is one, and when and under what circumstances is the other, which means naming the events: suspected compromise, a shared device, a departing employee at the customer.
2. Put it where the user is. Guidance in a contract reaches the signatory. Guidance in the product reaches the person with the password, who is the customer user this control names.
3. Offer multi-factor authentication and this control stops applying. It is also the better product, and it moves the customer off the single-factor path that made the control relevant.
4. Keep it consistent with your own policy. Advising customers to do something you do not do internally is a difference an assessor will notice.
Where this commonly fails
- Guidance that covers periodic change and omits the circumstances, which is half of a two-element control.
- Advice buried in terms and conditions, so customer users never see it.
- A merchant applying this to itself, when it is a service provider requirement.
- Assuming it does not apply because customers could enable MFA, when the condition is whether a password is in fact the only factor.
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.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.9 · All controls · 8.3.10.1 →
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.