PCI DSS 8.2.4: Addition, deletion, and modification of user IDs, authentication factors
PCI DSS v4.0.1 control 8.2.4: 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
Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
- Authorized with the appropriate approval.
- Implemented with only the privileges specified on the documented approval.
Summary
Adding, changing and removing user IDs and authentication factors is approved first, and what gets implemented is only what the approval said.
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.4 | Examine documented authorizations across various phases of the account lifecycle (additions, modifications, and deletions) and examine system settings to verify the activity has been managed in accordance with all elements specified in this requirement. |
The identity lifecycle where 7.2.3 is the privilege approval. They overlap and are tested separately, so meeting one does not carry the other. The second bullet is where this is lost: implemented with only the privileges specified on the documented approval. An approval exists, more was granted than it listed, and the control fails even though nothing was unapproved in spirit. The single procedure examines authorisations across additions, modifications and deletions and then examines system settings, so it compares the paperwork against reality at all three points of the lifecycle. Deletions are the phase entities have least evidence for, because removing access rarely generates a request.
What to prepare
- Approval records for a sample of additions, modifications and deletions.
- Current system settings for those same identities, so approval and outcome can be compared.
- The definition of who may approve, which the procedure needs in order to test "appropriate approval".
How to implement it
1. Grant exactly what was approved, and nothing convenient alongside it. Adding the group that "everyone in that team has" is the usual way the second bullet fails.
2. Give deletions a record too. A leaver process that removes access without documenting the authorisation leaves the deletion phase unevidenced, and the procedure looks at all three phases.
3. Approve before implementing, and let the timestamps show it. Retrospective approvals are visible as such in any ticketing system.
4. Cover authentication factors, not just accounts. The control names authentication factors and other identifier objects, so issuing a token or resetting a factor is in scope as much as creating the account.
Where this commonly fails
- More privilege granted than the approval specified, which fails the second bullet with an approval in hand.
- Deletions performed without a documented authorisation, leaving a third of the lifecycle unevidenced.
- Approvals held in email rather than with the identity record, so they are not findable when the assessor samples.
- Bulk account creation for a project, approved as a batch with no record of the privileges each received.
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.3 | Service providers with remote access to customer premises use unique 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.3 · All controls · 8.2.5 →
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.