How should organisations offboard non-human identities when an employee leaves without breaking critical workflows?

Security teams should inventory every NHI tied to the employee, understand which systems depend on it, and decide whether to revoke, rotate, or transfer ownership. The goal is to remove access quickly without disrupting automation. Prioritise visibility into API keys, OAuth tokens, SSH keys, and service accounts, then use workflow-based deprovisioning to preserve operational continuity.

Why This Matters for Security Teams

Offboarding NHI tied to a departing employee is not a simple access-removal task. The real risk is that one human departure can leave behind API keys, service accounts, OAuth tokens, SSH keys, and automation hooks that continue to run critical jobs. If those identities are revoked blindly, workflows fail; if they are left in place, access persists without ownership. That tension makes NHI offboarding a governance and resilience issue, not just a ticket in IAM.

NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why this control remains weak in practice. The broader lifecycle guidance in the NHI Lifecycle Management Guide is useful here because offboarding only works when ownership, dependency mapping, and rotation are part of the same process. Current guidance also aligns with the NIST Cybersecurity Framework 2.0, especially around asset visibility and access control.

In practice, many security teams encounter broken pipelines or orphaned access only after a departure has already interrupted production, rather than through intentional deprovisioning.

How It Works in Practice

Effective offboarding starts with inventory, not revocation. Security teams should identify every NHI associated with the employee, then classify each one by function: production access, build and deployment automation, third-party integration, or administrative tooling. From there, the team decides whether the identity should be revoked, rotated, transferred, or replaced with a new owner-bound credential.

A practical workflow usually includes:

• Discovering embedded secrets in code, CI/CD, vaults, configuration files, and password managers.
• Mapping each secret to the system, job, or integration that depends on it.
• Determining whether the credential is shared, machine-bound, or tied to one person’s account.
• Rotating secrets before revocation when the NHI is still required for business continuity.
• Rebinding ownership to a service account, team mailbox, or managed workload identity.

The strongest model is workflow-based deprovisioning: the employee’s departure triggers a coordinated set of checks across IAM, PAM, secrets management, CI/CD, and application owners. That approach reduces the chance that a dormant token survives because one team assumed another team would handle it. The risk is especially high when credentials have been hard-coded or copied into multiple tools, a pattern highlighted in NHIMG research on the Top 10 NHI Issues and reinforced by incidents such as the JetBrains GitHub plugin token exposure.

Where possible, organisations should replace person-bound secrets with workload identity, short-lived tokens, and JIT provisioning so the workflow survives the departure without retaining standing privilege. These controls tend to break down in legacy environments where shared service accounts, undocumented scripts, and direct-to-code secrets make ownership and dependency tracing unreliable.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid revocation against service continuity. That tradeoff becomes more complex when the employee owns a critical integration, supports a thinly documented production script, or has embedded credentials in a vendor-managed workflow.

There is no universal standard for every edge case yet, but current guidance suggests treating the following scenarios differently:

• Shared credentials: rotate immediately, then replace with individually attributable access.
• Production service accounts: transfer ownership first, then revoke the departing employee’s ability to use or reset them.
• Automation tied to personal tokens: rebuild the workflow around a non-personal identity instead of preserving the token.
• Emergency access or break-glass accounts: review separately so continuity is preserved without keeping unnecessary standing access.

Offboarding also needs exception handling for third-party systems, because external platforms may not support granular rotation or delegated ownership. In those cases, the best practice is evolving toward compensating controls such as shorter token TTLs, tighter monitoring, and documented fallback procedures. NHIMG’s Lifecycle Processes for Managing NHIs and NIST’s CSF 2.0 both support a repeatable, risk-based process rather than a one-size-fits-all revocation rule.

In mixed legacy and cloud environments, these controls often fail when no one can confidently identify every place a departed employee’s secret was copied or cached.

Related resources from NHI Mgmt Group

• How should organisations govern non-human identities alongside employee access?
• What breaks when organisations try to govern non-human identities without lifecycle ownership?
• How can organisations extend request workflows to non-human identities?
• What breaks when non-human identities are governed only through employee-centric workflows?