How should organisations automate joiner, mover, and leaver workflows across human and non-human identities?

Start by defining lifecycle events in one control model, then connect HR, identity providers, cloud apps, and NHI systems to the same provisioning and revocation logic. Use role-based access bundles for joiners, remove obsolete permissions for movers, and enforce verifiable deprovisioning for leavers. The goal is complete execution, not just workflow approval.

Why This Matters for Security Teams

Joiner, mover, and leaver automation is often treated as an HR efficiency project, but for security teams it is really an access-control integrity problem. When human and non-human identities follow different offboarding paths, organisations create blind spots where service accounts, API keys, and cloud roles outlive the business need that created them. That is why NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them reliably, according to the Ultimate Guide to NHIs.

The practical risk is not just delayed deprovisioning. It is orphaned access, broken ownership chains, and mover events that quietly preserve privileges no longer justified by role or project scope. Control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for timely access revocation, but most enterprises still implement this only for employees, not the machine identities tied to CI/CD, integrations, and workload-to-workload access. In practice, many security teams discover the failure only after a departed employee still owns the service account that keeps production systems reachable.

How It Works in Practice

Strong lifecycle automation starts with a single identity governance model that treats joiners, movers, and leavers as events, not tickets. The event source may be HR for employees, a contractor system for external staff, or an application owner workflow for machine identities, but the provisioning engine should consume the same state changes and apply policy consistently. For humans, that usually means role-based access bundles, approval gates, and periodic recertification. For NHIs, it means binding access to workload identity, ownership metadata, and expiry rules instead of a permanent shared secret.

For joiners, the workflow should create accounts, assign baseline entitlements, and issue only the minimum needed NHI credentials or trust bindings. For movers, it should remove obsolete group memberships, cloud roles, token scopes, and application permissions before assigning the new bundle. For leavers, the process must do more than disable a directory account. It should revoke API keys, rotate shared secrets, invalidate tokens, terminate ephemeral sessions, and remove the identity from automation pipelines and secrets stores. The operational goal is verifiable deprovisioning, not an approval record. That matters because credential leaks often persist in code and tooling long after the original owner has changed; incidents such as Code Formatting Tools Credential Leaks show how residual secrets become reusable attack paths.

Current best practice is to connect identity provider events, cloud IAM, PAM, secrets management, and CMDB-style ownership data so every entitlement has a clear system of record. For NHI-heavy environments, policy should also define whether credentials are static, short-lived, or fully federated through workload identity. NIST’s identity lifecycle guidance in the broader control family supports this kind of continuous enforcement, and NHI Mgmt Group’s Ultimate Guide to NHIs highlights why visibility into service accounts is a prerequisite for reliable offboarding. These controls tend to break down when cloud, SaaS, and CI/CD systems each maintain their own isolated identity state because no single system can prove revocation completed everywhere.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance speed of provisioning against assurance that access was actually removed. That tradeoff becomes sharper in environments with shared service accounts, long-running batch jobs, regulated change windows, or external partner integrations.

There is no universal standard for every mover scenario yet. Current guidance suggests treating high-risk moves, such as a developer joining a production-support team, as a privilege reduction problem first and a reassignment problem second. In practice, that means stripping old access before granting new access, then forcing re-attestation where duties overlap. For leavers, partial automation is not enough when an identity owns secrets embedded in scripts, pipeline variables, or third-party SaaS connectors. The GitHub Action tj-actions Supply Chain Attack is a reminder that automation platforms themselves can become persistence points if revocation is not propagated across all connected systems.

One useful pattern is to separate entitlement approval from lifecycle execution. Approval confirms business intent; execution confirms technical completion. That distinction matters most for NHIs because deprovisioning may require secret rotation, token invalidation, and dependency cleanup across multiple owners. If that cleanup cannot be verified, the identity should remain in a remediation queue rather than be marked closed.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should teams secure non-human identities across cloud and SaaS?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?