Every employee is a set of access that has to appear on day one, change when they change roles, and disappear the moment they leave. Managing that arc across thousands of people and hundreds of systems is identity lifecycle management. Done badly it is how breaches happen and audits fail. This guide covers the whole lifecycle, the four moments that matter, and the live operator tools you can try on each.
Walkthroughs and audio breakdowns of the JML lifecycle. Media slots below are ready for embeds.
Identity lifecycle management is the practice of granting, changing, and revoking a person's access in step with their real relationship to the organization. It is usually described by its three lifecycle events, joiner, mover, and leaver (JML), plus the periodic review that proves the whole thing stayed honest: access certification.
The reason it is hard is not any single step. It is that access accumulates. People join and get access, change teams and get more, and leave without anyone taking it back. Left alone, every organization drifts toward a state where people hold far more access than their job needs and nobody can say why. That drift is exactly what an attacker exploits and an auditor flags.
| Event | Trigger | What changes | Common failure | The fix |
|---|---|---|---|---|
| Joiner | Hire recorded in the HR system of record | Birthright + role-based access granted | Too slow (ticket queues) or too much (account cloned from a peer) | Provision from a role, not a person, automatically |
| Mover | Team or role change | New access added, old access removed | New access granted, old access left behind (privilege accumulation) | Treat a transfer as add-new-and-remove-old in one operation |
| Leaver | Termination event | All access revoked everywhere | Orphaned accounts: valid logins with no valid owner | Automatic deprovisioning across every system, with evidence |
On hire, a person needs access, and they need the right access, not a copy of whatever the last person had. The two failure modes are opposite and both common: too slow (a new hire waits days on IT tickets) and too much (someone copies an existing account and the newcomer inherits years of accumulated permissions). The fix is to provision from a role, not a person: birthright access everyone gets, plus role-based access defined once and attached automatically, driven by the HR system of record.
When someone changes teams, almost everyone remembers to grant the new team's access. Almost no one removes the old team's. After two or three internal moves a person is carrying the permissions of three different jobs, a least-privilege violation created entirely by good news. Correct lifecycle management treats a transfer as add the new and remove the old, in one operation, so access always reflects the current role.
The single most common gap in access management is the leaver whose access was never fully removed. Onboarding gets done because the new hire complains; offboarding has no one pushing it, so leaver access rots for days or forever. Those orphaned accounts, still-valid logins with no valid owner, are a top breach path. Deprovisioning has to be an automatic reaction to the termination event, reaching every place access hides (identity, SaaS, privileged credentials, secrets, tokens), and it has to produce evidence that it happened.
An orphaned account is a valid login with no valid owner. Onboarding gets done because the new hire complains. Nobody complains for a leaver, so their access rots, and that is the door attackers walk through.
Deprovisioning operator surfaceEven with clean JML automation, access drifts, so frameworks like SOX, SOC 2, and ISO 27001 require periodic access reviews (also called certification or recertification): the owner of each system confirms, entitlement by entitlement, that each person still needs what they have, and revokes what they do not. Most teams do this in a spreadsheet an auditor has no reason to trust. Access certification software turns the review into a workflow whose output is tamper-evident, replayable evidence, which is what the audit is really asking for.
Access certification operator surfaceAccess certification is not a framework-specific feature, it is the control several frameworks all ask for in their own language. The mapping below shows where periodic access review and lifecycle deprovisioning align with common control references. This is a readiness aid, not an attestation, and no page or tool here makes a certified-or-compliant claim on your behalf.
CC6.1, CC6.2, CC6.3 for logical
access provisioning and least privilege, and CC6.5 for removing access on termination.A.5.15 access control, A.5.16 identity
management, A.5.18 access rights (the provisioning-to-deprovisioning arc), and A.8.2
privileged access rights.Hours from a termination event to full access removal, everywhere access hides.
Accounts with no valid current owner, still able to log in.
How far a person's actual access has diverged from their role. Rising drift is the copy-an-account anti-pattern in your data.
Share of entitlements actually certified, and how often reviewers revoke.
A rough model of how much leaver exposure your offboarding delay creates. It runs entirely in your browser, nothing is sent anywhere. Treat the output as an estimate from your inputs, not a measurement of your environment.
Turn this into a live workflow, not a diagram.
Try the JML tool