PCI DSS 8.2.1: Everyone gets their own ID before they get any access. No shared logins.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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: 8.2.1.a interviews responsible personnel, and 8.2.1.b examines audit logs and other evidence to verify that access can be uniquely identified and associated with individuals, so this is checked against real activity 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. The one carve-out is in the applicability notes: user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction are outside this control.
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 puts most identities in one place, but the requirement still covers every system component, so each one needs checking for local accounts, and each of those needs a unique ID too.
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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.