Why it matters
JML is where identity policy meets day-to-day operations. Joiners need productive access quickly. Movers need entitlements that match their new role, not a pile of leftover privileges. Leavers need every account closed so access does not outlive employment.
When JML works only for SCIM-connected apps, the organization has two realities. Connected apps stay current. Disconnected apps lag by hours or days, or they never get updated. That lag creates orphaned accounts, privilege drift, and audit findings. It also creates ticket queues that burn analyst time that should go to higher-value work.
Regulated industries feel this most sharply. Banking, insurance, healthcare, and manufacturing often run critical systems that do not support modern provisioning standards. JML policy exists in the IGA. Execution in those apps still depends on people.
Example
An analyst moves from retail banking operations into fraud review. The IGA updates group membership for the apps that support SCIM. For the case-management console with no API, someone opens a ticket. Two weeks later the analyst still has the old operations role and the new fraud role. That incomplete mover event is a classic JML failure at the last mile.
How it is typically handled (and where it breaks)
Organizations usually encode JML in an IGA platform such as SailPoint or Saviynt, with the IdP handling authentication. Connected apps receive create, update, and disable events automatically. Everything else becomes a work instruction: tickets, shared inboxes, and admin console checklists.
The break is predictable. Tickets get skipped. UI steps vary by operator. Evidence is a screenshot or a closed ticket, not a verified application state. Certification campaigns then review incomplete data.
How Redblock handles it
Redblock executes approved JML changes inside applications that lack SCIM or reliable APIs. When the IGA or IdP issues a joiner, mover, or leaver action, Redblock agents perform the change in the target app, confirm the account or entitlement state, and return structured evidence.
That keeps the IGA as the system of record while closing the execution gap for disconnected and legacy apps. Learn more on the identity governance page and the identity access administration page.
JML also sits at the center of how identity teams are measured. Time to provision a joiner, completeness of mover updates, and time to revoke a leaver are the KPIs that show whether the stack is working. When those KPIs only include connected apps, leadership sees a healthier picture than the portfolio warrants.
Another pressure is contractor and vendor access. Temporary workers follow shorter, messier lifecycles. If JML playbooks assume a clean HR event and a SCIM endpoint, those identities fall through first.
Mature programs add compensating controls such as privileged access management and more frequent reviews. Those controls help, but they do not replace reliable create, update, and disable execution in every application that holds data.
Related terms
- Deprovisioning
- Disconnected Applications
- Last-Mile Provisioning
- Identity Governance and Administration (IGA)
- Orphaned Accounts
Frequently Asked Questions
What does JML stand for?
JML stands for joiner, mover, and leaver. It covers onboarding access, role-change updates, and offboarding revocation across applications.
Why does JML fail in disconnected apps?
Without SCIM or usable APIs, the IGA cannot push account changes into the application. Teams fall back to tickets and manual admin work, which is slow and hard to verify.
Does Redblock decide who should get access?
No. Approvals and policy stay in your IGA or IdP. Redblock executes changes that have already been approved and verifies the outcome.