The Complete Guide to Identity Lifecycle Management (ILM)

Every data breach has an access story behind it. An account that should have been revoked. A role change that added permissions but never removed the old ones. A service account nobody remembers creating. Identity Lifecycle Management (ILM) is the discipline that closes those gaps - and most organizations are only doing half of it.

This guide covers the full picture: what ILM is, how each phase works, where programs routinely break down, and what it takes to automate the lifecycle across every app in your stack - including the ones that don't support SCIM.

---

What Is Identity Lifecycle Management?

Identity Lifecycle Management (ILM) is the automated, centralized process of managing user identities and their access rights across enterprise resources and applications - from creation to deactivation. It is the operational engine that keeps digital access aligned with business reality: who works here, what role they hold, and whether they still need the access they have.

ILM sits inside the broader Identity Governance and Administration (IGA) framework. IGA covers the policy layer - who should have access, based on what rules, and how that's audited. ILM is the execution layer - the workflows, connectors, and automations that make those policies real across every system. You can't have effective IGA without ILM underneath it.

The lifecycle has three core phases - joiner, mover, and leaver - plus surrounding processes: access requests, periodic certification, and credential lifecycle management. Each phase has its own failure modes, and most organizations have at least one of them badly broken.

---

The Joiner Phase: Provisioning from an Authoritative Source

The joiner phase begins the moment a new hire is confirmed in your HRIS. The HRIS - Workday, BambooHR, HiBob, or equivalent - is the authoritative source: the system of record that tells your identity platform who exists, what their role is, and what department they belong to.

A well-designed joiner workflow does the following automatically:

• Reads the new hire record from the HRIS on a trigger (not a nightly batch)
• Creates the identity in the directory (Active Directory, Entra ID, Okta)
• Maps the role to a predefined birthright access set - the baseline apps and permissions every person in that role receives on day one
• Provisions accounts in every connected application, not just the SCIM-enabled ones
• Logs every action with a timestamp for audit purposes

Birthright access is the concept that certain access is automatic and role-appropriate - no ticket required. An engineer gets GitHub, Jira, and the dev Slack channels. A finance analyst gets the ERP read role and the expense tool. Birthright access reduces day-one friction and eliminates the ad-hoc provisioning that creates inconsistency.

The failure mode here is coverage. Most SSO and SCIM-based tools provision the apps they're connected to and leave the rest manual. If your stack includes Notion, Figma, Linear, or any long-tail SaaS tool without a SCIM connector, those accounts still get created via ticket - which means delays, inconsistency, and no audit trail.

---

The Mover Phase: The Hardest and Most-Neglected Phase

If joiners and leavers are the bookends, movers are the messy middle - and they're where most identity programs quietly fail.

A mover event occurs whenever an employee changes role, team, department, or manager while staying at the company. It's the most common lifecycle event by volume, and it's the primary driver of privilege creep: the gradual accumulation of access rights beyond what a person's current job requires.

Here's the mechanism: when someone moves from engineering to product management, the IGA platform (ideally) provisions their new role's access. But the old engineering permissions - GitHub repo access, dev environment credentials, CI/CD pipeline roles - often stay active. Nobody explicitly revoked them. The old manager assumed IT would handle it. IT assumed the new manager would request the change. The result is that the mover now holds the union of every role they've ever had.

Movers - employees who change roles, teams, or departments while staying at the company - create the largest privilege accumulation blind spot. Joiners start with 8-15 apps at role baseline; movers don't reset. They compound in both directions simultaneously.

Movers are the single biggest driver of privilege creep in every organization. And the risk compounds with seniority: the longer someone has been at a company, the more roles they've held, and the more access they've accumulated across systems that nobody has ever audited.

What a correct mover workflow looks like:

1. HRIS fires a role-change event (department, title, manager, or cost center change)
2. IGA platform maps the new role to its predefined access set
3. New-role permissions are provisioned
4. Old-role permissions are explicitly revoked - not assumed to be handled elsewhere
5. Any access that doesn't fit either the old or new role baseline is flagged for manager certification
6. The entire delta is logged

A well-designed mover workflow receives the role change from the HR system, maps the new role to a predefined permission set, provisions those entitlements, and revokes permissions associated with the previous role. The entire process is logged, auditable, and requires no manual intervention from the help desk.

The reason this rarely happens in practice: most IGA tools are better at adding access than removing it. Provisioning is a create operation; deprovisioning requires knowing what to remove, across every connected system, with confidence that removing it won't break something. That's harder - and it's why the mover phase is where access accumulates.

---

The Leaver Phase: Deprovisioning at Speed

The leaver phase is the most security-critical and the most time-sensitive. When an employee departs - voluntarily or not - every minute of continued access is a window of risk.

Orphan accounts are the unlocked back doors of the enterprise. They hold valid credentials, often with elevated privileges, but no active owner. Attackers know this and use them. Real-world examples include the Colonial Pipeline breach, where attackers entered via an inactive VPN account, and a 2025 manufacturing company hit by Akira ransomware through a "ghost" third-party vendor account that wasn't deactivated.

A leading identity governance report in 2026 found that 89% of enterprise CISOs now rank orphaned accounts as a top three SaaS security governance issue, on par with privilege escalation and shadow IT.

A complete leaver workflow must:

• Trigger immediately on the HRIS termination event - not on a nightly sync
• Disable the SSO/IdP account (which cuts federated access to SCIM apps)
• Also deprovision every non-SCIM app directly - because SSO session revocation doesn't reach apps with their own login
• Revoke API keys, tokens, and shared credentials the user held
• Transfer ownership of files, repos, and shared resources
• Archive the account for audit retention before deletion
• Log the full deprovisioning chain with timestamps

The gap that most tools leave: SSO-based deprovisioning only works for apps that enforce SSO. If a user has a direct login to an app - or if the app doesn't terminate active sessions on IdP disable - access persists. For a 50-app stack where 20 apps support SCIM and 30 don't, a SCIM-only offboarding tool leaves 30 doors open.

---

Surrounding Processes: Access Requests, Certification, and Credential Lifecycle

ILM isn't only joiner-mover-leaver. Three surrounding processes complete the picture:

Access requests handle the access that birthright doesn't cover - project-specific tools, elevated permissions, temporary access for contractors. A governed access request process routes requests through appropriate approvers, enforces time limits on temporary access, and logs every grant and denial.

Periodic access certification (also called access reviews or recertification) is the scheduled process of having managers or resource owners confirm that existing access is still appropriate. Regular, mandatory review of user entitlements by managers, with automated revocation if uncertified, is the mechanism that catches drift between lifecycle events - the access that accumulated through project grants, exception approvals, and mover gaps.

Credential lifecycle covers passwords, MFA factors, API keys, certificates, and tokens. Each has its own rotation schedule, expiry policy, and revocation path. Credential lifecycle is where ILM and PAM (Privileged Access Management) overlap.

---

The Non-Human Identity Lifecycle: The Blind Spot ILM Programs Miss

Service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, and AI agents are all identities. They authenticate to systems, hold permissions, and create risk when unmanaged. And none of them appear in your HRIS.

Non-human identities now outnumber human identities in most enterprises, with ratios commonly cited between 40:1 and 80:1. Traditional IGA programs were never built for that scale.

97% of NHIs carry excessive privileges, increasing unauthorized access and broadening the attack surface. Only 20% of organizations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

AI agents add a new layer of complexity. The difference between a service account and an AI agent is autonomy: a service account executes predefined instructions, while an agent interprets goals and chooses actions. That's why agents need the fuller governance treatment - ownership, scoped permissions, and lifecycle management - not just credential hygiene.

The most fundamental governance gap for non-human identities is the absence of clear ownership. A human identity is anchored to an individual whose employment status, role changes, and access needs can be tracked through HR systems. When a human employee departs, their identity can be deprovisioned through a defined offboarding workflow. Non-human identities lack this anchor. They are created by developers, automation systems, or AI agents themselves, and they frequently outlive the specific project, pipeline, or agent deployment that originally justified their existence.

The NHI lifecycle requires a parallel framework to JML:

NHI Lifecycle Stage	Human Equivalent	Key Controls
Creation	Joiner	Named owner, defined purpose, scoped permissions
Change	Mover	Re-scope on project/team change, ownership transfer
Retirement	Leaver	Revoke on project end, rotate before deletion
Rotation	(no equivalent)	Scheduled credential rotation, expiry enforcement

---

Manual vs. Automated ILM

Most organizations exist somewhere on a spectrum between fully manual and fully automated. Here's what that looks like in practice:

The business case for automation isn't just security - it's operational. A 2025 identity governance study found that manual orphaned identity cleanup averages more than 2 hours per week per environment. That burden scales poorly once you manage dozens of SaaS apps. And manual provisioning often results in "productivity lag," where new hires wait days or weeks for necessary access.

---

Key ILM Metrics

The most critical metrics include time-to-deprovision (your primary metric for risk reduction) and time-to-provision (which measures the impact on new employee productivity and time-to-value).

Track these four numbers to know whether your ILM program is actually working:

• Time-to-provision - From HRIS hire confirmation to full access. Target: same day or pre-day-one. Same-day or pre-day-one provisioning is the benchmark to aim for.
• Time-to-deprovision - From termination event to all access revoked. Anything beyond a few hours is a meaningful risk exposure. Best-in-class programs achieve full revocation in under 30 minutes through automation.
• Orphaned account rate - Percentage of active accounts belonging to users no longer with the organization. Target: as close to zero as possible, measured continuously.
• % of apps covered - What share of your app stack is governed by your ILM program (not just SCIM-connected apps). A program that covers 20 of 50 apps has a 60% blind spot.

Two additional metrics worth tracking: volume of manual access-related help desk tickets (a direct measure of automation ROI) and access review completion rate (the percentage of scheduled certifications completed on time).

---

ILM Within IGA: How They Fit Together

ILM is the operational core of IGA, but IGA is broader. Think of it this way:

• ILM answers: Does the right person have the right access right now?
• IGA answers: Is access governed by policy, auditable, and compliant?

IGA adds the policy layer (role definitions, SoD rules, risk scoring), the certification layer (periodic reviews), and the reporting layer (audit evidence, compliance dashboards). ILM provides the execution - the provisioning, deprovisioning, and change workflows that make policy real.

A mature IGA program without strong ILM underneath it produces beautiful dashboards that don't reflect reality. Strong ILM without IGA governance produces automation without accountability. You need both.

---

Where Most ILM Programs Break Down

The coverage gap is the most common failure. An ILM program that automates SCIM-connected apps and leaves the rest manual isn't a complete program - it's partial automation with a manual tail that grows as your SaaS stack grows.

For a typical 50-100 app stack at a 200-person company, fewer than half of those apps will support SCIM. The rest - the project management tools, the design platforms, the communication channels, the internal wikis - require either direct API integration or a connector that can write to the app without SCIM. If your IGA platform can't reach them, your leaver workflow has gaps, your mover workflow has gaps, and your orphaned account rate is higher than you think.

The second failure is the mover problem described above: provisioning new access without revoking old access. Permissions classified as safe and compliant dropped from 70% in 2024 to 55% in 2025, with ungoverned permissions rising from 5% to 28% of the total. That's not a joiner or leaver problem - it's a mover problem accumulating over time.

Iden is built to close both gaps. Universal connector technology reaches every app in your stack - SCIM, API, or neither - so joiner, mover, and leaver workflows execute completely, not partially. Fine-grained write-back goes deeper than group membership: channel-level, repo-level, project-level permissions are provisioned and revoked with the same automation. And the same lifecycle framework extends to non-human identities - service accounts, tokens, and AI agents that never appear in your HRIS.

See how Iden automates the full lifecycle across your entire app stack - including the non-SCIM long tail:

---

ILM Maturity Checklist

Use this checklist to assess where your program stands today. A mature ILM program checks every box.

Joiner

• HRIS is the single authoritative source for all identity events
• Provisioning triggers automatically on HRIS hire event (not manual notification)
• Birthright access is defined by role, not by individual request
• All apps in the stack - including non-SCIM - are covered by the joiner workflow
• Pre-day-one provisioning is achievable for standard roles

Mover

• HRIS role-change events (department, title, manager) trigger mover workflows automatically
• New-role access is provisioned AND old-role access is explicitly revoked in the same workflow
• Access that doesn't fit either role baseline is flagged for certification
• Mover workflows cover all apps, not just SCIM-connected ones
• Periodic access reviews catch drift between mover events

Leaver

• Termination event triggers deprovisioning immediately (not on nightly batch)
• SSO/IdP account is disabled within minutes of termination
• Non-SCIM apps are deprovisioned directly, not assumed to be covered by SSO
• API keys, tokens, and shared credentials are revoked
• Full deprovisioning chain is logged with timestamps
• Target time-to-deprovision is under 1 hour

Non-Human Identities

• All service accounts have a named human owner
• API keys and tokens have defined expiry and rotation schedules
• AI agent identities are inventoried and governed separately from service accounts
• NHI lifecycle events (creation, change, retirement) are tracked in the IGA platform
• Orphaned NHIs are detected and remediated continuously

Metrics and Governance

• Time-to-provision is measured and tracked
• Time-to-deprovision is measured and tracked
• Orphaned account rate is measured continuously (not just at audit time)
• % of apps covered by automated ILM is known and improving
• Access review completion rate is tracked and above 90%
• Manual access tickets are trending down quarter over quarter

---

For a deeper look at the joiner-mover-leaver framework, see our Complete Guide to Joiner-Mover-Leaver. If you're focused on the leaver phase specifically, the IT Employee Offboarding Checklist gives you a step-by-step template for same-day deprovisioning across every app in your stack.