What is Identity Lifecycle Management?

Definition

Identity Lifecycle Management (ILM) is the end-to-end process of creating, maintaining, modifying, and removing digital identities and their associated access rights across the systems an organization uses.

It covers every identity:

• Employees
• Contractors and partners
• Customers (in CIAM)
• Service accounts
• Workloads and applications
• OAuth applications
• AI agents and bots

ILM is sometimes called Joiner-Mover-Leaver (JML) when discussing the workforce lifecycle, but the principles apply to non-human identities too.

---

Why ILM Matters

Identities that aren't properly managed across their lifecycle become security liabilities:

• Former employees keep access months after leaving.
• Contractors retain access well past project end.
• Service accounts outlive the projects that created them.
• Role changes leave behind stale entitlements (privilege creep).
• OAuth apps remain authorized after vendors are dropped.
• AI agents accumulate scopes long after their initial scope ends.

The 2024 Verizon DBIR continues to find stolen credentials and stale access among the leading initial access vectors. NIST SP 800-53 (AC-2) explicitly calls for managing accounts through their full lifecycle.

Strong ILM directly reduces:

• Insider risk
• Compliance findings
• Attack surface
• Operational confusion ("who owns this account?")

---

The Three Phases: Joiner, Mover, Leaver

Joiner

Creating an identity and granting baseline access when a person joins or a workload is provisioned.

Triggers:

• New hire in HR system
• New contractor in vendor management
• New workload deployed
• New service account requested

Goals:

• Provision baseline access on day one.
• No "hold on, I'll grant this later" gaps.
• No accidental over-provisioning ("give them everyone's access just in case").

Mover

Updating access when a role, team, project, or workload purpose changes.

Triggers:

• Promotion or transfer
• Project change
• Manager change
• Re-architecture

Goals:

• Add new access required by the new role.
• Remove access no longer needed (this is the part most processes get wrong).
• Re-evaluate sensitive entitlements.

Leaver

Disabling and eventually removing identities and access when no longer needed.

Triggers:

• Termination, resignation, retirement
• Contract end
• Workload decommissioning
• AI agent retirement

Goals:

• Disable access immediately on the effective date.
• Revoke active sessions and tokens.
• Reassign or rotate owned credentials and secrets.
• Archive evidence and audit data.
• Delete after a defined retention period.

---

ILM Components

1. Authoritative Sources of Truth

For employees: HR systems (Workday, SuccessFactors, BambooHR). For contractors: vendor management or IGA tools. For workloads: cloud control plane, IaC, ticketing. For OAuth apps: IdP enterprise app catalog.

ILM only works if there is a clear, trusted source for "this identity exists / has changed / is gone."

2. Provisioning Engine

Pushes accounts into target systems based on rules: SCIM, custom connectors, IGA workflows.

3. Deprovisioning Engine

Removes or disables accounts in target systems on the leaver event. Should also revoke sessions and tokens.

4. Access Request and Approval

For access beyond baseline — request workflows with manager and resource-owner approvals.

5. Access Reviews / Certification

Periodic confirmation that current access still matches current need.

6. Audit and Reporting

Evidence for compliance: who got what access, when, and why; who removed it, when, and why.

---

ILM in Practice

Example 1: Joiner Workflow

A new employee starts:

1. HR creates the record with title, department, manager, and start date.
2. The IGA tool reads HR daily and triggers provisioning on day one.
3. Identity is created in Microsoft Entra ID.
4. Baseline groups are assigned (e.g., All-Employees, Marketing-Baseline).
5. SaaS apps are provisioned via SCIM.
6. Hardware is shipped with a temporary password and required passkey enrollment.
7. The manager approves any non-baseline access requests.

Day-one productivity, no over-provisioning.

Example 2: Mover Workflow

A developer transfers from Backend to Security Engineering:

1. HR updates the role.
2. The IGA tool detects the change.
3. Old groups (Backend-Devs, Backend-Repos) are removed.
4. New groups (Security-Engineers, SOC-Read-Only) are added.
5. The new manager certifies the resulting access.
6. An audit record captures every change.

Without this, the developer would carry both old and new entitlements — privilege creep.

Example 3: Leaver Workflow

An employee resigns:

1. HR sets the termination date.
2. At end of day on the last day, the IGA tool:
   • Disables the IdP account.
   • Revokes active sessions and refresh tokens.
   • Removes group memberships.
   • Deactivates SaaS accounts.
   • Reassigns owned files and shared mailboxes.
3. After 30 days, the account is deleted.
4. Owned service accounts and API keys are reassigned or rotated.

Example 4: Contractor with Time-Bound Access

A consultant has a 60-day engagement:

1. The vendor management system records start and end dates.
2. The identity is provisioned with auto-expiry.
3. Access is reviewed mid-engagement.
4. On day 60, the account is automatically disabled.

Time-bound access prevents "forever contractors."

Example 5: Service Account Lifecycle

A new microservice needs database credentials:

1. The team requests a service account through ITSM.
2. The IGA / PAM tool provisions it with documented owner and purpose.
3. Credentials are vaulted and rotated.
4. The account is reviewed annually.
5. When the service is decommissioned, the account is disabled and credentials rotated.

Example 6: AI Agent Lifecycle

An AI agent is launched to assist support staff:

1. The agent identity is registered with a unique ID and owner.
2. Tool/action scopes and delegation rules are defined.
3. Scopes are reviewed quarterly.
4. When the agent is deprecated, its identity, tokens, and tool registrations are revoked.

---

Common ILM Pitfalls

Mover events ignored

Joiner and leaver get attention; mover is often manual and inconsistent. Result: privilege creep.

Slow leaver process

Days or weeks between termination and deprovisioning create a serious risk window.

"Disabled" but not really

Account disabled in IdP but still active in some SaaS app or cloud account because integration is missing.

Sessions not revoked

Disabling the account doesn't revoke active OAuth tokens or refresh tokens. Attackers can keep using valid sessions.

Service accounts forgotten

ILM focuses on humans; service accounts are created manually, never reviewed, and outlive everything.

OAuth apps and integrations

Third-party OAuth apps installed years ago still hold tenant-wide access.

Dependencies on personal accounts

Critical scripts use personal credentials. When the person leaves, things break — leading to "let's not disable yet" decisions.

No reassignment of ownership

When a service account or shared mailbox owner leaves, the asset becomes orphaned.

---

Best Practices

1. HR-driven automation for joiner, mover, and leaver events.
2. Same-day deprovisioning for terminations.
3. Token and session revocation as part of deprovisioning.
4. Time-bound access for contractors and project-based roles.
5. Automated re-evaluation on mover events — remove old, grant new.
6. Lifecycle for non-human identities, with documented owners.
7. Periodic access reviews for sensitive entitlements.
8. Orphan and dormant identity detection.
9. Reassignment workflow for owned assets when someone leaves.
10. Integration with PAM and IGA for end-to-end coverage.
11. Audit trail for every lifecycle event.
12. Test deprovisioning regularly — pick a sample and verify access really ended.

---

ILM Use Cases

Use Case	Why ILM Matters
New hire productivity	Day-one access without delay
Termination response	Immediate access revocation
Mergers & acquisitions	Bulk on/off-boarding at scale
Contractor management	Time-bound access
Compliance	Evidence of access lifecycle
Insider risk reduction	Less stale access to abuse
Cloud and SaaS sprawl	Consistent provisioning across tools
NHI governance	Ownership and decommissioning

---

ILM Checklist

• Is there a single source of truth for each identity type?
• Is provisioning automated for baseline access?
• Are mover events fully processed (removals, not just additions)?
• Is deprovisioning same-day for terminations?
• Are sessions and tokens revoked on deprovisioning?
• Are contractor and project roles time-bound?
• Are service accounts inventoried, owned, and reviewed?
• Are OAuth apps inventoried and re-consented periodically?
• Are orphaned and dormant identities detected and remediated?
• Are AI agent identities included in the lifecycle program?
• Is access reviewed at least annually (quarterly for sensitive)?
• Is every lifecycle event auditable?

---

How Forestall Helps

Even mature ILM programs leave gaps — orphaned service accounts, stale OAuth grants, AI agents nobody owns, dormant admin accounts. Forestall continuously detects these:

• Orphaned and dormant identities.
• Service accounts and AI agents without clear owners.
• Identities still active despite role changes or terminations.
• Privileged group memberships that survived a mover event.
• Ownership chains that need reassignment.

Used alongside an IGA or HR-driven ILM, Forestall closes the gap between "the process says they're gone" and "they're really gone."

---

Frequently Asked Questions

Is ILM the same as IGA?

ILM is a core part of IGA (Identity Governance and Administration), but IGA also covers access reviews, role management, SoD, and policy.

What's the most common ILM gap?

Mover events. Leaver and joiner usually get attention; mover is where privilege creep silently grows.

How quickly should access be removed at termination?

Ideally same-day. NIST SP 800-53 (AC-2) recommends timely revocation; many regulations require it.

Do AI agents need lifecycle management?

Yes — they need identities, owners, scopes, reviews, and decommissioning, just like service accounts.

How often should access be reviewed?

Sensitive and privileged: at least quarterly. Standard: at least annually. Continuous monitoring is increasingly the norm.

---

Conclusion

Identity Lifecycle Management is the unglamorous backbone of identity security. When it works, identities exist exactly as long as they should, with exactly the access they need, and disappear cleanly when they're done. When it fails, the organization slowly accumulates ghost users, stale entitlements, orphaned service accounts, and forgotten OAuth apps — each of them a potential foothold.

A strong ILM program treats every identity — human or non-human — as something with a beginning, middle, and end, and automates the boring, error-prone work of keeping that lifecycle accurate.