Most access problems don't start with a breach. They start with a promotion.
Someone joins, gets the tools their role needs, and everything is correct on day one. Then they move teams. They get the new access, and nobody removes the old. Two more moves and they're carrying permissions from three jobs they no longer do. Multiply that across a few hundred people and you have an access estate nobody designed and nobody can explain.
Identity lifecycle management is the practice of stopping that. This guide covers what it is, where it breaks, and how to make access follow people properly instead of just accumulating.
Identity lifecycle management is the process of controlling a user's access from the moment their account is created to the moment it's removed. It covers three events: creating the identity and granting initial access when someone joins, adjusting that access when their role changes, and revoking it completely when they leave.
The goal is simple to state and hard to do: people should have exactly the access their current role requires, and nothing else, at every point in time.
It's worth separating it from two things it gets confused with.
It isn't identity governance. Governance is the wider discipline - policy, certification, audit evidence, who is allowed to decide what. Lifecycle management is the operational layer underneath it: the actual granting and removing. You can run lifecycle management without much governance, and plenty of organizations do. It just means nobody is checking whether the rules are right.
It isn't SaaS lifecycle management. That's the application lifecycle - buying, deploying, renewing and retiring the software itself. Identity lifecycle management is about the people who use it. Related, and often run by the same team, but different work.
A new hire needs accounts created and access granted across everything their role touches. Done manually, this is slow and inconsistent - and the usual shortcut is to copy the permissions of someone already in the team.
Copying is where the damage starts. You inherit whatever that person had accumulated, including access they shouldn't still have. Do it a few times and you've propagated one person's permission sprawl across a whole department.
The fix is granting by role rather than by example. Define what a role needs once, then provision from that definition.
This is the stage that breaks, and it breaks quietly.
When someone changes role, two things need to happen: grant the new access, remove the old. The first happens reliably, because the person asks for it - they can't do their job without it. The second has no such pressure. Nobody files a ticket asking to lose access.
So access accumulates. The internal transfer who has been through four teams ends up with more permissions than anyone intended, and usually more than their manager realizes. This is why long-tenured employees are so often the most over-permissioned people in an organization, despite being the most trusted.
Handling the mover stage properly is the single biggest difference between a lifecycle process that works and one that just automates onboarding.
When someone leaves, access has to be revoked everywhere - not just the obvious systems.
Email, VPN and the core platforms usually get handled, because they're on the checklist. The long tail of departmental tools often isn't, because IT doesn't always know those tools exist. Those accounts stay live, keep costing money, and remain a way in. Accounts belonging to people who have left are among the most common starting points for an attack, precisely because nobody is watching them.
For more on what happens when this stage fails, see our guide to orphaned accounts.
Automated provisioning is what makes the joiner stage work at any scale: access is granted from a rule rather than a request.
The mechanics are straightforward. Your HR system is the source of truth for who works here and what their role is. When a record is created or changed there, it triggers provisioning across connected applications. Nobody raises a ticket; the access appears because the role says it should.
Three things have to be right for this to work.
The role definitions. You need agreed answers to "what does a sales engineer get?" If those definitions don't exist, automation just distributes the old inconsistency faster.
The HR data. If job titles are free text and department names are entered differently by different managers, rules can't match reliably. Provisioning automation usually fails on data quality long before it fails on technology.
The connections. Applications need to accept programmatic provisioning — through SCIM, an API, or a native integration. Anything without that stays manual, and those manual exceptions are where the gaps reappear.
Access provisioning is worth distinguishing from account creation. Creating an account gives someone a way in. Provisioning determines what they can do once inside. Systems that do the first well and the second loosely produce users who exist correctly and are permissioned badly.
Deprovisioning sounds like provisioning in reverse. It isn't, for two reasons.
You have to know everywhere the person had access. Provisioning only needs to know where access should go. Deprovisioning needs a complete inventory of where it actually went - including applications adopted by a team without telling IT. You can't revoke what you don't know about, which makes discovery a prerequisite rather than a nice-to-have.
Removal isn't always the right answer. Deleting an account can destroy data the business needs, break integrations that were running under that user, or orphan files nobody else can reach. Mature deprovisioning suspends access first, transfers ownership of data and automations, then removes the account.
The useful measure here is time-to-revoke: how long between someone leaving and their last access being cut. If it's measured in weeks, you have an exposure window. If nobody can tell you the number, you have a bigger problem than the number.
For the operational detail - what to delete, in what order, and how to archive data first - see our guide to deleting offboarding employee accounts.
Service accounts, API integrations, bots and AI agents all hold access. Most organizations manage none of them through a lifecycle process.
They're created for a project, given broad permissions to avoid troubleshooting, and then forgotten. They have no manager, no HR record, no leaving date, so none of the triggers that drive human lifecycle management apply. Many outlast the person who created them and the project they were built for.
They often hold more privilege than any individual employee, and because nothing forces a review, that privilege is permanent by default.
Bringing them into scope means the same discipline: a named owner, a defined purpose, an expiry or review date, and permissions matched to the job. The hard part isn't the policy - it's finding them in the first place, since they rarely appear in any directory anyone maintains.
AI agents make this more urgent, because they're being created faster than any previous category of non-human identity and often act with delegated human permissions. Our guide to AI agent governance covers that specifically.
Five steps, in order. The sequence matters more than the speed.
1. Find out what access exists now. Not what should exist - what does. Pull from your identity provider, your HR system and your applications. Expect the picture to be worse than anyone predicted; that gap is the reason the work is needed.
2. Pick your source of truth. Almost always the HR system, because that's where joining and leaving are recorded first. Everything downstream keys off it, so its data quality sets your ceiling.
3. Define roles for the common cases. Don't attempt every role. Cover the ones you hire into repeatedly - that's usually most of your volume - and handle the rest by exception.
4. Automate leaving before joining. This is counterintuitive and it's the right order. Onboarding failures are visible and get fixed within hours, because someone is blocked and complaining. Offboarding failures are invisible and last for years. Automate the silent one first. For how to design that process end to end, see our guide to building a SaaS offboarding process.
5. Review what the process misses. No lifecycle process catches everything. Periodic user access reviews are how you find the exceptions, the manual grants and the accounts that fell outside the rules.
