Join our Newsletter — 33% off our NHI Course
Home› Glossary› NHI Lifecycle Management› Joiner-Mover-Leaver Engine
NHI Lifecycle Management

Joiner-Mover-Leaver Engine

← Back to Glossary
By NHI Mgmt Group Updated October 7, 2026 Domain: NHI Lifecycle Management

The part of an identity governance programme that provisions, modifies, and removes access as people change roles or exit the organisation. For disconnected applications, the JML engine can decide correctly but still fail operationally if the execution path is manual or unverified.

What the Joiner-Mover-Leaver Engine Actually Does

A joiner-mover-leaver engine is the workflow and decision layer inside identity governance that turns HR or source-system events into access changes. It is responsible for first-time provisioning, role-change updates, and final removal of access when someone leaves.

Its value is not just speed. A good JML engine keeps access aligned to a current job role, which helps prevent privilege creep, stale entitlements, and orphaned accounts from accumulating across the identity lifecycle.

How JML Connects People, Roles, and Entitlements

JML sits between an authoritative source of workforce change and the applications that enforce access. When it is working well, it maps a joiner to baseline access, a mover to the right revised entitlements, and a leaver to deprovisioning actions that close access paths cleanly.

That mapping is usually policy-driven, not manually improvised. In practice, the engine may apply role rules, approval logic, and entitlement templates, then push the result into target systems through connectors or provisioning APIs.

NHIMG’s Joiner-Mover-Leaver (JML) Guide explains how automation reduces access creep by revoking old-role access and closing down credentials, tokens, keys, and related access paths when people move or exit.

Where JML Fails in the Real World

The engine can make the right decision and still fail operationally. That happens when downstream applications are disconnected, when deprovisioning steps are manual, or when target systems are not reliably verified after the change is sent.

In those cases, the identity governance layer believes the access state is correct, but the actual application estate may still retain old privileges. The practical gap is not the policy logic, it is the execution path.

That is why JML should be understood as both a governance function and an integration function. A complete lifecycle design has to account for ownership, connectors, timing, reconciliation, and exception handling.

Why JML Matters for Security and Governance

JML is one of the most important control points in identity governance because it reduces the window in which unnecessary access can persist. It also gives the organisation a repeatable way to answer who should have access, when that access should change, and when it should be removed entirely.

It becomes especially important in environments with many apps, many approvers, and high turnover. If movers keep old access or leavers stay active, the result is excess privilege, audit exposure, and a larger attack surface for account misuse.

NHIMG’s IAM and IGA Basics places JML in the broader identity governance model, including provisioning, access reviews, entitlements, and least-privilege controls. For secure onboarding and offboarding workflows, see the SCIM and Automated Provisioning Guide, which covers automated provisioning and deprovisioning patterns and common integration failure modes.

Risk and Threat Considerations

JML risk is less about the policy decision and more about whether the decision is fully executed everywhere it needs to be. If deprovisioning is delayed, partial, or unverified, access can survive in SaaS apps, internal tools, shared credentials, or disconnected platforms long after the business event has occurred.

Failure mechanism: A role change or termination event updates the identity record, but downstream systems do not reliably remove the old entitlements, so former access remains active and exploitable.

Impact: Excess privilege, orphaned access, and delayed offboarding increase the likelihood of misuse, unauthorized data access, audit findings, and post-exit account abuse.

Standards & Framework Alignment

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

CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
CSA Cloud Controls MatrixIAM — Identity and Access ManagementJML is an IAM lifecycle control for provisioning and deprovisioning access.
Recommendation — Automate joiner, mover, and leaver access changes under IAM controls.
NIST SP 800-53 Rev 5AC-2 — Account ManagementJML directly governs account creation, modification, and disabling across the lifecycle.
IA-5 — Authenticator ManagementJML often must revoke or rotate authenticators and access material at offboarding.
Recommendation — Use AC-2 to manage account provisioning, changes, and timely removal. Use IA-5 to revoke or rotate authenticators when access ends.
ISO/IEC 27001:2022A.5.18 — Access rightsJML operationalises granting, modifying, and removing access rights over time.
Recommendation — Apply A.5.18 to review and remove access rights on role change or exit.
CIS Controls v8CIS-5 — Account ManagementJML is the operational pattern for managing accounts through joiner, mover, and leaver events.
Recommendation — Implement account lifecycle controls to add, modify, and remove access promptly.

Practitioner Guidance

What to watch for: Treat JML as a reconciliation problem, not only a workflow problem. The most important operational question is whether every access change is confirmed in the target system, especially where the application is disconnected, manually administered, or slow to respond.

Governance implication: Ownership should be clear for the authoritative source, the policy logic, and each downstream application. If any of those three are ambiguous, the lifecycle process tends to fail at the exception boundary rather than in the core workflow.

Practitioner takeaway: The strongest JML programmes do not just issue access changes, they prove that the changes actually landed.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org