Subscribe to the Non-Human & AI Identity Journal

How should security teams automate joiner-mover-leaver processes in IGA programmes?

Security teams should connect identity governance workflows to authoritative HR or asset sources so access provisioning and removal happen from state changes, not manual requests. The priority is complete deprovisioning across all business-critical systems, including legacy platforms that often escape clean automation. Verification matters as much as orchestration.

Why This Matters for Security Teams

Joiner-mover-leaver automation is where identity governance either becomes reliable or becomes a backlog of manual exceptions. For human accounts, delays create inconvenience. For non-human identities, delays create standing access, orphaned secrets, and hidden paths into business-critical systems. That risk compounds quickly when service accounts, API keys, and OAuth grants are scattered across SaaS, legacy applications, and CI/CD tooling. NHI Management Group notes that 91.6% of secrets remain valid five days after notification of compromise, which shows how often deprovisioning breaks down in practice. Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs aligns lifecycle control with the operational reality of NHIs.

The mistake many teams make is treating JML as a ticket routing problem instead of a state management problem. The authoritative source of truth should drive the workflow, but the workflow must also prove that access actually disappeared everywhere it mattered. In practice, many security teams discover stale access only after an employee exit, app migration, or vendor offboarding has already left privileged credentials behind.

How It Works in Practice

Effective JML automation starts by linking identity governance to authoritative sources such as HR systems for people and asset inventories or CMDB records for machine accounts. The workflow should react to state changes, not manual requests. On join, the process provisions only the minimum access needed, ideally through role-based templates and time-bounded approvals. On move, it removes old entitlements first, then reissues only what the new role requires. On leaver, it must revoke access across directories, SaaS apps, SSH keys, tokens, certificates, and privileged accounts without waiting for a human to close each task. NIST’s guidance on governance and access control supports this event-driven approach in principle through the NIST Cybersecurity Framework 2.0.

For NHI-specific environments, the workflow needs additional controls that human IAM often lacks. Current guidance suggests using:

  • authoritative triggers for lifecycle changes, not email approvals or spreadsheet audits
  • JIT provisioning for privileged access, with short TTLs and automatic revocation
  • credential inventory reconciliation so every secret, key, and token is accounted for
  • post-change verification that confirms removal in the target system, not just in the IAM console
  • exception handling for legacy platforms where deprovisioning APIs do not exist

The strongest programmes also track ownership for service accounts and shared integration identities, because offboarding a person often leaves machine access untouched. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs highlights lifecycle visibility as a core control area, and that is exactly what JML automation must produce. These controls tend to break down when legacy platforms, shadow IT, or externally managed apps lack reliable APIs because automated orchestration cannot verify final state.

Common Variations and Edge Cases

Tighter JML automation often increases integration and exception-management overhead, so organisations must balance speed against completeness. Best practice is evolving, especially for machine identities that do not map cleanly to employee lifecycle events. Some teams trigger NHI revocation from asset retirement, workload shutdown, or contract termination rather than from HR status alone, and that is usually the correct model.

Edge cases matter. Shared service accounts, embedded secrets in code, and third-party OAuth grants often require separate offboarding paths because they are not governed by the same workflow as a user account. For these cases, policy should define compensating controls such as vault-managed rotation, break-glass review, or manual attestation with evidence of completion. NHI Management Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes vendor offboarding especially fragile. The most reliable programmes therefore treat JML as a closed-loop process: trigger, provision or revoke, verify, and escalate when verification fails. There is no universal standard for this yet, so teams should document system-specific exceptions rather than assuming one workflow covers every identity type.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 JML automation must fully lifecycle NHI access and remove stale credentials.
NIST CSF 2.0 PR.AA-01 Identity lifecycle governance requires controlled authentication and access handling.
NIST AI RMF Automated identity workflows need governance, accountability, and ongoing monitoring.

Map joiner-mover-leaver steps to identity governance controls and validate access removal after each state change.