The Identity Lifecycle in Practice
The most technically elegant authentication system in the world is useless if you cannot answer a simple question: "Does this person still work here?"
That question - and the thousands of operational processes behind it - is what identity lifecycle management is about. It is the least glamorous part of IAM and arguably the most important. When identity lifecycle breaks down, former employees retain access to production systems, contractors keep VPN credentials after their engagement ends, and departed executives still have admin rights to financial systems months after leaving.
I have seen every one of these failures firsthand. At LoginRadius, managing identity lifecycle was not just an internal concern - it was a product requirement. Our enterprise customers needed to manage millions of customer identities through their natural lifecycle: registration, progressive enrichment, consent changes, account linking, and eventual deletion. The patterns are different from workforce identity, but the discipline is the same.
The Joiner-Mover-Leaver Framework
Every identity, whether employee or customer, goes through three phases. In workforce IAM, this is called the Joiner-Mover-Leaver (JML) process.
THE IDENTITY LIFECYCLE
======================
┌───────────────────────────────────────────────────┐
│ │
▼ │
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐│
│ JOINER │────>│ ACTIVE │────>│ MOVER │────>│ LEAVER ││
│ │ │ │ │ │ │ ││
│ Day 1 │ │Ongoing │ │Role │ │Offboard││
│Onboard │ │Access │ │Change │ │Deprovi-││
│Provision│ │Reviews │ │Transfer│ │sion ││
└────────┘ └───┬────┘ └───┬────┘ └────────┘│
│ │ │
│ └─────────────────────┘
│ (Mover returns to Active)
│
▼
┌────────┐
│CERTIFY │
│ │
│Periodic│
│Access │
│Review │
└────────┘
The Joiner - Day One Access
When a new employee starts, they need access to systems on their first day. Not their second day. Not "once IT gets to the ticket." Day one.
This sounds trivial. It is not. A typical enterprise employee needs access to 15-25 applications on day one: email, Slack, HR portal, VPN, development tools, shared drives, project management, CRM, and department-specific applications. Each of these applications has its own provisioning mechanism, its own role model, and its own approval workflow.
What a mature Joiner process looks like:
| Step | Trigger | Action | System |
|---|---|---|---|
| 1 | Offer letter signed | Create identity record | HR System (Workday) |
| 2 | HR record created | Auto-provision base account | IGA (SailPoint) |
| 3 | Start date - 3 days | Create email, directory account | IdP (Entra ID) |
| 4 | Department assigned | Apply role-based access package | IGA (SailPoint) |
| 5 | Manager approval | Grant department-specific apps | IdP + SCIM |
| 6 | Start date | Activate all accounts | Automated |
| 7 | Day 1 | Employee receives credentials/passkey | Self-service portal |
What actually happens at most organizations:
An IT admin gets a ticket saying "New hire starting Monday." They manually create accounts in six different systems, copy permissions from "someone else in that department," miss two applications, and the new hire spends their first week submitting access request tickets.
The "copy permissions from a similar user" anti-pattern is one of the most dangerous practices in IAM. It causes access creep - each copied user inherits not just the base role permissions but also every exception, temporary access, and one-off grant that accumulated over their predecessor's tenure. After a few generations of copying, users have access to systems they have never heard of and should never touch.
The Mover - Role Changes and Transfers
Movers are where lifecycle management most commonly fails. When an employee transfers from Engineering to Sales, they need Sales application access. But what happens to their Engineering access?
In most organizations: nothing. Nobody removes it.
This is called access accumulation or privilege creep, and it is a massive security and compliance risk. An employee who started in Engineering, moved to Finance, then moved to Sales might have read access to source code repositories, financial reporting systems, and CRM data. No single role should have all three.
The correct Mover process:
- HR system records the role change
- IGA platform detects the change
- Old role access is flagged for removal (with grace period)
- New role access is provisioned
- Manager of new role approves the new access package
- Old access is removed after grace period (typically 30 days)
- Exception requests for retained access require documented business justification
MOVER ACCESS TRANSITION
========================
Before Move: After Move (correct):
┌─────────────────────┐ ┌─────────────────────┐
│ Engineering Role │ │ Sales Role │
│ ├── GitHub │ │ ├── Salesforce │
│ ├── Jira │ => │ ├── HubSpot │
│ ├── AWS Console │ │ ├── Gong │
│ └── CI/CD Pipeline │ │ └── LinkedIn Sales │
└─────────────────────┘ └─────────────────────┘
After Move (reality at most orgs):
┌─────────────────────────────────┐
│ Engineering + Sales (combined!) │
│ ├── GitHub <-- RISK │
│ ├── Jira │
│ ├── AWS Console <-- RISK │
│ ├── CI/CD Pipeline <-- RISK │
│ ├── Salesforce │
│ ├── HubSpot │
│ ├── Gong │
│ └── LinkedIn Sales Navigator │
└─────────────────────────────────┘
The Leaver - Offboarding and Deprovisioning
When someone leaves the organization, their access must be revoked. Immediately. Not "within 24 hours." Not "when IT gets to it." Immediately upon termination becoming effective.
This matters most for involuntary departures. When an employee is fired, there is a window between when they learn about it and when IT disables their accounts. In that window, a disgruntled employee can exfiltrate data, sabotage systems, or plant backdoors.
Critical Leaver timeline:
| Timeframe | Action | Priority |
|---|---|---|
| T+0 (termination effective) | Disable IdP account (kills all SSO) | Critical |
| T+0 | Revoke VPN and remote access | Critical |
| T+0 | Revoke MFA tokens | Critical |
| T+0 | Invalidate active sessions | Critical |
| T+1 hour | Disable email (with forwarding to manager) | High |
| T+4 hours | Revoke cloud console access (AWS, Azure, GCP) | High |
| T+24 hours | Transfer file/data ownership | Medium |
| T+7 days | Archive mailbox | Medium |
| T+30 days | Delete accounts per retention policy | Low |
The fastest way to disable all access is through the IdP. If every application authenticates through Okta or Entra ID via SSO, disabling the IdP account immediately kills access to all federated applications. This is one of the strongest arguments for SSO - it gives you a single kill switch for offboarding. Applications that use local accounts outside of SSO are deprovisioning nightmares.
SCIM - The Protocol That Makes Lifecycle Work
SCIM (System for Cross-domain Identity Management) is the REST API standard that automates identity provisioning across systems. If SAML and OIDC are how users authenticate, SCIM is how their accounts get created, updated, and deleted.
SCIM PROVISIONING FLOW
=======================
HR System IGA/IdP Target App
(Workday) (SailPoint/Okta) (Salesforce)
| | |
| 1. New hire | |
| event | |
|----------------->| |
| | |
| | 2. POST /Users |
| | { |
| | "userName": "alice"|
| | "name": {...} |
| | "emails": [...] |
| | "department": "Eng"|
| | } |
| |--------------------->|
| | |
| | 3. 201 Created |
| |<---------------------|
| | |
| (Later: role | |
| change) | |
|----------------->| |
| | |
| | 4. PATCH /Users/123 |
| | { |
| | "department":"Sales"|
| | } |
| |--------------------->|
| | |
| (Later: | |
| termination) | |
|----------------->| |
| | |
| | 5. DELETE /Users/123 |
| | (or set active:false)|
| |--------------------->|
SCIM operations:
| Operation | HTTP Method | Use Case |
|---|---|---|
| Create user | POST /Users | Joiner provisioning |
| Read user | GET /Users/{id} | Sync verification |
| Update user | PATCH /Users/{id} | Mover - attribute changes |
| Replace user | PUT /Users/{id} | Full profile update |
| Delete user | DELETE /Users/{id} | Leaver deprovisioning |
| List users | GET /Users?filter= | Reconciliation |
| Create group | POST /Groups | Role provisioning |
SCIM adoption is uneven. Major SaaS applications (Salesforce, Slack, Zoom, Box) support SCIM well. But many enterprise applications - especially older ones - do not. For these, you end up building custom connectors using APIs, database writes, or even CSV file imports. A significant portion of IAM engineering work is building and maintaining these connectors for applications that do not speak SCIM.
Access Certifications and Reviews
Provisioning access is only half the problem. The other half is proving that access is still appropriate. This is what access certification (also called access review or entitlement review) does.
Regulatory frameworks like SOX, HIPAA, and SOC 2 all require periodic review of access rights. Typical certification cycles are quarterly for high-risk access and annually for standard access.
How an access certification campaign works:
- The IGA platform generates a list of all users and their current entitlements
- Each manager receives a review package: "Here are the people who report to you and what they have access to. Approve or revoke each entitlement."
- Application owners receive a separate review: "Here are all users with access to your application. Are they all appropriate?"
- Reviewers approve, revoke, or flag items for investigation
- Revoked access is automatically deprovisioned
- Results are documented for audit evidence
The problem with access certifications in practice:
Most managers rubber-stamp everything. They do not have time to review 200 entitlements for 15 direct reports, and they do not understand what half the entitlements mean. "Oracle EBS - AP_INVOICES_ALL - READ" - approve or revoke? Most managers just click "approve" for everything.
This is why access intelligence is becoming critical. Modern IGA platforms use analytics to flag anomalies - "This user has access that no one else in their role has" or "This entitlement has not been used in 90 days." These flags guide reviewers to focus on the decisions that actually matter.
Real-World Identity Operations - Lessons from LoginRadius
When I was building LoginRadius, we faced identity lifecycle challenges at a scale that most workforce IAM teams never encounter. We were managing customer identities - not hundreds or thousands, but hundreds of millions, eventually surpassing a billion.
Customer identity lifecycle differs from workforce identity in several fundamental ways:
Self-service is everything. Customers create their own accounts, update their own profiles, and delete their own data (GDPR right to erasure). There is no IT department to submit a ticket to. The lifecycle must be fully automated and user-driven.
Progressive profiling replaces day-one provisioning. You do not ask a customer for 20 fields on registration - you ask for email and password, then gradually collect more information over time as they engage with the product. This means the identity record is always incomplete and always evolving.
Account linking is a constant challenge. A customer might sign up with email, then later try to log in with Google social login using the same email. Are these the same person? Should the accounts be merged? What happens to the data in each account? We built sophisticated account linking logic that handled dozens of edge cases.
Scale changes everything. When you have a billion identities, every database query matters. Every authentication flow must complete in under 200 milliseconds. Every provisioning operation must handle eventual consistency. You cannot just "add more servers" - you need fundamentally different architectural patterns.
Consent is a lifecycle event. Under GDPR and similar regulations, a customer's consent preferences are part of their identity lifecycle. When they withdraw consent for marketing communications, that change must propagate to every downstream system within the required timeframe - often 72 hours.
These experiences shaped how I think about identity lifecycle management at any scale. Whether you are managing 5,000 employees or 500 million customers, the principles are the same:
- Automation is not optional. Manual lifecycle processes do not scale and do not comply.
- The source of truth must be definitive. Pick one system as authoritative and flow changes outward.
- Deprovisioning is harder than provisioning. Anyone can create accounts. Ensuring they get cleaned up is the real challenge.
- Lifecycle events must be auditable. Every change, every approval, every revocation must be logged.
- Edge cases will find you. The employee who rejoins after 6 months. The contractor whose engagement extends three times. The customer who deletes their account and then wants it back. Build for these.
If you want to stand out in an IAM interview, demonstrate that you understand the operational reality of lifecycle management - not just the theory. Talk about rubber-stamping in access reviews and how you would fix it. Talk about the gap between HR termination and access revocation and why it matters. Talk about access creep from role changes. These are the problems that keep IAM teams up at night, and candidates who understand them get hired.
Building Your Lifecycle Management Skills
To develop practical lifecycle management expertise:
Lab exercise: Set up an HR system emulator (even a simple database), connect it to Keycloak or a free Okta developer tenant, and implement automated provisioning and deprovisioning. Build the JML flow end to end.
Certification value: SailPoint Certified IdentityNow Engineer is one of the most in-demand certifications in IGA. The skills it covers - identity lifecycle, access certifications, role management, and connector development - map directly to high-paying enterprise roles.
Resume impact: On your resume, quantify lifecycle management impact: "Automated onboarding for 5,000 users across 12 applications, reducing Day 1 provisioning time from 3 days to 2 hours" or "Reduced orphaned accounts by 94% through automated deprovisioning linked to HR termination events."
The identity lifecycle is where IAM theory meets operational reality. Master it, and you will never lack for work.