Identity Lifecycle Management: Joiner, Mover, Leaver Guide

Short answer: Identity lifecycle management (ILM) is the process of creating, changing and removing a person's accounts and access as they join, move within and leave an organization. A good setup makes the HR system the source of truth, provisions apps over SCIM, removes old access when roles change, and disables every account on the leaver's last day, with an audit trail for each step.

Who this guide is for

This guide is for an IT admin, identity engineer or MSP who has been asked to stop handling onboarding and offboarding by ticket and spreadsheet. It fits a 300-person company on Microsoft 365 that wants HR-driven accounts, a 1,500-person firm with Workday and dozens of SaaS apps that fails access audits, and an MSP standardizing leaver checklists across client tenants.

It covers how joiner, mover and leaver (JML) automation works, what to require from a tool, and how to test it. It does not rank products; for the vendor field, see the identity and access management category hub.

What is identity lifecycle management?

Identity lifecycle management is the set of processes and tools that create a user's digital identity, keep its access correct as the person's role changes, and remove access when the person leaves. Most vendors and the federal ILM playbook describe the same three phases, usually named joiner, mover and leaver.

Microsoft describes the same model in its Entra documentation: joiners enter the scope of needing access, movers cross boundaries within the organization, and leavers leave that scope (Microsoft Learn, accessed September 22, 2026). The federal playbook adds a Master User Record that aggregates attributes, entitlements and authenticators for each person (idmanagement.gov, accessed September 22, 2026).

If you map purchases to a framework, identity lifecycle work falls under CIS Critical Security Control 5, Account Management, which covers assigning and managing authorization to credentials for user, administrator and service accounts (CIS, accessed September 22, 2026).

Requirements that separate identity lifecycle management tools

Identity lifecycle management tools differ less on whether they "do provisioning" and more on where they read identity data from, how many apps they can reach, and what they do on a mover or leaver event. The table sets out the requirements that decide most evaluations.

The mover row is the one to press vendors on. Microsoft's own Lifecycle Workflows task list includes mover tasks such as notifying the manager, requesting access packages and removing the user from selected groups, but which groups to remove is still something you configure (Microsoft Learn task reference, accessed September 22, 2026). Expect the same pattern elsewhere: the tool runs the rule, you still have to define the role.

Watch out: Microsoft Entra's provisioning service cannot read or provision users in nested groups; it only acts on immediate members of an assigned group (Microsoft Learn, accessed September 22, 2026). A nested group design can silently leave people out of provisioning.

How SCIM provisioning and deprovisioning work

SCIM (System for Cross-domain Identity Management) is the standard REST API most identity lifecycle management tools use to create, update and disable users in SaaS apps. The identity platform calls the app's SCIM endpoint; the app has to implement it. Microsoft describes SCIM as becoming the de facto standard for provisioning, used alongside SAML or OpenID Connect for sign-in (Microsoft Learn, accessed September 22, 2026).

Microsoft's documentation of the Entra provisioning service shows the details worth checking with any vendor:

• Cycles, not instant pushes: the service runs an initial cycle, then repeated incremental cycles at intervals set per app. A leaver's app access ends at the next cycle, not the moment HR saves the record.
• Disable by default: when a user goes out of scope or is soft-deleted, the service disables the user in the app (for SCIM apps, active = false). A delete request follows only on a hard delete, which in Entra ID happens 30 days after the soft delete.
• Failures stall quietly: if most calls to an app fail, the job goes into quarantine, cycles slow to once per day, and after four weeks in quarantine the job is disabled.
• Nothing for disabled users: provisioning a user who is disabled in Entra ID is not supported.

All four points come from How provisioning works on Microsoft Learn, accessed September 22, 2026. For a leaver, the practical meaning is simple: disable sign-in and revoke sessions at the identity provider first, then let provisioning clean up the apps, and alert on quarantined jobs.

Admin tip: Entra Lifecycle Workflows includes a built-in "Revoke all refresh tokens for user" task for leavers and movers (Microsoft Learn task reference, accessed September 22, 2026). Put it in the same workflow that disables the account.

Deployment models

Identity lifecycle management comes in three shapes, and the choice is mostly about where your identities and target apps live.

• Built into your identity provider: Microsoft Entra ID Governance and Okta Lifecycle Management add provisioning and workflows to the directory you already run. Okta says its product uses HR systems such as Workday, BambooHR and SuccessFactors as sources of truth, provisions apps over SCIM and adds no-code customization through Okta Workflows (Okta Lifecycle Management page, accessed September 22, 2026). This fits most mid-market teams with mainly SaaS apps.
• Dedicated identity governance (IGA) platforms: products such as SailPoint Identity Security Cloud and Saviynt add role modeling, access certifications and separation-of-duties checks on top of provisioning. They fit large enterprises with many on-prem and custom apps and heavy audit demands.
• Self-hosted or scripted: open-source identity servers and in-house scripts give full control, but your team owns every connector, retry and log. This fits only teams with the engineering time to maintain it.

Hybrid environments usually need an agent on-prem. Microsoft, for example, provisions into LDAP, SQL, REST, SOAP and PowerShell targets through an on-premises provisioning agent (Microsoft Learn, accessed September 22, 2026).

Pricing models and hidden costs

Identity lifecycle management is usually priced per user per month, and the common trap is that lifecycle automation is a separate SKU on top of the directory license. Microsoft's published prices show the pattern.

Microsoft Entra list prices, checked September 22, 2026 (per user per month, paid yearly):

Sources: Microsoft Entra pricing and What are lifecycle workflows?, both accessed September 22, 2026.

Pricing note: on those list prices, a team on Entra ID P1 that adds ID Governance pays $14.00 per user per month for scheduled JML workflows (Microsoft pricing page, checked September 22, 2026). Okta does not publish a Lifecycle Management price on its product page; it routes buyers to sales or a trial.

Other costs to budget for:

• Seat scope: check whether you pay for every identity or only governed users, and whether contractors and guests count.
• Connector gaps: apps with no SCIM support may need a higher SaaS tier to get SCIM at all, a custom connector, or a manual process.
• Implementation: HR attribute cleanup and role design are usually the largest effort, and vendors rarely include them.
• Service limits: Microsoft documents up to 100 custom task extensions per tenant for Lifecycle Workflows, but states the workflow limit two ways: 100 workflows on What are lifecycle workflows? and 50 on its licensing fundamentals page (both accessed September 22, 2026). Confirm the current limit with Microsoft if you plan many workflows.

How to evaluate identity lifecycle management, step by step

1. Inventory identities and apps. List employee, contractor and guest populations, and every app with its provisioning method (SCIM, JIT, manual). Output: an app list marked by connector type. Owner: IT.
2. Fix the HR data. Confirm hire date, termination date, department, manager and employee type exist and are reliable. Output: an attribute map. Owner: HR with IT.
3. Define birthright access. Decide what every joiner gets by department and role. Output: a role-to-group table. Owner: IT with department heads.
4. Write mover and leaver rules. Specify what is removed on a role change and the order of leaver steps (disable, revoke sessions, remove licenses, transfer data). Output: a written JML policy. Owner: security.
5. Shortlist two or three tools against the requirements table. Output: a scored list. Owner: IT.
6. Run the trial below on a test tenant with test HR records. Output: pass or fail per test. Owner: IT.
7. Pilot with one department, then expand. Output: provisioning logs reviewed each week during the pilot. Owner: IT.
8. Add access reviews for access granted outside birthright rules. Output: a review schedule. Owner: security.

Run a trial that proves something

Questions to ask vendors

Data sources and connectors

• Which HR systems do you connect to natively, and is the connector included in the quoted SKU?
• How many of our listed apps have a supported provisioning connector, and which use SCIM versus other methods?
• How do you provision into Active Directory, LDAP and databases, and what agent is required?

Lifecycle behavior

• On a leaver event, do you disable or delete in each app, and can we choose per app?
• How often do provisioning cycles run, and can a termination be pushed immediately?
• How do mover rules remove the previous role's access?
• How do you handle rehires and name changes without duplicate accounts?

Security and audit

• What is logged for each provisioning action, and how long are logs retained?
• How are failed jobs surfaced, and what happens to a connector that keeps failing?
• Which admin roles can edit workflows, and are workflow changes logged?

Pricing, contract and exit

• Which SKU includes lifecycle workflows, and does it require a base directory license?
• Which identities count as billable seats?
• Can we export workflows, rules and logs if we leave?

Mistakes to avoid

• Treating deprovisioning as instant. Provisioning runs in cycles, so block sign-in and revoke sessions at the identity provider first (Microsoft Learn).
• Using nested groups for app assignment in Entra ID, where the provisioning service skips members of nested groups (same source).
• Automating joiners and ignoring movers, so access piles up with every role change.
• Forgetting apps without connectors. Each needs a tracked manual step, or the leaver keeps that account.
• Ignoring quarantined jobs. A quarantined Entra provisioning job drops to one cycle per day and is disabled after four weeks (same source).
• Buying before checking the SKU. Lifecycle Workflows needs Entra ID Governance or Entra Suite, not P1 alone (Microsoft Learn).

Shortlist by scenario

To score options against your own requirements, use the shortlist builder. The same SCIM deprovisioning test applies to other tools you connect, as in the business password manager buying guide.

Bottom line

Start with the HR data and the leaver rule, not the tool: if the termination date is unreliable, no product will disable accounts on time. Then pick the lifecycle features of the identity provider you already run, unless audits or on-prem apps push you to an IGA platform. The deciding question in most deals is which SKU includes scheduled workflows, so get it named in the quote.

Next step: compare the vendors in the identity and access management category hub.