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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | JML 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 5 | AC-2 — Account Management | JML directly governs account creation, modification, and disabling across the lifecycle. |
| IA-5 — Authenticator Management | JML 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:2022 | A.5.18 — Access rights | JML 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 v8 | CIS-5 — Account Management | JML 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.