PCI DSS 8.2.2: Shared logins only by exception: justified, authorised, time-limited, and with every action still traceable to a person.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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. Like 8.2.1, it does not apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. It is not a permission to keep shared accounts; it is a set of conditions that make one temporarily defensible, and the hardest are the last two: individual user identity is confirmed before access to the account, and every action taken is attributable to an individual user. That is what keeps Requirement 10 meaningful. A shared credential typed directly cannot meet those last two conditions, because nothing records who asked for it; one brokered by a tool that checks it out to a named person can.
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. Some shared accounts exist only 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 last two conditions 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.