Inactive Account Disabling

“Inactive account disabling” is a simple-sounding requirement that fails in execution because different systems record “last activity” differently, identity platforms don’t always cover everything in PCI scope, and exceptions (service accounts, break-glass IDs, third-party support access) quietly accumulate. PCI DSS 4.0.1 Requirement 8.2.6 sets a clear baseline: inactive user accounts must be removed or disabled within 90 days of inactivity. (PCI DSS v4.0.1 Requirement 8.2.6)

For a Compliance Officer, CCO, or GRC lead, the fastest path to a durable control is to treat this as an access lifecycle control with three deliverables: (1) a precise definition of inactivity for each in-scope system, (2) a repeatable operational runbook that identifies accounts past the threshold and disables or removes them, and (3) evidence that proves the control ran and produced timely outcomes.

This page gives requirement-level implementation guidance you can hand to IAM, IT operations, and application owners, with a focus on auditability and coverage across the CDE and connected systems in scope.

Regulatory text

Requirement: “Inactive user accounts are removed or disabled within 90 days of inactivity.” (PCI DSS v4.0.1 Requirement 8.2.6)

What an operator must do:
You need a process (preferably automated) that identifies user accounts that have not had activity for the defined period and then removes or disables them within the required window. “User accounts” includes accounts that can authenticate to systems in PCI scope; the control must work across platforms, not just in one directory. (PCI DSS v4.0.1 Requirement 8.2.6)

Plain-English interpretation

If an account hasn’t been used for long enough to meet the inactivity definition, it becomes a liability. Attackers look for dormant accounts because they often have lingering access and weak monitoring. This requirement forces you to (a) know which accounts exist in scope, (b) know when each was last used, and (c) take action—disable or remove—before inactive access becomes an entry point. (PCI DSS v4.0.1 Requirement 8.2.6)

Two practical clarifications to decide internally and document:

• What counts as “activity.” For many systems, “last login” is the cleanest signal. For others, you may need to use “last authentication,” “last interactive sign-in,” VPN use, privileged access tool checkout, or application session logs.
• Remove vs. disable. Disabling is usually operationally safer (recoverability, investigations). Removal is acceptable if your joiner/mover/leaver process and audit trail remain intact.

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, and payment processors that must comply with PCI DSS. (PCI DSS v4.0.1 Requirement 8.2.6)

Operational scope (where it bites):

• CDE systems (servers, databases, applications handling cardholder data) and the identity stores they rely on.
• Connected systems in scope (jump hosts, bastions, admin consoles, SIEM access, backup consoles, patching systems, endpoint management) where a dormant account could be used to pivot.
• Third-party access paths used for support, managed services, or incident response, if those accounts can access in-scope environments.

What you actually need to do (step-by-step)

1) Set your inactivity standard and account categories

Create a short standard that answers, for each account type:

• Interactive workforce accounts: “Inactive” = no successful authentication event recorded by the authoritative identity source for the system.
• Privileged accounts: same as above, but validate that privileged access pathways (PAM checkout, bastion login) also feed the inactivity signal.
• Emergency/break-glass accounts: define a special handling procedure (see “Exceptions” below) but still track activity and disablement decisions.
• Service/non-interactive accounts: decide whether they are “user accounts” in your environment and how you measure “activity” (e.g., credential use, token use). If you cannot measure meaningfully, treat them as exceptions with alternate controls and explicit owner review.

Deliverable: Inactivity definition + account taxonomy in an access management standard mapped to PCI scope. (PCI DSS v4.0.1 Requirement 8.2.6)

2) Build a complete inventory of in-scope accounts

You cannot disable what you don’t know exists. For PCI scope, inventory accounts from:

• Central IAM/SSO directory exports
• Local OS accounts on in-scope servers (including break-glass local admin)
• Application-native user tables for CDE apps
• Database users for in-scope databases
• Network/security tooling accounts (firewalls, WAF, SIEM, EDR consoles) in scope

Deliverable: System-by-system account inventory with owner, account type, and where “last activity” is sourced.

3) Identify the authoritative “last activity” field per system

For each system, document:

• The field name (e.g., lastLoginTimestamp, lastSignInDateTime, last_auth, last_used)
• The event source (identity provider logs, OS auth logs, app audit logs)
• Known limitations (field updates only on interactive login; excludes API token use; resets on password change; etc.)

Deliverable: Evidence map that tells an auditor exactly how inactivity is detected per platform.

4) Implement detection: recurring report + threshold logic

Run a recurring job or report that produces, per system:

• Accounts with last activity older than the threshold
• Accounts with no recorded activity (never used) after provisioning
• Accounts excluded as exceptions, with documented reason and review date

Make this report reproducible. Auditors will ask for consistency and completeness.

Implementation options:

• Native IAM reports (directory sign-in reports, admin portals)
• SIEM queries against authentication logs
• Custom scripts for systems without reporting APIs
• GRC workflow tooling to route findings to owners and track closure

If you use Daydream, treat this as a control with a defined evidence package and an automated collection schedule so every review cycle produces a dated artifact set without manual screenshot hunts.

5) Execute disabling/removal with approvals and ticketing

Define the operational workflow:

1. Generate the inactive account list for each in-scope system.
2. Route to system owner for confirmation (valid account vs. should be retired).
3. Disable or remove the account in the target system.
4. Record the action (ticket ID, change record, approver, timestamp, system).
5. Verify the account can no longer authenticate (spot-check or automated test).

Key decision: default to disable first, then remove later if your retention policy allows. Either approach satisfies the requirement as long as access is ended and evidence exists. (PCI DSS v4.0.1 Requirement 8.2.6)

6) Handle exceptions explicitly (don’t let them sprawl)

Create an exceptions register for accounts that cannot be cleanly governed by inactivity:

• Third-party support accounts that must exist but are rarely used
• Service accounts where “inactivity” is hard to measure
• Break-glass accounts that must remain enabled for resiliency reasons (if that’s your stance)

For each exception, require:

• Business justification
• Compensating control(s) (e.g., stronger authentication, restricted source IP, monitored use, time-bound enablement)
• Account owner and review cadence
• Evidence of each review and the decision outcome

This keeps you honest in audits: you either comply directly, or you show disciplined exception governance tied to risk.

7) Prove ongoing operation

Auditors and QSAs test that the process is not a one-time cleanup. Build a cadence:

• Scheduled report generation
• Scheduled remediation window
• Escalation path for owners who do not act

Make the process resilient to org changes (owner changes, mergers, system migrations) by baselining it in policy and runbooks.

Required evidence and artifacts to retain

Keep evidence that answers three questions: what you checked, what you found, what you did.

Minimum useful artifact set:

• Written procedure / standard defining inactivity, scope, account types, and actions. (PCI DSS v4.0.1 Requirement 8.2.6)
• System inventory of in-scope platforms and account sources.
• Recurring inactive account reports (dated exports or SIEM query outputs).
• Disablement/removal logs: admin audit logs, directory logs, system change records.
• Ticketing evidence: request, approval, implementation, closure notes.
• Exceptions register with approvals and review evidence.
• Sampling packet: for a subset of accounts, show before/after (present on report; then disabled in logs).

Tip: Store artifacts in a single audit binder structure by system and review cycle. Daydream can function as the system of record for evidence requests, due dates, and reusable artifacts across PCI assessments.

Common exam/audit questions and hangups

Expect these lines of testing:

• “Show me the report you use to identify inactive accounts and the date it ran.”
• “How do you define inactivity for this application, and where is that documented?”
• “Prove the accounts were disabled/removed within the required window.” (PCI DSS v4.0.1 Requirement 8.2.6)
• “How do you cover local accounts on servers and appliances?”
• “What about third-party accounts and shared admin IDs?”
• “How do you ensure the process runs consistently if the IAM team is unavailable?”

Hangup to avoid: presenting a policy statement without showing operational outputs and timestamps.

Frequent implementation mistakes and how to avoid them

• Mistake: Only covering SSO and ignoring local/app-native accounts.
  Fix: require each in-scope system owner to attest to their account sources and last-activity signal.
• Mistake: Treating service accounts as out of scope by default.
  Fix: categorize them, assign owners, and document either measurable activity or exception controls.
• Mistake: Manual screenshots as primary evidence.
  Fix: exportable reports and log pulls; make them reproducible.
• Mistake: No ownership.
  Fix: every system has an accountable owner for remediation, not just IAM.
• Mistake: Disabling without a trace.
  Fix: tickets + admin logs + report snapshots; one without the others triggers audit friction.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, dormant accounts increase the chance of unauthorized access because they can be missed by monitoring and reviews, especially when ownership changes or third-party relationships end. PCI assessors commonly treat weak access hygiene as a sign of broader control gaps, which can expand testing and remediation scope.

A practical execution plan (30/60/90-day)

This requirement has a fixed threshold, so plan your rollout around immediate coverage and repeatability. The phases below are designed to get you to “works in production” quickly and then harden.

First 30 days: Establish scope, definitions, and quick wins

• Publish an inactivity standard with system-specific signals and account categories. (PCI DSS v4.0.1 Requirement 8.2.6)
• Inventory all in-scope systems and their account repositories.
• Run baseline reports for the top identity sources (SSO/directory, VPN, bastion, critical apps).
• Do a first remediation sweep: disable obvious dormant interactive accounts with clear owners and low operational risk.
• Stand up an exceptions register and force all non-standard accounts into it.

Next 60 days: Automate and close coverage gaps

• Integrate log sources into a repeatable reporting mechanism (IAM reporting, SIEM queries, or scripts).
• Cover “edge” systems: appliances, databases, admin consoles, and application-native user stores.
• Implement a standard ticket workflow with required fields (system, account, last activity, action, approver).
• Add escalation paths for non-responsive owners and define a default action.

By 90 days: Operationalize as BAU and make it audit-ready

• Demonstrate at least one full control cycle with dated evidence: report → tickets → disablement logs.
• Formalize exception reviews and tie them to ownership changes and third-party offboarding.
• Add QA checks: reconcile account inventories against HR rosters, third-party access lists, and system exports.
• Package artifacts into an assessment-ready binder, or manage them continuously in Daydream to reduce audit scramble. (PCI DSS v4.0.1 Requirement 8.2.6)

Frequently Asked Questions

Does disabling an account satisfy the inactive account disabling requirement, or must we delete it?

The requirement allows either removed or disabled accounts, as long as inactive user accounts are addressed within the required window. Disabling is often operationally safer because it preserves history and supports investigations. (PCI DSS v4.0.1 Requirement 8.2.6)

What counts as “inactivity” if a user only accesses via SSO?

Use the authoritative identity event as the source of truth (for example, SSO sign-in logs) and document that mapping per system. If an app has local accounts that bypass SSO, you still need local evidence for those accounts.

How should we handle service accounts that don’t have interactive logins?

Classify them explicitly, assign an owner, and define how you detect “activity” (credential use, token use, job execution logs). If you cannot measure it reliably, document an exception with compensating controls and periodic owner review. (PCI DSS v4.0.1 Requirement 8.2.6)

Do break-glass accounts have to be disabled if they’re not used?

They are still accounts that can grant access, so they need governance. Many teams keep them disabled by default and enable only during an incident, or keep them enabled with strict compensating controls and documented reviews; pick one approach and retain evidence.

We have contractors and third-party support users. Are they covered?

Yes if those accounts can access PCI in-scope systems. Treat them like any other user account: track last activity, disable/remove when inactive, and maintain ownership and offboarding controls. (PCI DSS v4.0.1 Requirement 8.2.6)

What evidence will a QSA accept without argument?

A dated inactive-account report, tickets or change records showing approvals and actions, and system audit logs proving the disablement/removal occurred. Pair that with a written procedure defining inactivity per system. (PCI DSS v4.0.1 Requirement 8.2.6)