PCI DSS 8.2.2: Group, shared, or generic IDs, or other shared authentication credentials are only used
PCI DSS v4.0.1 control 8.2.2: the requirement in full, the 3 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
Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
- ID use is prevented unless needed for an exceptional circumstance.
- Use is limited to the time needed for the exceptional circumstance.
- Business justification for use is documented.
- Use is explicitly approved by management.
- Individual user identity is confirmed before access to an account is granted.
- Every action taken is attributable to an individual user.
Summary
Shared logins only by exception: justified, authorised, time-limited, and with every action still traceable to a person.
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.2.a | Examine user account lists on system components and applicable documentation to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement. |
| 8.2.2.b | Examine authentication policies and procedures to verify processes are defined for shared authentication credentials such that they are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement. |
| 8.2.2.c | Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement. |
The narrow exception to 8.2.1. It is not a permission to keep shared accounts; it is a set of conditions that make one temporarily defensible, and the hardest is the last: individual user identity is confirmed before access, so actions taken under the shared ID can still be attributed. That is what keeps Requirement 10 meaningful. Most entities that rely on this control meet the first three conditions and not the fourth, because the shared credential is typed directly rather than being brokered by something that records who asked for it.
What to prepare
- The list of shared or generic IDs still in use.
- The business justification and management authorisation for each.
- Evidence use is time-limited rather than standing.
- The mechanism that attributes use of the shared ID to an individual.
How to implement it
1. Broker the credential rather than sharing it. A privileged access tool that checks out the password, records who took it and rotates it afterwards satisfies the traceability condition, which typing a shared password never does.
2. Put an expiry on the justification, not just the session. "Needed for legacy system X" with no review becomes permanent, and the requirement asks for the exceptional circumstance to be bounded.
3. Prefer removing the need. Most shared accounts exist because a system cannot federate. Replacing it is usually cheaper over time than operating this control around it.
4. Reconcile against 10.x. If a log entry under a shared ID cannot be traced to a person, the logging controls inherit the ambiguity, which is the real cost.
Where this commonly fails
- A shared administrator credential in a password manager, treated as satisfying attribution.
- Justifications recorded once and never revisited, so the exception is permanent.
- Use unlimited in time, when the requirement bounds it to the circumstance.
- The fourth condition ignored entirely, leaving audit logs that name an account rather than a person.
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.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.2.1 · All controls · 8.2.3 →
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.