NHI Offboarding vs Human Offboarding: Different Triggers, Owners and Cleanup Steps

Human offboarding has a reliable trigger, an HR leaver event, while non-human identity offboarding usually has no trigger at all, which is why service accounts, keys and tokens survive long after the people and projects that created them. Most organisations have tuned their joiner, mover and leaver process for people over many years, then assume the same process covers the machine credentials those people created. It does not. This guide compares the two processes on what starts them, who owns the decision, what breaks when you get it wrong and what evidence proves it happened. It focuses on the seam between them: the non-human identities (NHIs) a human leaver leaves behind. It is written for identity governance, IAM and platform security teams. The step by step retirement process is in the NHI Offboarding and Decommissioning Guide and the leaver sequence for people is in the Employee Offboarding Security Guide; this page does not repeat them. Where platforms are named they are listed alphabetically.

Key takeaways

• Short answer: humans are offboarded by an event, NHIs must be offboarded by a condition. A leaver has a termination date in the HR system; a service account has no end date unless you record one, so NHI offboarding has to be driven by owner changes, application retirement, contract end and dormancy.
• The two failure modes point in opposite directions. Late human offboarding leaves access open; hasty NHI offboarding breaks production. Human leavers are disabled immediately, NHIs are disabled in a reversible way and watched before deletion.
• Ownership is the hinge. A person owns their own account; an NHI is owned by someone else, and when that someone leaves, the NHI becomes orphaned unless the leaver workflow reassigns it.
• Disabling the person does not disable what they could reach. OWASP's NHI1:2025 names the partially offboarded employee: someone who saw an NHI's credentials and left without them being rotated. The Coupang breach shows the cost.
• Evidence differs. Human offboarding proves the account was disabled on time; NHI offboarding must prove every credential was revoked, every copy found and nothing depended on it.

Why the two processes diverge

OWASP ranks Improper Offboarding first in its Non-Human Identities Top 10 for 2025 and rates it easy to exploit, widespread, hard to detect and severe in technical impact. Its description names three situations: the application that used the NHI is retired and the NHI is forgotten (stale or dormant), the owner leaves and no new owner is assigned (orphaned), and a person who was not the owner saw the credentials and left without revoking them (partially offboarded employee). Only one of those three starts with a person leaving, and even that one is not solved by disabling the person.

Human offboarding sits on a mature foundation. HR is the system of record, the termination date is a data field, and identity governance tools act on it. Microsoft Entra ID Governance lifecycle workflows, for example, run Leaver tasks such as Disable user account, Remove users from all groups, Revoke all refresh tokens for user and Delete user on a schedule tied to the user's attributes. NIST SP 800-53 has a dedicated control, PS-4 Personnel Termination, alongside AC-2 Account Management. There is no equivalent of PS-4 for a workload: AC-2 covers system accounts, but nothing in the organisation emits a "this service account has left" event.

Side-by-side comparison

Human offboarding: threat model and failure modes

Threat model: the adversary is the leaver (malicious or disgruntled), or an outsider who takes over an account that should have been disabled. Exposure lasts from the last working day to the moment every session and token is revoked.

Architecture in words: HR records the leaver date; the IGA or IdP picks it up; a workflow disables the account, revokes refresh tokens, removes group and licence assignments and notifies the manager; SaaS outside single sign-on is closed by hand or by SCIM deprovisioning.

Failure modes are well known: SaaS accounts not federated to the IdP, sessions and refresh tokens left valid after the password changes, contractors and guests with no HR record, and delays when HR enters the date late. These are covered in the Joiner-Mover-Leaver Guide and the Employee Offboarding Security Checklist. The one failure that matters here is structural: the human process ends when the person's own identity is disabled, and it has no step for identities the person owned or could see.

NHI offboarding: threat model and failure modes

Threat model: the adversary is anyone who obtains a credential that nobody is watching: a former employee who kept a copy, a supplier who received a token for a pilot, or an outsider who finds a key in a repository or a breached third party. Dormant NHIs often keep elevated permissions, and their use looks like normal automation.

Architecture in words: an NHI is created by a person or a pipeline, granted permissions, and its credential is copied into the places that use it. Retirement means finding the owner, confirming the purpose has ended, finding every consumer, removing privilege, disabling reversibly, watching, revoking every credential and copy, then deleting with a record.

• No trigger fires: the application is switched off but its service account, keys and OAuth grants remain, because retirement in the change process does not reach identity.
• Ended engagement: a token given to a third party for a short pilot is never revoked. In the Klue OAuth Breach 2026, a GitHub personal access token from a 2022 pilot that was later abandoned stayed active for about four years and was used in June 2026 to add code that collected customers' Salesforce OAuth tokens.
• Breaking production: a clean-up job deletes an "unused" key that a quarterly batch job needed, and the next run fails. This is the reason teams are reluctant to retire anything, which makes the dormant population grow.
• Partial revocation: the service account is deleted but its key in a CI variable, a second client secret or a long-lived certificate remains valid somewhere else.

The seam: NHIs a human leaver leaves behind

The highest-risk cases sit between the two processes. A developer, administrator or integration engineer leaves; the human workflow runs correctly; the machine credentials they created, owned or could read are untouched. OWASP's example scenarios include exactly this: a former employee who managed automated services keeps working credentials even after their personal account was disabled, and a business-critical application's access key stays active after the developer who built it leaves.

The Coupang Breach 2025 is the clearest illustration. A developer on the user authentication system left at the end of 2024 and kept a token signing key. Investigators found the key was never revoked or rotated after he left, had a validity period of years and was stored on developer computers. Forged tokens were accepted from April to November 2025, and the government investigation confirmed 33.67 million records exposed. The leaver's own access was not the problem; the signing key he could reach was.

The third row is the hardest. Ownership can be read from directory attributes, but "who could read this secret" needs vault audit logs and access policies. Treat every secret reachable by a privileged leaver as exposed and rotate it, accepting that rotation takes engineering effort. The rotation process is in the Secrets Rotation Runbook Template and signing keys in the JWKS and Signing Key Rotation Guide.

Triggers and ownership models

Because NHIs have no HR record, offboarding needs several triggers wired to the systems that do know when something ends. Each trigger maps to one of OWASP's three situations.

On ownership, three models are common, and each fails differently:

• Individual owner: simple and auditable, but the NHI orphans the day that person leaves. Acceptable only if the leaver workflow reassigns ownership.
• Team owner: survives individual departures, but "the platform team" can become nobody. Pair a team owner with a named accountable person who is reviewed at each mover event.
• Sponsor plus manager fallback: the person who requested the identity sponsors it, and ownership falls to their manager when they leave. Microsoft Entra lifecycle workflows include a Leaver and Mover task, Transfer agent identity sponsorships to manager, which adds the manager as sponsor of each agent identity the user sponsors and removes the user; it needs the manager attribute to be populated. The same pattern can be built for other NHI types with custom task extensions or an IGA connector.

Two or more owners per production NHI is the practical default. Microsoft's enterprise application documentation shows that owners can add and remove other owners, which lets a remaining owner repair the record without a ticket to administrators. See the NHI Ownership Guide and How to assign owners to orphaned service accounts.

Controls that close the gap

• Owner-linked triggers: extend the leaver workflow to query the NHI inventory for every identity the leaver owns or sponsors, and open a reassignment task for the manager before the last day. Block the human account's deletion until each item is closed or explicitly accepted.
• Staged disable for NHIs: never delete first. AWS lets you set an access key to Inactive before deleting it; GitHub organisations can require administrator approval for fine-grained personal access tokens and set maximum token lifetimes, so tokens end by policy rather than by memory; Google Cloud recommends disabling a service account before deleting it so you can confirm nothing critical depends on it; Microsoft Entra lifecycle workflows can disable and later delete accounts on a schedule.
• Credential-level revocation: retiring an account is not enough. List every key, secret, certificate and token, and search code, CI variables and vaults for the key ID or client ID.
• Rotation on privileged leavers: make rotation of reachable shared secrets a mandatory leaver step for administrators, developers on authentication or payment systems, and anyone with vault read access to production.
• End dates at creation: record owner, purpose and expected end condition when an NHI is created, and use expiry where the platform supports it. GitHub's organisation lifetime policy defaults to a 366-day maximum for fine-grained tokens.
• Workload identities over personal credentials: automation should not run under a person's account or personal token, because then the human and the NHI share one fate. Use service principals, managed identities or federation.
• Revocation evidence: keep a record per NHI of approver, reason, credentials revoked, watch-period result and deletion date, linked to the leaver or change ticket that triggered it.

Decision criteria: which process, how fast

The main trade-off is breakage against exposure. For human leavers, breakage is cheap and exposure is expensive, so speed wins. For NHIs, the balance depends on privilege: a dormant read-only reporting key can wait for a watch period, while a signing key or tenant-wide credential a hostile leaver could have copied should be rotated even if something breaks.

Small organisations can add a single question to the leaver checklist ("what keys, tokens, service accounts or integrations did this person create or see?") and keep a spreadsheet register of NHIs with an owner column. Large organisations should drive it from data: an NHI inventory joined to the HR feed so that every leaver event lists the identities affected, as described in the NHI lifecycle automation guide.

Worked scenario: a platform engineer leaves

A senior platform engineer gives four weeks' notice. HR enters the leaver date and the human workflow is scheduled. The joined workflow then runs as follows:

1. Inventory query (week 1): the NHI inventory returns 14 identities: 6 service accounts and 2 app registrations where the engineer is owner, 3 personal access tokens they created, a deploy key, and vault read access to a production database credential and a JWT signing key.
2. Reassign (week 1 to 2): the manager assigns each owned identity to a team with a named lead; two service accounts are found to serve a retired staging environment and go to the NHI retirement process.
3. Migrate automation (week 2 to 3): two scheduled jobs running on the engineer's personal tokens are moved to a workload identity, tested, and the personal tokens revoked.
4. Last day: the human workflow disables the account, revokes refresh tokens and removes group and licence assignments.
5. Rotation (last day plus 5 days): the database credential and signing key are rotated. Signing key rotation follows the published key set process so existing tokens expire gracefully.
6. Retire (over 30 days): the two staging service accounts are disabled, watched for authentication attempts, then deleted.
7. Evidence: one record links the leaver ticket to every NHI decision and every revocation timestamp.

Without the joined workflow, the human process would have finished on the last day and all 14 items would have stayed as they were.

Detection and measurement

Watch for authentication by any NHI whose owner has left, any use of a credential after its owner's leaver date that originates from a new network location, any authentication attempt against a disabled NHI during its watch period (a missed dependency or an attacker), and tokens or keys older than policy. Useful metrics:

• Orphan rate: percentage of NHIs with no active owner; target near zero for production.
• Leaver NHI closure time: days from leaver date until every owned NHI is reassigned or retired.
• Privileged leaver rotation coverage: percentage of privileged leavers whose reachable secrets were rotated within the agreed window.
• Dormant privileged NHIs: count of NHIs with administrative or write permissions and no use in the dormancy window.
• Retirement without incident: percentage of NHI retirements completed without rollback, a measure of dependency mapping quality.

Framework mapping

Common failure patterns

• Leaver workflow ends at the person: account disabled on time, owned and reachable NHIs untouched. The Coupang signing key case is the extreme form.
• Automation under personal identities: disabling the leaver breaks scheduled jobs, so the account is re-enabled "temporarily" and stays enabled.
• Retirement without identity: an application is decommissioned in the CMDB while its keys and OAuth grants live on.
• Third-party pilot tokens: credentials given to suppliers have no owner on your side and no end date, as in the Klue case.
• Delete first: a clean-up deletes an identity with a hidden dependency, the outage makes teams afraid to retire anything, and the dormant population grows.

Practitioner checklist

• Every NHI has a named owner (person plus team), a purpose and an end condition recorded at creation.
• The human leaver and mover workflow queries the NHI inventory and opens reassignment tasks before the last day.
• Privileged leavers trigger rotation of every shared secret and signing key they could read.
• No automation runs under a personal account or personal token.
• Application, contract and pilot retirements trigger NHI retirement through the change process.
• NHI retirement uses privilege removal, reversible disable and a watch period before deletion.
• Every credential and copy is revoked, not just the account object.
• Revocation evidence links each NHI decision to the triggering ticket.
• Orphan rate and leaver NHI closure time are reported monthly.

Standards and references

• OWASP: NHI1:2025 Improper Offboarding
• NIST: SP 800-53 Rev 5 Security and Privacy Controls (AC-2, IA-5, PS-4, PS-5)
• NIST: Cybersecurity Framework 2.0
• AWS: Manage access keys for IAM users
• GitHub: Setting a personal access token policy for your organization
• Google Cloud: Disable and enable service accounts
• Microsoft: Lifecycle workflow built-in tasks
• Microsoft: Assign enterprise application owners

Related NHI Mgmt Group resources: NHI Offboarding and Decommissioning Guide, Employee Offboarding Security Guide, OWASP NHI Top 10 NHI1 Improper Offboarding Guide, Entra ID Governance Lifecycle Workflows, Insider NHI Misuse Breaches Lessons Guide.