PCI DSS 8.2.3: Service providers with remote access to customer premises use unique authentication factors
PCI DSS v4.0.1 control 8.2.3: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 8.2.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.2
Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
Summary
Service providers only: if you reach into customer premises remotely, each customer gets its own authentication factor rather than one credential that opens all of them.
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.2.3 | Additional testing procedure for service provider assessments only: Examine authentication policies and procedures and interview personnel to verify that service providers with remote access to customer premises use unique authentication factors for remote access to each customer premises. |
Service providers only. The control exists because of a specific failure mode: a provider that uses one credential across its whole customer base turns a single compromise into a compromise of every customer at once. Note the unit. The requirement says unique factors for each customer premises, not for each technician, so per-engineer credentials that work everywhere do not satisfy it. If you are the merchant rather than the provider, this is not your control, but it is worth asking about during the due diligence in 12.8.3, because your exposure to it is real and you cannot test it yourself.
What to prepare
- The authentication policy covering remote access to customer environments.
- How credentials are issued and separated per customer, and where they are stored.
- Personnel to interview, since the procedure is policy plus interview rather than configuration.
How to implement it
1. Separate at the customer boundary, not at the technician. One credential per engineer that works across every customer is the arrangement this control is written against.
2. Use a vault with per-customer scoping. It is the practical way to keep uniqueness without asking engineers to remember which credential belongs to whom, and it gives you the issuance record as a side effect.
3. Make offboarding per-customer too. Losing a customer should revoke that customer's factors, and it is easier to evidence when they were separate to begin with.
4. Say it in the customer agreement. 12.8.2 is the customer's side of the same relationship, and stating the arrangement there means both parties can evidence it.
Where this commonly fails
- One shared support credential reused across customers, which is precisely the pattern the control names.
- Unique per engineer and identical across customers, which reads as uniqueness and is not what is required.
- A remote support tool with a single provider-side account, so the uniqueness exists only in the ticketing system.
- A merchant applying this to itself, which is effort spent on a control that does not apply.
Related controls
Others in section 8.2:
| Control | What it requires |
|---|---|
| 8.2.1 | All users are assigned a unique ID before access to system components or cardholder data… |
| 8.2.2 | Group, shared, or generic IDs, or other shared authentication credentials are only used… |
| 8.2.4 | Addition, deletion, and modification of user IDs, authentication factors… |
| 8.2.5 | Access for terminated users is immediately revoked |
| 8.2.6 | Inactive user accounts are removed or disabled within 90 days of inactivity |
| 8.2.7 | Accounts used by third parties to access, support… |
| 8.2.8 | If a user session has been idle for more than 15 minutes… |
← 8.2.2 · All controls · 8.2.4 →
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.