Why do dormant accounts and privilege drift increase governance risk?

Dormant accounts and privilege drift extend access beyond current business need, which increases the number of identities that can be misused, overlooked, or exploited. They also weaken audit confidence because reported policy and actual access diverge. In practice, the longer excess access persists, the larger the governance and security gap becomes.

Why This Matters for Security Teams

Dormant accounts and privilege drift are governance problems before they become incident problems. They create a mismatch between what policy says should exist and what access actually remains in production. That gap weakens recertification, makes exceptions harder to track, and leaves security teams with more identities that can be forgotten, misused, or inherited by the wrong owner. The risk is especially visible in NHI-heavy environments where service accounts, API keys, and OAuth grants accumulate outside normal employee lifecycle controls.

Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point to the same operational issue: access must be continuously governed, not just approved once. NHIMG research also shows why this matters in practice. In The 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they have experienced or suspect a breach involving non-human identities. In practice, many security teams encounter excessive access only after audit findings, token abuse, or a production incident has already exposed the drift.

How It Works in Practice

Dormant accounts increase risk because they are still valid identities even when no one is actively watching them. Privilege drift increases risk because access slowly expands beyond the original business need through role changes, temporary exceptions, inherited permissions, or forgotten integrations. Together, they create a long tail of excess access that is difficult to inventory and even harder to justify during audit. The problem is not only over-permissioning. It is the operational inability to prove that access remains current, necessary, and owned.

Security teams usually address this through lifecycle controls, entitlement reviews, and automated detection of inactive identities. For NHIs, that means mapping each account or token to a business owner, a system owner, and a purpose. It also means using policy and telemetry to catch drift before it becomes normalised. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle discipline is the main control that keeps access from accumulating silently. For broader governance and audit framing, see Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

• Detect inactivity with a defined TTL, not with informal “last seen” assumptions.
• Re-certify access against current job function, system purpose, or integration need.
• Remove standing privileges that are only needed occasionally and replace them with JIT access where feasible.
• Reconcile IAM records with actual tokens, secrets, and app grants so drift is not hidden behind stale inventory.

For a practical example of how unmanaged OAuth grants can persist, the Salesloft OAuth token breach shows how retained access can become an attack path long after the original trust decision. These controls tend to break down in fast-moving SaaS environments because ownership changes, app integrations, and exception handling outpace review cycles.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance reduction in risk against the cost of review, remediation, and service disruption. That tradeoff is real, especially where legacy applications, shared service accounts, or third-party integrations cannot tolerate frequent change. Best practice is evolving, but there is no universal standard for every environment yet.

Some dormant accounts should not be deleted immediately if they are tied to legal retention, disaster recovery, or a dependent system that is not yet modernised. In those cases, the safer approach is to disable, isolate, or monitor them rather than leave them fully active. Privilege drift also appears differently across environments. In cloud platforms, it often shows up as role sprawl and inherited permissions. In SaaS, it is commonly embedded in app-to-app authorisations and delegated OAuth grants. In on-premises estates, it may be buried in service accounts that no one fully owns.

NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same point: governance risk rises when access is allowed to persist without evidence of continued need. The question is not whether access was once approved, but whether it is still justified today.

Related resources from NHI Mgmt Group

• Why do multi-agent systems increase NHI governance risk?
• Why do non-human identities create more audit risk than human accounts?
• Why do Salesforce integrations increase NHI risk?
• When do service accounts become a higher risk than ordinary user accounts?