Joiners, movers and leavers automation is identity governance at scale

At a glance

What this is: A practical guide to JML automation showing how lifecycle-triggered access changes reduce manual work and close joiner, mover, and leaver gaps.

Why it matters: It matters because lifecycle failures erode least privilege across human and non-human access, creating hidden exposure that IAM, IGA, and PAM teams must govern continuously.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's guide on joiners, movers and leavers automation

Context

Joiners, movers, and leavers, or JML, is the access lifecycle problem that turns identity governance into an operational discipline. The core issue is simple: access should change when a person joins, changes role, or leaves, but manual processes usually fail to keep pace with those events.

That gap matters across human identity programmes, contractor access, and any environment where entitlement changes need to be repeatable and auditable. A mature JML model protects least privilege over time, rather than treating provisioning and offboarding as one-time tasks.

For teams managing broader identity sprawl, the lifecycle lens has to extend beyond employees. The same governance logic that covers joiners and leavers for staff also applies to contractors, vendors, and other identities that need access removed when the relationship ends.

Key questions

Q: How should security teams automate joiner, mover, and leaver access changes?

A: Security teams should tie access decisions to authoritative lifecycle signals such as HRMS create, update, and termination events, then map those signals to predefined entitlement rules. Joiners should receive birthright access automatically, movers should have old access removed and new access added in one flow, and leavers should trigger full revocation and data handoff.

Q: Why do mover events create more identity risk than joiners or leavers?

A: Mover events are risky because the excess access usually does not break anything, so it remains invisible for long periods. Joiner mistakes are obvious because work cannot start. Leaver mistakes are obvious because access should disappear immediately. Mover errors accumulate silently and create privilege creep across roles, applications, and permission scopes.

Q: What breaks when offboarding does not include shadow IT?

A: When offboarding ignores shadow IT, former users can keep active access to applications IT never tracked, including trials, department-managed tools, and self-service SaaS. That leaves residual access after separation even when central systems look clean. A complete leaver process needs discovery of the full access footprint before credentials are revoked.

Q: Who is accountable when lifecycle access changes are not completed on time?

A: Accountability should sit with the identity or IT owner who controls lifecycle workflow design, because incomplete JML is a governance failure, not a user behaviour issue. The relevant control question is whether the organisation can prove that provisioning, changes, and revocation happen from authoritative signals and are auditable end to end.

Technical breakdown

How HRMS-triggered provisioning works in JML

A joiner workflow starts when the HR system creates a new worker record and passes attributes such as role, department, seniority, location, and employment type into an automation engine. Those attributes map to birthright access, which is the baseline entitlement set for that role. Mature JML also uses contextual recommendations to add peer-driven apps and in-app groups, so onboarding is not limited to a static application list. The technical value is that the lifecycle event becomes the trigger, not a ticket.

Practical implication: connect HR attributes to entitlement rules so joiner access is created from policy, not manual interpretation.

Mover access recalculation and permission scope drift

Mover handling is harder because the system must remove old access and add new access at the same time, often across multiple applications with different permission models. HRMS-triggered movers provide a reliable signal, but event-based movers often arrive without a formal system change and therefore need structured requests with expiry. The important technical point is that access should be recalculated at the new role scope, not merely carried forward. Otherwise privilege accumulation becomes invisible until audit or incident response.

Practical implication: chain removal and provisioning together, and force time-bound approval for any access granted outside HR-triggered events.

Leaver deprovisioning across shadow IT and data handoff

Leaver workflows need to scan the full access footprint, because the riskiest exposure is usually outside centrally managed SaaS. A complete offboarding sequence revokes application access, backs up data, reassigns ownership, removes licenses, and deletes accounts including cloud data where appropriate. The technical challenge is completeness. If the workflow only covers what IT already knows, shadow IT, department-managed tools, and self-service trials remain active after separation.

Practical implication: build offboarding around full footprint discovery, not a checklist of approved applications.

NHI Mgmt Group analysis

JML automation is now a baseline governance requirement, not an efficiency upgrade. Manual joiner, mover, and leaver handling breaks because identity change is continuous while human intervention is intermittent. The result is access drift, delayed revocation, and entitlement gaps that no static review cycle can fully catch. Practitioners should treat lifecycle automation as part of core IAM control design, not a back-office convenience.

Role-change handling exposes the most persistent form of privilege creep. Movers are dangerous because the failure does not immediately interrupt work, so the excess access stays hidden. That makes mover governance a better measure of identity maturity than onboarding speed. Teams that do not recalculate access at each transition are allowing least privilege to decay in place.

Lifecycle governance now has to span employees, contractors, and other external identities. The article is strongest where it extends JML beyond full-time staff, because the offboarding problem is structurally the same across identity types. The difference is the trigger source and the data available at deprovisioning time. Practitioners should stop treating employee JML as a separate discipline from broader access lifecycle governance.

Access reviews alone do not solve lifecycle failure. Reviews look backward, while JML automation changes access at the point of lifecycle event. That distinction matters because the control objective is not to discover stale access eventually, but to prevent it from becoming normal. Programmes that rely on review to compensate for broken lifecycle handling are accepting avoidable residual risk.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why lifecycle and revocation failures persist in practice.
• The Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the best next resource for teams formalising joiner, mover, and leaver controls.

What this signals

Identity lifecycle automation is becoming the only defensible way to keep pace with workforce change. JML processes that depend on tickets and manual follow-up will continue to lag behind role changes, terminations, and contractor churn. Teams should expect more pressure to prove that access changes are triggered from authoritative sources and completed without drift.

Lifecycle governance now needs to include external identities, not just employees. Contractors, vendors, and partners often sit outside HR-driven controls, which means offboarding and access expiry have to be designed explicitly. Programmes that only automate employee lifecycle events are leaving a structurally important part of the access surface unmanaged.

Access review will not compensate for missing lifecycle triggers. Reviews can detect stale entitlements, but they do not remove the operational delay between role change and entitlement change. Organisations should use JML automation to reduce the number of access decisions that ever need later correction.

For practitioners

• Map lifecycle triggers to access outcomes Define which HRMS fields, request events, and termination signals must create immediate provisioning, recalculation, or revocation actions. Do not leave role changes or departures to ticket-based interpretation.
• Separate birthright access from exception access Encode baseline entitlements by role and keep exception access time-bound, approved, and easy to remove. This prevents one-off grants from becoming permanent entitlements.
• Audit mover controls for access accumulation Review recent promotions, transfers, and manager changes to confirm old access was removed when new access was added. Focus on applications where permission scope changes inside the app, not only at the SSO layer.
• Expand offboarding to shadow IT discovery Require offboarding workflows to enumerate apps, trials, and department-managed tools that were never centrally provisioned. A clean exit depends on finding access that never passed through procurement.

Key takeaways

• JML automation closes the gap between lifecycle events and access changes, which is where most manual IAM failures begin.
• Mover handling is the most dangerous phase because it creates silent privilege creep instead of obvious outages.
• Offboarding must cover shadow IT, data reassignment, and full revocation, or former access will outlive the employment relationship.

Key terms

• Joiner: A joiner is a new identity entering an organisation and needing access provisioned before work begins. In JML, the joiner event is the trigger for birthright access, application assignment, and initial governance checks tied to role, department, location, and employment type.
• Mover: A mover is an existing identity whose role, department, manager, or location changes and whose access must be recalculated. This is where privilege creep usually starts, because old access is often left behind while new access is added on top.
• Leaver: A leaver is an identity leaving the organisation and requiring complete access revocation, account deactivation, and data handoff. The control goal is to remove all access at the point of separation, including applications that sit outside centrally managed systems.
• Birthright Access: Birthright access is the standard baseline entitlement given to every identity in a defined role or cohort. It is pre-approved, policy-driven, and used to automate first-day access without relying on per-user request decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: The IT Admin's Guide to JML - Joiners, Movers, and Leavers Automation. Read the original.