Module 10 Lesson 4 of 6 🕑 ~50 min

> cat module-10-4-identity-lifecycle.md

Identity Lifecycle (Joiner-Mover-Leaver)

Every identity has a lifespan: it's created, it changes, and eventually it should stop having access. Getting this right on day one is a productivity problem; getting it wrong on someone's last day is a security incident. This lesson covers the full JML model, plus the identities that never fit the "employee" mould at all.

1 The Joiner-Mover-Leaver Model

Identity lifecycle management deals with how identities change over time, and the standard model has three phases: Joiner – Mover – Leaver, often abbreviated JML. Microsoft's Entra ID Governance lifecycle workflows documentation uses exactly these three phases to automate what happens as users join, change position, and leave. SailPoint similarly supports lifecycle states that automatically grant, disable, or remove access based on someone's organisational status.

2 Joiner

A Joiner is anyone entering the organisation — employee, contractor, consultant, intern, or external partner. The process often starts several days before their first day:

HR creates employee↓ Employee ID generated↓ IAM receives identity↓ AD account created · Entra identity synchronised · mailbox created↓ Department roles calculated · applications provisioned↓ Manager notified — employee starts

A good Joiner process means the employee has correct access on day one. A poor one looks like: employee arrives, no laptop access, no mailbox, no application access, 10 support tickets, three days of lost productivity — which is exactly why IAM automation has direct, measurable business value, not just a security one.

Some organisations create identities before the person officially starts — pre-hire — e.g. identity created 5 days early, mailbox created 2 days early, account enabled at 08:00 on the actual start date. The IAM platform has to distinguish PreHire from Active status so nothing usable leaks out before day one.

3 Mover

A Mover is someone whose organisational position changes — promotion, transfer, department change, country change, manager change, legal entity change, temporary assignment, or project assignment. Movers are often harder than Joiners, because a Joiner only ever adds access, while a Mover has to both add and remove.

Alice moves from Customer Support to Finance. IAM needs to add SAP Finance, Finance SharePoint, finance reporting, and finance groups — and remove the support admin console, customer diagnostic tools, and support-ticket administration. If the add happens but the remove doesn't, Alice experiences access creep (Lesson 1) right there in the tooling.

Someone employed for 15 years might have worked in Sales, Support, Engineering, Management and Security in turn. Without proper lifecycle controls, they can retain permissions from every one of those roles — which is why Mover processes, not just Joiner and Leaver, are a major source of excessive permissions in real organisations.

4 Leaver

The Leaver process is one of the most security-critical IAM processes there is. A typical flow:

HR sets employmentStatus = Terminated↓ IAM detects the change↓ Primary account disabled · SSO sessions revoked↓ VPN disabled · application accounts disabled↓ Privileged access removed · cloud roles removed↓ Tokens/credentials revoked↓ Manager receives ownership-transfer tasks

Not every departure follows the same timeline. A normal departure might schedule account disabling for Friday 17:00; a security termination may need access removed within minutes, which is why some organisations run a separate "HR Emergency Termination → priority IAM workflow → immediate disable" path alongside the standard one.

Why disabling the AD account isn't enough

Older organisations sometimes assume "disable Active Directory = employee has no access." That's no longer safe to assume. The employee may also hold an AWS IAM user, a GitHub account, a local application account, a VPN certificate, an API key, a live Salesforce session, a database account, an SSH key, a personal access token, a SaaS account, or a service credential — none of which necessarily die with the AD account. Modern offboarding requires enterprise-wide lifecycle management, not one directory flag.

Session revocation

Consider: employee logs in at 09:00, the IdP creates a session, and they're terminated at 10:00. If the account is merely disabled while their existing application session stays valid until, say, 18:00, they may retain access for hours after "termination." Modern lifecycle architecture has to consider account status, IdP session, application session, refresh tokens, API tokens, certificates, SSH keys, and device credentials together — identity termination is not the same thing as session termination, a distinction Module 9 (Lesson 6) covers from the protocol side.

5 Identity Lifecycle Beyond Employees

Global enterprises manage far more than employees — contractors, vendors, partners, customers, guests, administrators, service accounts, applications, APIs, devices, cloud workloads, bots, and RPA. Every one of these needs its own lifecycle.

Contractors
Should normally have an explicit expiration date (e.g. 1 January–30 June) so IAM can auto-disable access on that date unless the contract is extended. Without automatic expiration, contractor accounts routinely become orphaned (Section 7 below).
Guest users
Entra and similar platforms let organisations collaborate with people from other organisations. These accounts need periodic review: does the guest still need access? Does the sponsoring employee still work here? Does the partner relationship still exist?
Service accounts
E.g. svc_backup, svc_database — often no human user at all, so the standard HR-driven JML process simply doesn't apply. They instead need explicit metadata: owner, purpose, application, creation date, expiration date, privileges, credential rotation policy. If the owner leaves the company, ownership has to be actively reassigned, or the account effectively becomes ownerless.
Workload identities
AWS IAM roles, Azure managed identities, Entra service principals, Kubernetes service accounts, API clients, CI/CD identities, cloud functions, containers. Modern cloud environments frequently contain more non-human identities than human employees — managing them is an increasingly large share of the job.

6 Access Requests & Separation of Duties

Not all access can be automatically calculated from a role — users sometimes need to request extra access:

Alice → IAM Access Request Portal
   → Request: Production Database Read
   → Manager Approval → Application Owner Approval → Security Approval
   → Provision

The request itself creates an audit trail. Approval depth typically scales with risk: low-risk access might need only manager approval; medium-risk needs manager + application owner; high-risk needs manager + application owner + security + privileged-access controls on top.

Separation of Duties (SoD) prevents dangerous permission combinations regardless of approvals. If one person can both Create Supplier and Approve Supplier Payment in a financial system, they could create a fake supplier, create an invoice, approve the payment, and move company money — entirely within their own authorised access. An SoD policy blocks one person from ever holding both roles simultaneously. This matters most in banking, finance, ERP systems, procurement, and other regulated industries where a single compromised or malicious identity shouldn't be able to complete an entire high-risk transaction alone.

7 Access Reviews, Orphan & Dormant Accounts

Provisioning controls who initially gets access. Governance asks whether they should still have it — a periodic access review (also called certification or recertification), e.g. "Manager: does Alice still require Salesforce Admin? Approve / Remove." Common review types: manager review, application-owner review, privileged-access review (security reviews administrators), guest review, and service-account review (owners confirm non-human accounts are still needed).

Orphan account
An account that exists without a properly associated active owner — e.g. John leaves, his AD account is disabled, but a legacy application's separate john.smith account stays active. Dangerous because nobody may be monitoring it, credentials may still work, ownership is unclear, and attackers can use it unnoticed. Reconciliation (Lesson 2) and certification are what surface these.
Dormant account
An account with a valid owner that simply isn't being used — e.g. last login 415 days ago. The organisation should ask why it still exists at all; dormant privileged accounts are especially risky since nobody would necessarily notice if one were quietly used.

Lab Lab 1 – Run the Full JML Lifecycle

🦡 Hands-on lab

Create Alice with Department = Sales and confirm she's automatically assigned Sales-Users. Then change her to Department = Finance.

🔮 Predict first

What should IAM do automatically when her department changes — and what happens if only half of that happens?

Reveal the expected behaviour

IAM should remove Sales-Users and add Finance-Users together, as one atomic Mover event. Finally, set employmentStatus = Terminated and verify access is actually removed — that's the complete Joiner → Mover → Leaver cycle in miniature. If only the "add" half of the Mover step ran, you'd have just reproduced access creep on purpose.

Lab Lab 2 – Run an Access Review

🦡 Hands-on lab

Create three users — Alice, Bob, Charlie — and give them all privileged access to a test system. Ask a "manager" to review each: Alice – Keep, Bob – Remove, Charlie – Keep.

🔮 Predict first

What should happen the moment the manager marks Bob's access "Remove"? Should it be immediate, or queued for a batch process?

Reveal the point of the exercise

Demonstrate Bob's access actually being removed as a direct result of the review decision, not just recorded somewhere. In a real IGA platform this triggers the same deprovisioning path as a Leaver event — a certification decision isn't just a compliance checkbox, it's a live access-control action.

Lab Lab 3 – Investigate an Orphan Account

🦡 Hands-on lab

Create employee David with an application account david@example.com. Terminate David in HR, but deliberately leave the application account enabled. Run reconciliation.

🔮 Predict first

What signal should reconciliation use to flag this account as a potential orphan?

Reveal the answer

Active account + no active, matching employee record = potential orphan. The reconciliation process should be comparing every application account back against the authoritative source (Lesson 2) and flagging any account whose "owner" no longer shows up there as active — exactly the check that would have caught David's leftover account.

Lesson Outcome

You should now be able to walk through the Joiner-Mover-Leaver model end to end, explain why Movers are often harder than Joiners, explain why disabling one directory account isn't the same as full offboarding, describe the lifecycle challenges specific to contractors/guests/service accounts/workload identities, and define Separation of Duties, orphan accounts, and dormant accounts. Lesson 5 zooms out to how all of this actually gets architected across a real, messy, multi-decade enterprise.