What breaks when non-human identities are managed with human joiner-mover-leaver processes?

Why JML Breaks Down for Non-Human Identities

Joiner-mover-leaver processes work because people have predictable employment milestones. Non-human identities are different: they are created for systems, integrations, automations, and APIs, then left to outlive the original owner, business case, or runtime. Once you treat those identities as if they will be naturally removed by HR events, lifecycle gaps appear immediately.

The biggest break is that the control point shifts from a person leaving to a workload still existing. That means access can continue even when the integration should have been retired, the secret should have been rotated, or the service should no longer authenticate anywhere. NHIMG’s Joiner-Mover-Leaver Guide is useful here because it frames the real problem as lifecycle automation, not employee administration.

Managing non-human identities through a human lifecycle also blurs ownership. A service account can be tied to a project, a team, or a vendor dependency, but not to a clean joiner or leaver event. Without explicit ownership, deprovisioning becomes reactive, exceptions pile up, and the organisation loses track of which credentials, tokens, and certificates still matter.

What Goes Wrong Operationally

When JML is the only lifecycle mechanism, three failure patterns usually show up: stale access, orphaned identities, and hidden credentials. The identity may no longer have a valid business purpose, but it still authenticates, still has entitlements, and still depends on secrets that are difficult to inventory. Service Account Security Guide covers the practical side of discovering and governing those accounts across different environments.

Human movers also do not map cleanly to machine change. A developer changing teams does not necessarily mean the CI/CD pipeline, database connector, or cloud workload they built should retain the same permissions. If the access model is not decoupled from the person, privilege creep accumulates as inherited access survives long after the role change. IAM and IGA Basics is relevant because it connects provisioning, access reviews, and entitlement governance to that longer-lived access problem.

Offboarding is often the most visible failure, but it is not the only one. Non-human identities can also be over-provisioned at creation, reused across environments, or left with broad standing permissions because no one wants to break an automated dependency. Top 10 NHI Issues is a good reference point for the recurring patterns that emerge when those identities are managed too casually.

What JML Must Become Instead

The correct model is identity lifecycle management for the workload itself, not for the human who requested it. That means creating an explicit owner, an expiry or review point, and a revocation path for the secret or credential material that makes the identity useful. If the non-human identity cannot be tied to a current system purpose, it should be reviewed as an exception rather than allowed to persist by default. NHI Ownership and Accountability Guide reinforces why ownership is the control that prevents these identities from becoming invisible.

Practically, this shifts the question from “who joined or left?” to “what changed in the service, integration, or trust relationship?” That change may require credential rotation, entitlement reduction, environment separation, or full decommissioning. Guide to NHI Rotation Challenges is relevant because the revocation side of the lifecycle is often the hardest part to execute cleanly at scale.

For organisations that rely heavily on cloud or automation, the lifecycle also has to account for short-lived credentials and federated trust rather than static passwords. In those environments, the lifecycle control is less about “remove the user” and more about “expire the trust path, revoke the token, and ensure the workload cannot silently keep operating.” Cloud Workload Identity Guide and NHI Authentication Guide both support that operational model.

Practitioner Guidance

What to prioritise: Separate the identity owner from the person who created it. For every service account, token, or certificate, require a business owner, a technical owner, and a review date so revocation is triggered by asset purpose, not employee status.

What to verify: Confirm that leaver workflows actually remove or expire the non-human credentials they are supposed to cover. The best test is whether you can prove the secret was rotated, the token was invalidated, and the downstream integration either failed safely or was intentionally re-authorised.

Common mistake: Treating non-human access as “temporary” just because it was created for a project. In practice, temporary service access often becomes permanent standing access unless someone owns its retirement.

Practitioner takeaway: JML breaks for non-human identities when process ownership follows the employee instead of the machine, so the control objective must be lifecycle accountability for the workload and its credentials, not just the person who requested them.

Related resources from NHI Mgmt Group

• Why do mover-leaver processes miss so many non-human identities?
• How should organisations automate joiner, mover, and leaver workflows across human and non-human identities?
• What breaks when non-human identities are managed separately from AI security?
• What breaks when joiner, mover, leaver processes are handled differently for technical accounts?