Joiner, mover, and leaver events are the identity lifecycle changes that happen when a person or system account is created, changed, or removed. In IAM, these events trigger onboarding, access updates, and deprovisioning so permissions stay aligned with job role, risk, and current need.
What Joiner, Mover, and Leaver Events Mean in IAM
Joiner, mover, and leaver events are the operational signals that tell an identity system a person or account has entered, changed, or exited the organisation. They are the lifecycle checkpoints that keep access aligned to role, employment status, and business need.
These events are important because access usually drifts unless someone or something actively updates it. A joiner event should create the right baseline access, a mover event should change entitlements when duties shift, and a leaver event should remove access that is no longer justified.
Why JML Events Matter for Access Governance
JML events sit at the center of identity governance because they connect HR, managers, IT, and security to a common access decision. When they work well, they reduce standing access, stale accounts, and permissions that no longer match the person’s current responsibilities.
They also help distinguish between access that is temporary and access that should persist. Without that distinction, organisations often accumulate privilege creep, duplicate accounts, and exceptions that are difficult to unwind later.
For a practical model of how onboarding, role change, and exit handling fit together, see the Joiner-Mover-Leaver (JML) Guide.
What Changes During Joiner, Mover, and Leaver Processing
A joiner event typically involves account creation, initial role assignment, and delivery of baseline access that matches the new user’s job or the new system’s purpose. A mover event is about re-evaluating what should stay, what should be added, and what must be removed as responsibilities change.
A leaver event is the most sensitive phase because it should remove access from applications, shared systems, tokens, keys, and any dependent pathways that could survive account closure. If the lifecycle only disables a primary account but leaves related credentials active, the identity is not truly offboarded.
For non-human accounts as well as people, lifecycle management becomes a control over ownership, inventory, and eventual decommissioning. That is why lifecycle handling is not just an HR workflow, but an access-control workflow.
How Organisations Operationalise JML
Most organisations operationalise JML by linking an authoritative source of truth to access workflows, then using those events to trigger provisioning, modification, and deprovisioning. Automation is helpful, but only when the underlying role data, ownership data, and termination data are reliable.
JML also works best when it is tied to access review and exception handling. If a mover event creates a new access pattern, the old access should be explicitly reviewed rather than assumed to fall away on its own.
When the organisation manages service accounts, APIs, or automation identities alongside people, the same lifecycle discipline should apply to secrets, tokens, and other identity-bearing material. That keeps lifecycle controls consistent across both human and non-human access paths.
A broader lifecycle perspective on provisioning, rotation, offboarding, and visibility is covered in the NHI Lifecycle Management Guide, which is useful where machine and application access must follow the same governance pattern.
Risk and Threat Considerations
JML failures create some of the most common access-control weaknesses in IAM. The risk is not just that someone keeps access longer than intended, but that stale accounts, leftover tokens, or unrevoked credentials become an easy path for misuse, lateral movement, or unauthorised persistence.
Failure mechanism: The lifecycle event is delayed, incomplete, or disconnected from the systems that actually hold access, so entitlements survive after the role change or exit.
Impact: Excess privilege, orphaned access, and retained credentials can let former users or compromised accounts continue to act inside the environment after the business believes access has been removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JML events govern issuance, change, rotation, and revocation of authenticators and related access material. |
| AC-2 — Account Management | JML is the operational mechanism for creating, modifying, disabling, and removing accounts across their lifecycle. | |
| AC-6 — Least Privilege | Mover events should reduce or reshape access so users keep only what current duties require. | |
| Recommendation — Tie joiner, mover, and leaver workflows to IA-5 so credentials and authenticators are updated or revoked on lifecycle change. Use AC-2 to ensure accounts are provisioned, modified, disabled, and removed through defined lifecycle events. Apply AC-6 to remove obsolete access after role changes and keep privileges aligned to current need. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | JML is a core IAM lifecycle process for provisioning, change control, and deprovisioning. |
| Recommendation — Map joiner, mover, and leaver workflows into IAM lifecycle controls for consistent entitlement handling. | ||
Related resources from NHI Mgmt Group
- Why do mover events create more risk than joiner or leaver events?
- What breaks when identity platforms handle joiner and leaver events well but mover events poorly?
- How should organisations govern physical badge access across joiner-mover-leaver events?
- Should organisations tie access reviews to joiner-mover-leaver events?