Identity lifecycle management is the operational process an organization uses to create, change and remove accounts and access as people join, move between roles and leave. It turns events in a person’s working life, such as a hire date or a transfer, into concrete changes across email, applications, devices and data.
When the process works, nobody notices: new staff are productive on day one and departing staff lose access on their last day. When it fails, the results include idle new hires, employees who accumulate years of unnecessary rights and former staff who can still sign in. This guide explains the stages, triggers, special cases and practical improvements.
A Career Seen Through Its Accounts
Picture a hypothetical employee named Daniel. He joins a retailer as a store analyst, transfers to the marketing team two years later, takes parental leave, returns as a manager and eventually resigns. Each of those moments should change what he can access, sometimes in several systems at once.
If every change is handled manually through emails and tickets, small errors accumulate. Daniel might keep his store analytics access after moving to marketing, receive manager rights before his promotion is official, or keep remote access for weeks after leaving because the departure email reached the wrong person.
Identity lifecycle management treats these events as a predictable sequence rather than a series of surprises. By defining in advance what each event should do and connecting it to trustworthy data, the organization keeps access aligned with reality throughout a person’s entire relationship with it.
The same thinking helps individuals. When you change jobs, move out of a shared home or end a subscription, treat it as a lifecycle event: update recovery details, remove old shared access and close accounts tied to the role you left behind.
Joiners, Movers and Leavers
Practitioners usually describe the lifecycle with three stages, abbreviated as JML. Each stage has a distinct goal, and each carries its own typical failures.
Joiners
The joiner stage creates the identity and grants starting access. Ideally, accounts are prepared before the first day, with standard access based on job role and location. Credentials should be delivered securely, for example through an in-person setup or a verified enrollment link, never by sending a password in a plain email.
Movers
The mover stage handles transfers, promotions and changes in responsibility. It must both add new access and remove access tied to the previous role. Many organizations handle additions well because people ask for what they need, but removals are often forgotten because nobody complains about having too much access.
A reliable mover process asks the old manager and the new manager to confirm the change, so both sides of the transfer are covered.
Leavers
The leaver stage disables access when someone departs. Timing matters most here, especially for sudden or contentious departures. Accounts should be disabled promptly, active sessions ended, and company data and devices recovered. Full deletion can follow later, according to retention rules, once ownership of files and mailboxes has been transferred.
Triggers: What Should Start Each Change
A lifecycle process is only as reliable as the signals that start it. The most dependable trigger is a change in an authoritative source, typically the human resources system for employees and a vendor management or sponsorship record for contractors. When that record changes, the lifecycle process reacts.
Triggers based on informal messages are fragile. A manager may forget to email IT, or the email may sit unread during a holiday. Automating the link between human resources and the identity system removes that dependency, although it does require human resources data to be accurate and entered on time.
Some events need extra triggers beyond human resources. A security team may need to suspend an account immediately during an investigation, and a contractor’s sponsor may end an engagement early. A clear, documented path for these urgent changes ensures they happen quickly without bypassing records.
Provisioning: Automated and Manual Approaches
Provisioning means creating accounts and assigning access in target systems; deprovisioning means removing them. Organizations usually combine automated and manual methods, depending on how well each application connects to the central identity system.
Common provisioning approaches include:
- Connector-based automation: the identity system creates and updates accounts directly through an application’s interface.
- Standard protocols: SCIM, the System for Cross-domain Identity Management, gives many cloud applications a common way to receive account changes.
- Just-in-time creation: an account is created the first time a person signs in through single sign-on.
- Ticket-based manual work: an administrator receives a task and makes the change by hand.
Automation reduces delays and mistakes, but manual steps will likely remain for older or specialized systems. Track those manual tasks carefully, assign them deadlines and confirm completion, because unfinished deprovisioning tickets are a common source of lingering access.
The Mover Problem and Privilege Creep
Privilege creep is the gradual accumulation of access as people change roles without losing old permissions. Long-serving employees are especially affected, sometimes holding rights from four or five previous positions. Each extra permission expands what an attacker could reach if that person’s account were compromised.
The cleanest fix is to treat a role change as a recalculation rather than an addition. When someone moves, the lifecycle process compares their old and new role-based access, removes what no longer applies and adds what the new role requires. Exceptions still needed temporarily should receive an end date.
Transitions often require a short overlap, for example while someone hands over their old duties. Supporting that need with time-limited access, rather than leaving the old permissions open-ended, satisfies the business while ensuring the overlap ends automatically once the handover period is complete.
Offboarding Without Loose Ends
Departures deserve a dependable checklist because missing one step can leave a door open. The exact list varies by organization, but a typical sequence looks like this:
- Disable the primary account and sign-in to the identity provider.
- End active sessions and revoke tokens issued to apps and devices.
- Remove the person from privileged groups and shared credentials they knew.
- Recover company devices, or remotely wipe work data from them.
- Transfer ownership of files, mailboxes and scheduled jobs to a successor.
- Record completion and keep the account disabled until retention rules allow deletion.
Shared secrets need particular attention. If a departing administrator knew passwords for shared system accounts, those passwords should be changed. Planning ahead, by storing shared credentials in a vault that logs who viewed them, makes this step far easier and more precise, because you know exactly which secrets a departing person could have seen.
Special Cases That Break Simple Processes
Real lifecycles include events that do not fit neatly into joiner, mover or leaver. Leaves of absence, such as extended medical or parental leave, may justify suspending access temporarily while preserving accounts and files for the person’s return.
Rehires raise a different question: should the returning person receive their old account or a new one? Reusing old accounts risks restoring outdated permissions, while creating new ones can break history and records. Many organizations reactivate the identity but reset its access to the new role’s standard set.
Name changes, for example after marriage, should update display names and email aliases without creating a duplicate identity. Using a stable internal identifier, rather than the person’s name, as the key that links systems together prevents a name change from splitting one person into two accounts.
Lifecycles for Non-Human Identities
Service accounts, application credentials and automated workloads also have lifecycles, yet they rarely appear in human resources data. Without a deliberate process, they are created during a project and simply never retired, often with broad permissions and passwords that never change.
Give each non-human identity a recorded owner, purpose and expected lifespan when it is created. Tie its review to that owner’s lifecycle, so that when the owner leaves or changes role, someone else formally accepts responsibility or the identity is retired. Without that handover, service identities quietly become orphans.
Credential rotation is part of this lifecycle too. Secrets and certificates should be replaced on a schedule and immediately after any suspected exposure. Automating rotation where systems support it removes the temptation to leave long-lived credentials in place simply because changing them is inconvenient.
Orphaned and Dormant Accounts
An orphaned account is one with no matching active person or owner, often left behind after a departure that bypassed the normal process. A dormant account belongs to a valid identity but has not been used for a long time. Both are attractive to attackers because unusual activity on them may go unnoticed.
Regular reconciliation finds them. This means comparing accounts in each important application against the authoritative source and flagging any that do not match. Applications outside single sign-on are especially prone to orphans, because they never receive the central signal that someone left.
When orphans or dormant accounts appear, disable them first and investigate second. If a legitimate need surfaces, the account can be reassigned to a named owner. Each discovery is also a clue to a broken trigger or manual step that should be fixed to prevent recurrence.
Signs Your Lifecycle Process Is Healthy
A healthy process shows up in a few simple observations. New staff receive working access by their first day without a chain of follow-up requests. Departing staff lose sign-in on their final day, and reconciliation finds few or no orphaned accounts in key systems.
Movers are a revealing test. Pick several people who changed roles recently and compare their current access with what their new role requires. If old permissions remain, the mover stage needs work, regardless of how smoothly joining and leaving appear to run.
Tracking the time between a human resources change and the matching access change is another useful indicator. Long or inconsistent delays usually point to manual handoffs. Reporting these measures regularly keeps lifecycle quality visible to managers who might otherwise assume the process takes care of itself.
Strengthening Your Lifecycle Process Step by Step
Start by connecting your authoritative sources to your central identity system and automating account disabling for leavers. Removing access promptly delivers the greatest risk reduction for the effort, and it builds confidence in the data before you automate more complex steps.
Then address movers by defining standard access for common roles and recalculating access on each transfer. Bring the most important applications into automated provisioning, and track any remaining manual tasks with deadlines and confirmation.
Afterwards, extend the same discipline to contractors and non-human identities, and schedule regular reconciliation. Identity lifecycle management never reaches a final state, because organizations constantly change, but each improvement shortens the window in which the wrong person holds the wrong access.