Why do standard offboarding processes miss non-human identities?

Why This Matters for Security Teams

Standard offboarding is usually designed to remove a person’s access, not to revoke the machine authority that person created or delegated. That gap matters because NHI sprawl often outlives the employee, contractor, or admin who set it up. NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why abandoned tokens, service accounts, and connectors remain active long after HR has closed the ticket.

The practical problem is that offboarding checklists rarely cover OAuth consents, webhook secrets, shared mailbox automations, CI/CD variables, or low-code integrations. Those objects can keep authenticating, calling APIs, and moving data without a human session attached. The result is not just missed cleanup, but retained privilege across systems that security teams may not even classify as identities. Guidance in the NIST Cybersecurity Framework 2.0 supports lifecycle discipline, but most organisations still operationalise it mainly for workforce accounts.

For a broader lifecycle view, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NHI Lifecycle Management Guide show why lifecycle control must include creation, rotation, and revocation, not just termination. In practice, many security teams discover leftover machine access only after a former employee’s automation has already continued to run in production.

How It Works in Practice

Effective NHI offboarding starts by treating identities, secrets, and delegated authorisations as separate objects that must each be discovered and revoked. A user account deletion does not invalidate an OAuth grant, and disabling a laptop does not remove an API key embedded in a pipeline. That is why current guidance suggests building offboarding around runtime inventory rather than relying on HR events alone.

Practitioners usually need three layers of control:

• Inventory every NHI linked to the person, including service accounts, tokens, certificates, shared inbox automations, and app-to-app trust.
• Revoke or expire credentials first, then remove the human’s delegation path, so machine access cannot persist through cached grants.
• Confirm downstream dependencies, because one shared secret may power multiple applications, jobs, or chatbots.

For implementation detail, security teams can align lifecycle workflows with the Ultimate Guide to NHIs — Standards and use the Top 10 NHI Issues to prioritise the most common failure modes. The operational point is simple: revocation must be automated where possible, time-bounded where automation is not ready, and verified with logging that proves the secret can no longer authenticate. This is especially important because identity sprawl in integrations, CI/CD, and SaaS connectors usually exceeds what a manual offboarding checklist can enumerate. These controls tend to break down in distributed SaaS estates where no single team owns the integration path, because the identity trail is fragmented across HR, IT, and application owners.

Common Variations and Edge Cases

Tighter offboarding often increases administrative overhead, so organisations must balance revocation speed against the risk of breaking critical automations. That tradeoff becomes real when the same NHI supports multiple services, or when a shared mailbox and its automations are owned by different teams.

There is no universal standard for this yet, but current guidance suggests distinguishing between high-risk credentials that should be revoked immediately and low-risk dependencies that can be migrated during a controlled cutover. The hardest edge cases usually involve dormant service accounts, inherited app registrations, and secrets hidden in scripts or CI/CD variables. NHI Mgmt Group’s research shows why this matters: 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 “offboarded” often still means reachable.

Teams should also watch for third-party integrations and personal automation tools that were provisioned through a user’s consent rather than a central IAM process. The 2025 State of NHIs and Secrets in Cybersecurity underscores how often former employee tokens remain active after offboarding, while the JetBrains GitHub plugin token exposure illustrates how overlooked credentials can persist outside the intended control plane. The practical lesson is that offboarding must include shadow inventory, not just the systems that were formally assigned to the person.

Related resources from NHI Mgmt Group

• Why do mover-leaver processes miss so many non-human identities?
• How should security teams handle SaaS offboarding when non-human identities are involved?
• Why do non-human identities complicate standard IAM reviews?
• What breaks when offboarding does not cover non-human identities?