How should security teams handle dormant accounts without leaving downstream access behind?

Why This Matters for Security Teams

Dormant accounts are rarely just inactive usernames. In most environments, they are the front door to a wider entitlement graph that includes app roles, API tokens, OAuth grants, delegated admin rights, and service-to-service dependencies. Disabling the visible account without tracing those attachments leaves downstream access behind, which is exactly how access persists after offboarding or role changes. Current guidance in OWASP Non-Human Identity Top 10 and NIST control families pushes teams toward entitlement review, not just account status checks.

This is especially important in hybrid and SaaS-heavy estates where identity providers cannot see every locally issued token or vendor-side permission. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 91.6% of secrets remain valid five days after notification, which means dormant identity cleanup often lags behind actual exposure. The practical risk is that a deprovisioned account can still authorize jobs, integrations, or automation long after the owner is gone, as highlighted in Ultimate Guide to NHIs. In practice, many security teams discover these hidden dependencies only after an audit or incident has already exposed the gap.

How It Works in Practice

The cleanest process starts with inventory, then dependency tracing, then revocation. First, identify the dormant identity in the IdP, HR feed, PAM system, or application directory. Next, map everything that account can still touch: active sessions, refresh tokens, API keys, OAuth grants, SCIM links, mailbox delegation, CI/CD secrets, and any service account impersonation rights. Then revoke in the correct order so downstream systems do not recreate access from cached trust.

For human accounts, this often means disabling login first and then removing app entitlements. For non-human or shared automation identities, the sequence may need to be stricter: rotate secrets, kill tokens, invalidate certs, and update any workload that depends on the old credential before final deletion. NIST guidance on access control and account lifecycle in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of layered revocation, because account state alone is not a sufficient control signal.

• Confirm the identity source of record and whether the account is human, service, or delegated.
• Enumerate linked privileges across SaaS apps, cloud IAM, code repositories, and automation pipelines.
• Revoke refresh tokens, OAuth grants, and long-lived secrets before relying on account disablement.
• Check for local application caches, shadow admin roles, and backup credentials outside the IdP.
• Document what was removed so the same dependency is not reintroduced later.

Where this breaks down most often is in decentralized SaaS and legacy apps that issue their own tokens or maintain separate privilege stores, because the IdP cannot reliably see or revoke every downstream entitlement.

Common Variations and Edge Cases

Tighter cleanup often increases operational overhead, requiring organisations to balance faster deprovisioning against the risk of breaking legitimate automations. That tradeoff is real in finance, healthcare, and engineering environments where dormant accounts may still support batch jobs, shared mailboxes, or third-party integrations. Best practice is evolving, but the direction is clear: treat each dormant account as a dependency problem, not a single-object lifecycle event.

One edge case is the “inactive but necessary” service identity. If a workload only runs monthly, simple inactivity thresholds can create false positives, so teams should verify usage windows before removal. Another is delegated access. A user account may look dormant while mailbox delegation, GitHub app grants, or cloud role assumption still persists under another identity. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference here, especially where visibility into service accounts is incomplete.

Teams should also watch for credentials embedded in code, config, or CI/CD systems, because disabling the parent account does not invalidate the secret already copied elsewhere. That is why dormant-account cleanup needs a parallel secrets review, not a separate ticket filed later. In environments with federated SaaS, partner integrations, or long-lived API consumers, the standard account-disable workflow is usually insufficient unless it is paired with token and entitlement revocation.

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time access without leaving standing privilege behind?
• How should security teams handle AI client access to governed data without shared secrets?
• How can security teams handle shared accounts without losing control?
• How should teams close SaaS access without leaving orphaned licenses behind?