Identity Lifecycle Management Explained

The most dangerous accounts in your organization aren’t the ones that are actively managed. They’re the ones that were forgotten. The contractor who finished six months ago but still has VPN access. The service account for a decommissioned application that still has database permissions. The former employee whose Azure AD account was disabled but whose local accounts on eight servers were never touched. These orphaned identities are gifts to attackers — valid credentials with no legitimate owner watching for abuse.

Identity lifecycle management is the discipline of ensuring that every identity in your environment is created with appropriate access, modified when responsibilities change, and terminated completely when no longer needed. It sounds obvious. It almost never happens cleanly.

The TLDR

The identity lifecycle covers three phases: joiner (provisioning — granting access when someone starts), mover (modification — adjusting access when someone changes roles), and leaver (deprovisioning — revoking access when someone departs). Most organizations handle joiners reasonably well, handle movers poorly, and handle leavers inconsistently. The result is orphaned accounts, accumulated permissions, and separation of duties violations. SCIM (System for Cross-domain Identity Management) automates provisioning and deprovisioning across cloud services. Identity Governance and Administration (IGA) platforms manage access reviews, role mining, and compliance reporting. NIST SP 800-53 AC-2 (Account Management) requires organizations to manage the complete lifecycle of information system accounts. Access reviews — periodic audits of who has access to what — are the safety net that catches everything the automated processes miss.

The Reality

Here’s a number that should keep you up at night: most large organizations have a significant percentage of accounts that are orphaned — belonging to people who no longer work there, attached to projects that no longer exist, or running services that were decommissioned years ago. These aren’t edge cases. They’re the norm.

The joiner process usually works because it has to. Someone is hired, they need access to do their job, there’s urgency. A ticket gets opened, accounts get created, permissions get assigned. It might be manual and slow, but it happens.

The mover process is where things start breaking. When someone transfers from Engineering to Sales, they need new access — CRM, sales tools, customer databases. That gets provisioned. But their old access — source code repos, CI/CD pipelines, staging environments — almost never gets revoked. The reasoning is always some variation of “they might need it during the transition” or “we’ll clean it up later.” Later never comes. Over time, people accumulate permissions from every role they’ve ever held. This is permission creep, and it creates accounts that violate the principle of least privilege in ways nobody intended.

The leaver process is where the wheels come off entirely. HR knows someone left. IT disables the Active Directory account. But what about the local accounts on Linux servers? The API keys in third-party services? The shared credentials they had access to? The SSH keys deployed to production boxes? The OAuth tokens granted to their personal devices? Unless every system is federated through the IdP (and they never all are), deprovisioning is a manual checklist that’s incomplete by definition.

The SolarWinds breach used a compromised service account for lateral movement. The 2021 Colonial Pipeline attack involved a compromised VPN account that belonged to a user who was no longer active at the company — an orphaned account with no MFA. These aren’t exotic attack techniques. They’re the predictable consequence of incomplete lifecycle management.

How It Works

Joiner — Provisioning Done Right

Provisioning should be automated, role-based, and policy-driven. When HR records a new hire in the HRIS (Human Resource Information System), that event should trigger automatic account creation with permissions derived from the person’s role, department, and location.

Birthright access is the baseline set of permissions everyone in a given role needs on day one: email, intranet, department file shares, standard applications. This should be templated and automated so that a new hire is productive immediately without manual intervention.

Request-based access covers everything beyond the baseline — access to specific systems, elevated permissions, project-specific resources. This requires a request, an approval workflow, and documentation.

The provisioning workflow should create accounts in the IdP (which cascades to federated applications), assign RBAC roles, and document everything in an access register. SCIM 2.0 (System for Cross-domain Identity Management) is the protocol that automates this for cloud services — when a user is created in your IdP, SCIM pushes that identity to every connected SaaS application (Slack, Salesforce, GitHub, AWS) automatically.

Mover — The Forgotten Phase

When someone changes roles, two things need to happen simultaneously:

Grant new access appropriate to their new role.
Revoke old access that’s no longer appropriate.

In practice, organizations reliably do step 1 and almost never do step 2. The standard process is: submit a ticket for new access, get it provisioned, start the new role. Nobody submits a ticket to revoke old access because nobody wants to risk losing access they might need. The manager approving the new access doesn’t know what old access exists. The system doesn’t flag the conflict.

This is where role mining becomes valuable. Identity governance platforms can analyze actual access patterns and compare them to role definitions, flagging accounts that have permissions inconsistent with their current role. If someone in the Finance department still has access to the engineering CI/CD pipeline, that’s a candidate for removal.

Separation of Duties (SoD) enforcement is critical during moves. A person transferring from the team that approves purchase orders to the team that processes payments creates a conflict — they could now approve and process their own transactions. SoD rules should automatically detect and prevent these conflicts. NIST SP 800-53 AC-5 (Separation of Duties) requires organizations to define, document, and enforce SoD policies.

Leaver — Deprovisioning Completely

When someone leaves the organization, every identity, credential, and access path associated with them must be eliminated. This is the deprovisioning checklist, and it’s longer than most organizations realize:

Disable IdP account — immediately. This cascades to all federated services (if you’ve done federation right).
Revoke all OAuth tokens and API keys — disabling the account doesn’t invalidate active sessions or previously granted tokens in many systems.
Rotate shared credentials — if the departing person had access to shared accounts, root passwords, service account credentials, or encryption keys, those credentials must be rotated immediately.
Recover hardware — laptops, phones, hardware security keys, smart cards.
Remove SSH keys — from every server they were deployed to. This requires knowing which servers they accessed.
Remove from distribution lists, shared mailboxes, and group memberships — even inactive accounts in groups can receive sensitive information.
Transfer ownership — of documents, shared drives, cloud resources, and automated workflows. If a departing person owns the CI/CD pipeline, and their account is disabled without ownership transfer, production deployments break.
Review and disable non-federated accounts — every system that doesn’t authenticate through the central IdP needs manual deprovisioning.

The timeline matters. Best practice is to disable IdP access the moment the departure is effective — not end of day, not end of week, not “when IT gets around to it.” For involuntary terminations, access should be revoked before the person is notified. That sounds harsh, but the insider threat risk during a hostile departure is real and well-documented.

Identity Governance and Administration (IGA)

IGA platforms (SailPoint, Saviynt, One Identity, Microsoft Entra Identity Governance) provide the automation and oversight layer for the entire lifecycle:

Automated provisioning and deprovisioning based on HR system events.
Access certification campaigns — periodic reviews where managers verify that each person’s access is still appropriate. Managers receive a list of their direct reports’ access and must approve or revoke each entitlement.
Role mining and modeling — analyzing actual access patterns to define optimal roles and identify outliers.
SoD policy enforcement — automatically detecting and preventing toxic access combinations.
Compliance reporting — generating evidence of access controls for auditors (SOX, HIPAA, PCI DSS, GDPR).

Access certification (also called access reviews or entitlement reviews) is the safety net. Even with perfect automation, access drift happens. Quarterly access reviews force a human to look at each entitlement and ask “does this person still need this?” The reviews are tedious. They’re also one of the few controls that catch the slow accumulation of unnecessary access.

SCIM — Automating Across Boundaries

SCIM 2.0 is a REST API protocol for managing identities across systems. When your IdP creates, updates, or deletes a user, SCIM propagates that change to every connected application. The key operations:

Create — new user provisioned in IdP, SCIM creates accounts in connected applications with appropriate attributes (name, email, groups).
Update — user changes roles or attributes, SCIM updates connected applications.
Delete/Deactivate — user leaves, SCIM disables or removes accounts in connected applications.

SCIM doesn’t solve everything. Applications need to support the SCIM protocol (most major SaaS vendors do). Custom or legacy applications often don’t. And SCIM only works for applications that are connected to your IdP — shadow IT and unmanaged applications are invisible to it.

How It Gets Exploited

Orphaned Account Abuse

Orphaned accounts are the low-hanging fruit of privilege escalation. An attacker discovers a valid but unmonitored account — a former employee, a decommissioned service — and uses it for access. Because nobody is watching the account, the activity goes undetected. MITRE ATT&CK T1078.001 (Valid Accounts: Default Accounts) and T1078.002 (Valid Accounts: Domain Accounts) document this pattern. The Colonial Pipeline attackers used exactly this technique — an orphaned VPN credential with no MFA.

Permission Accumulation Exploits

An attacker who compromises an account with accumulated permissions from multiple roles has a broader attack surface than the current role would suggest. The account’s access spans Engineering, Finance, and Operations — not because the person needs all three, but because nobody cleaned up after their last two role changes. The attacker gets lateral movement for free.

Insider Threats During Role Transitions

The mover phase is the highest-risk window for insider threats. A person transitioning to a new role may retain access to sensitive systems from their old role while gaining access to new ones. If the transition is involuntary (demotion, lateral move to a less sensitive role), the risk increases. Without timely access modification, the window for data exfiltration or sabotage is wide open.

Delayed Deprovisioning

Every hour an account remains active after someone leaves is an hour of exposure. If the departure is hostile — termination for cause, layoff, dispute — the risk is acute. Former employees have used active credentials to access systems after departure, steal data, deploy ransomware, or simply cause destruction out of spite. The Verizon DBIR consistently reports insider actions as a significant breach category.

What You Can Do

Automate the lifecycle. Connect your HR system to your IdP. When HR records a hire, the provisioning workflow fires. When HR records a departure, the deprovisioning workflow fires. Remove humans from the loop for standard operations.

Run access reviews quarterly. Every manager reviews every direct report’s access. Every system owner reviews every account on their system. Revoke what doesn’t belong. Make it a calendar item, not an afterthought.

Audit for orphaned accounts monthly. Compare your IdP account list to your HR active employee list. Any accounts that don’t map to an active person need investigation and likely deprovisioning. Do the same for service accounts — compare the inventory to active applications.

Enforce separation of duties with tooling. Define SoD rules in your IGA platform. Let the system flag conflicts automatically rather than relying on managers to notice them. Toxic combinations — approve and execute, create and audit, code and deploy to production — should generate automatic alerts.

Close the non-federated gap. Every application that doesn’t authenticate through your IdP is a deprovisioning blind spot. Prioritize federating these applications, or at minimum, maintain a manual deprovisioning checklist that covers them.

Treat movers like a simultaneous join and leave. When someone changes roles, revoke old access with the same urgency you’d apply to a departure. Provision new access simultaneously. This is operationally harder than sequential provisioning, but it eliminates the window of accumulated access.

Identity Lifecycle — Provisioning, Deprovisioning & the Accounts Nobody Disabled