Why do mover-leaver processes miss so many non-human identities?

Why This Matters for Security Teams

Mover-leaver processes are often effective for employees because the trigger is a clean HR event. That model breaks for NHI because the identity is attached to a workload, pipeline, integration, or shared automation, not a person. By the time a human exits, the real risk is often the live service account, API key, certificate, or token that was created, copied, or reused along the way. NHI Mgmt Group research shows only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why exit workflows miss so much machine access; see the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NIST Cybersecurity Framework 2.0. The problem is not just inventory. It is attribution, ownership, and revocation speed across systems that were never designed to map access back to a single leaver event. In practice, many security teams encounter stale machine access only after an incident review, rather than through intentional offboarding control testing.

How It Works in Practice

A strong mover-leaver process for NHIs has to follow the access path, not the person chart. That means identifying where a departing employee could have influenced machine access: CI/CD variables, code repositories, vault entries, local config files, cloud roles, and shared service accounts. Once those touchpoints are known, the organisation can revoke or rotate secrets, remove delegated permissions, and check whether the workload identity itself still has an owner. Guidance in the JetBrains GitHub plugin token exposure case shows how a single exposed token can become a durable access path long after the original human context disappears. That is why machine offboarding needs both lifecycle control and secret hygiene, not just HR deletion workflows.

Practitioners typically need four steps:

• Maintain an inventory of NHIs tied to systems, repos, and pipelines.
• Map each NHI to an owner, purpose, scope, and rotation schedule.
• Revoke or reissue secrets immediately when staff leave or role boundaries change.
• Verify that dependent services still work under least privilege after rotation.

For mature programmes, this also aligns with zero trust thinking in NIST Cybersecurity Framework 2.0: access should be continuously validated, not assumed to remain safe after onboarding. The key issue is that many NHIs are created outside central IAM, which makes them invisible to leaver checklists and hard to retire cleanly. These controls tend to break down in fast-moving DevOps environments because secrets are copied into build tools and ephemeral jobs faster than ownership records are updated.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance stronger revocation against deployment speed and service continuity. The tradeoff is especially sharp where multiple teams share the same automation, because one person may have touched a secret without being the true owner of the workload. Current guidance suggests treating this as an ownership problem first and a revocation problem second, but there is no universal standard for this yet. Some teams solve it with PAM and RBAC reviews; others move toward JIT access and short-lived credentials so there is less to clean up at departure time.

Edge cases also appear in vendor-managed integrations, CI/CD runners, and support scripts that were created by a former employee but are now embedded in business processes. In those environments, the leaver event is just the last visible symptom. The real control is to shorten secret lifetime, centralise workload identity, and confirm that access is tied to runtime need rather than a historical user association. NHI Mgmt Group’s lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames offboarding as part of the full lifecycle, not a one-time HR action.

Related resources from NHI Mgmt Group

• How can teams reduce risk from stale non-human identities?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do non-human identities create more IAM risk than many teams expect?