Who should own lifecycle workflows across joiners, movers, and leavers?

One accountable identity or IT operations owner should govern the workflow, even if different approvers participate by role. Shared ownership without clear accountability leads to gaps in execution and verification. The workflow owner should be responsible for completion evidence, escalation, and exception tracking.

Why This Matters for Security Teams

Joiners, movers, and leavers workflows define whether identities, access, and credentials change cleanly as people change roles or exit. The risk is not just slow provisioning, but incomplete revocation, orphaned access, and undocumented exceptions that outlive the business need. For NHI programs, lifecycle ownership must extend beyond human accounts into service accounts, API keys, and automation credentials, which are often more persistent and harder to track than employee access.

When ownership is unclear, the workflow becomes a coordination problem instead of a control. Security may define policy, IAM may execute changes, and IT operations may hold system knowledge, but one accountable owner must be able to prove completion. That is the difference between a control that exists on paper and one that actually removes access. This is why the NHI Lifecycle Management Guide treats lifecycle governance as an operational discipline, not just an access review activity.

It also matters because lifecycle failure is where compromise becomes durable. NHIs are often overprivileged, reused across systems, and left active long after business changes, which makes the leaver step especially critical. In practice, many security teams encounter stale access only after an audit failure, incident, or former-account abuse, rather than through intentional lifecycle verification.

How It Works in Practice

The most effective model is a single accountable owner for the end-to-end workflow, usually within identity operations, IAM, or IT operations, with business and technical approvers participating by role. That owner should not personally approve every change. Instead, they govern the process, define service-level expectations, verify evidence, and own escalation when a joiner, mover, or leaver action stalls.

For humans, that means tracking onboarding, transfers, and terminations through a workflow that ties HR events to identity actions, then to application and infrastructure updates. For NHIs, the same logic applies but the triggers are system events: new application deployment, owner change, service retirement, credential rotation, or environment decommissioning. The workflow owner should require evidence that access was created, changed, or removed, and that secrets, tokens, certificates, and keys were handled consistently.

A practical workflow usually includes:

• Joiners: create only the access needed for the task, with approval and traceability.
• Movers: remove old entitlements before or at the same time as new ones are granted.
• Leavers: revoke access, disable accounts, rotate secrets, and confirm downstream cleanup.
• Exceptions: document compensating controls, expiry dates, and revalidation owners.

For NHI-heavy environments, the workflow must also cover where credentials live, because leaks often persist outside vaults. The Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 both reinforce the need for lifecycle ownership that includes revocation, rotation, and visibility, not just ticket closure. These controls tend to break down when ownership is split across HR, app teams, and platform teams because each group assumes someone else will verify the final state.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance faster delivery against stronger verification. That tradeoff is especially visible in engineering-led environments where service accounts are created rapidly, inherited across pipelines, or embedded in infrastructure-as-code.

There is no universal standard for the exact owner title, but current guidance suggests the owner should sit close enough to execution to enforce completion, while remaining independent enough to escalate failures. In mature environments, that is often an identity operations lead. In smaller organisations, it may be a platform or IT operations manager with explicit accountability.

Edge cases matter. M&A activity, outsourced operations, and legacy applications often expose gaps where no single team can change the credential or account directly. In those cases, the owner should still track the exception, assign an expiry, and define the compensating control. The same is true for NHIs that cannot be immediately rotated or decommissioned. The relevant question is not who touched the ticket, but who can prove the lifecycle outcome.

Where organisations treat joiners, movers, and leavers as a shared responsibility without a named owner, delayed revocation and orphaned credentials become normalised. That failure pattern is documented repeatedly in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Guide to the Secret Sprawl Challenge.

Related resources from NHI Mgmt Group

• How should teams govern asset lifecycle workflows across users and devices?
• Who should own lifecycle decisions when access is delegated across IT, HR, and app owners?
• Who should own lifecycle governance across IAM and access controls?
• Who should own automated compliance workflows across IAM and NHI?