PCI DSS 8.2.6: Inactive user accounts are removed or disabled within 90 days of inactivity
PCI DSS v4.0.1 control 8.2.6: 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
Inactive user accounts are removed or disabled within 90 days of inactivity.
Summary
An account that has not been used in 90 days is disabled or removed.
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.6 | Examine user accounts and last logon information, and interview personnel to verify that any inactive user accounts are removed or disabled within 90 days of inactivity. |
Ninety days of inactivity, measured from last use, not ninety days after somebody noticed. That distinction matters because the six-monthly review in 7.2.4 cannot be the mechanism: a review every six months cannot enforce a ninety-day threshold. The procedure examines user accounts and last logon information, which means the last-logon data has to exist and be retained, and that is the practical obstacle in older systems and in applications that do not record it. The edge case worth deciding in advance is the account that has never been used at all: it has no last logon, and the sensible reading is that its clock starts at creation.
What to prepare
- An account listing with last logon for every in-scope system, not only the directory.
- The automated or scheduled mechanism that acts on the threshold.
- Evidence of accounts actually disabled by it, since a rule with no effect looks the same as no rule.
- The decision on never-used accounts, written down.
How to implement it
1. Automate it. Ninety days is too short for a manual cycle to enforce reliably, and an automated disable is also the evidence.
2. Find the systems that do not record last logon before the assessment does. Where the data does not exist the control cannot be demonstrated, and the fix is usually configuration rather than replacement.
3. Disable rather than delete, at least first. Disabling satisfies the requirement, is reversible, and avoids the orphaned-data problems that deletion creates.
4. Include service and vendor accounts in the sweep, then exclude deliberately. Some genuinely sit idle by design, and an exclusion you decided is defensible where one you never noticed is not.
Where this commonly fails
- Relying on the six-monthly access review, which cannot enforce a ninety-day threshold.
- Last logon not retained, so the control cannot be evidenced even where it is being met.
- Accounts created for a project, never used, and never captured because there is no last-logon date to compare.
- The sweep applied to the directory only, while application-local accounts age untouched.
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.4 | Addition, deletion, and modification of user IDs, authentication factors… |
| 8.2.5 | Access for terminated users is immediately revoked |
| 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.5 · All controls · 8.2.7 →
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.