Why do orphaned service accounts and tokens create so much risk after offboarding?

Why This Matters for Security Teams

orphaned service account and tokens matter because they preserve machine access long after the human relationship ends. That turns offboarding into an identity governance gap, not a simple HR process. NHI exposure is especially dangerous because tokens are often embedded in automation, CI/CD, and SaaS integrations, where they are easy to overlook and hard to trace back to a current owner.

The risk is not theoretical. NHI Management Group’s research on The 2025 State of NHIs and Secrets in Cybersecurity, attributed to Entro Security, found that 91% of former employee tokens remain active after offboarding. That means a departure can leave direct access to repositories, cloud services, and business workflows unless machine identities are explicitly revoked. Current guidance from NIST Cybersecurity Framework 2.0 reinforces that access control must be continuously governed, not assumed complete after a checklist item is closed.

In practice, many security teams encounter the breach after the employee has already left and the token has already been reused, rather than through intentional offboarding validation.

How It Works in Practice

Effective offboarding has to treat non-human identities as first-class assets. The operational question is not only “disable the user” but “find every service account, API key, certificate, OAuth grant, and automation token tied to that person or their work.” The NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both emphasize that lifecycle ownership, inventory, and revocation must be linked before separation occurs.

In practice, teams usually need a combination of discovery, dependency mapping, and automated revocation:

• Inventory every secret and service account associated with the departing worker, team, or application.
• Trace where each token is used, including scripts, CI/CD runners, SaaS connectors, and scheduled jobs.
• Rotate or revoke credentials immediately, not on a delayed renewal cycle.
• Confirm replacement credentials are issued to the owning workload before old ones expire.
• Log the revocation event so audits can show who owned the identity, when it was retired, and what system replaced it.

This is where machine identity becomes essential. A service account should not exist only because a person once needed it. It should exist because a workload still needs it, with bounded scope and a clear expiration path. The broader secrets problem is why the Secret Sprawl Challenge remains so relevant: if tokens are duplicated across chat, tickets, and code, offboarding becomes a search problem before it becomes a revocation problem. NIST guidance is clear that access governance should be continuous, and Top 10 NHI Issues highlights lifecycle failure as a recurring pattern. These controls tend to break down in highly automated environments with shared secrets because ownership is unclear and revocation can interrupt production dependencies.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance faster security action against application stability and recovery effort. That tradeoff is real when one token supports multiple services, legacy systems lack per-workload identity, or a third-party integration cannot tolerate immediate credential rotation.

Best practice is evolving, but current guidance suggests treating high-risk tokens differently from low-impact automation credentials. For example, externally reachable APIs, admin-grade tokens, and secrets tied to finance or customer data should be revoked immediately, while lower-impact credentials may use a staged cutover with monitoring. Where possible, teams should prefer short-lived tokens and workload-bound identities over long-lived shared secrets. That reduces the blast radius if offboarding is missed.

Edge cases usually appear in environments with inherited access, joint ownership, or service accounts created years ago with no documented owner. In those cases, the right answer is not to keep the token alive indefinitely, but to assign explicit ownership, establish a retirement date, and replace the secret with a properly scoped workload identity. The recurring lesson from incidents such as the Salesloft OAuth token breach is that unused or forgotten tokens become active attack paths as soon as one compromise reveals them.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of orphaned service accounts and stale tokens?
• Why do service accounts create so much hidden risk in SaaS stacks?
• Why do service accounts and delegation settings create so much risk in Active Directory?
• Why do service accounts create so much access governance risk?