PCI DSS 8.2.1: All users are assigned a unique ID before access to system components or cardholder data
PCI DSS v4.0.1 control 8.2.1: the requirement in full, the 2 testing procedures 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
All users are assigned a unique ID before access to system components or cardholder data is allowed.
Summary
Everyone gets their own ID before they get any access. No shared logins.
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.1.a | Interview responsible personnel to verify that all users are assigned a unique ID for access to system components and cardholder data. |
| 8.2.1.b | Examine audit logs and other evidence to verify that access to system components and cardholder data can be uniquely identified and associated with individuals. |
The foundation the whole of Requirement 10 rests on: an audit log is only evidence if an action traces to a person, and a shared account makes every log entry ambiguous. Two procedures, and 8.2.1.b examines system components to verify unique IDs are in use, so this is checked against real accounts rather than policy. The exceptions people reach for: a shared administrator account, a rota login on a terminal, a service account used interactively: are exactly what the control exists to remove, and where a shared account genuinely cannot be avoided, 8.2.2 sets specific conditions rather than granting a pass.
What to prepare
- An account inventory across in-scope components, showing one identity per person.
- Evidence for any shared or generic account still in use, and the 8.2.2 conditions met for it.
- The joiner process, showing the ID exists before access is granted.
How to implement it
1. Look for the accounts that are not people. admin, root, deploy, support and the vendor account are the ones shared in practice, and they are usually the most privileged.
2. Federate where you can. Single sign-on makes uniqueness a property of the identity provider instead of something each system has to be checked for individually.
3. Separate interactive from automated use. A service account used by a person for troubleshooting is a shared account in the sense that matters, and 8.6.1 governs when that is permitted at all.
4. Grant the ID before the access, in that order. The requirement says before access is allowed, and provisioning that grants access to a group first is how a shared credential appears.
Where this commonly fails
- A shared administrator credential kept for emergencies and used routinely.
- Vendor or support accounts shared across their staff, so no action traces to a person.
- Rota or kiosk logins on shared terminals.
- Uniqueness assumed from the identity provider while local accounts exist on individual components.
Related controls
Others in section 8.2:
| Control | What it requires |
|---|---|
| 8.2.2 | Group, shared, or generic IDs, or other shared authentication credentials are only used… |
| 8.2.3 | Service providers with remote access to customer premises use unique authentication factors… |
| 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.1.2 · All controls · 8.2.2 →
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.