Joiners, Movers, Leavers: The Identity Lifecycle Gap

Every identity has a life: it is created when someone joins, changed as they move between roles, and — in theory — removed when they leave. The security of an organisation depends heavily on the move and leave stages, and those are exactly the two that get neglected, because a failure there hurts no one who could complain. A new hire without access files a ticket in an hour. A leaver with lingering access says nothing, because they are gone.

The joiner-mover-leaver model is not new, but its failure surface has grown enormously. An identity today is not one account. It is a directory identity, a dozen SaaS logins provisioned by different teams, a VPN certificate, API tokens, membership in chat workspaces and shared drives, and often a personal device holding cached credentials. 'Deprovision the leaver' now means unwinding a graph, not deleting a row — and the parts provisioned outside the central directory are the parts that get missed. Every SaaS tool a team adopted on its own corporate card is a small identity store your central offboarding process has never heard of.

The mover problem: access that only ever grows

When someone changes roles, the new access gets provisioned promptly — they need it to work. The old access is supposed to be removed, and almost never is, because removing it requires someone to know what it was and to bother. Over a career of internal moves, a long-tenured employee accumulates the union of every role they have ever held. This is privilege accumulation, and it produces the most dangerous insider profile in the building: a trusted, legitimate identity that can touch nearly everything, entirely by accident of history.

Closing the gaps

• Make HR the trigger, not a ticket. Joiner, mover and leaver events should flow from the authoritative HR record into provisioning automatically — a departure in HR should start deprovisioning without a human remembering to file it.
• Provision through a governed layer. Access granted via SCIM or a governance platform can be revoked centrally; access granted by a team admin clicking around a SaaS console cannot, and that is what survives.
• Recertify on move, not just annually. A role change is the natural moment to ask 'does this person still need the old access?' — make the mover event force that review.
• Reconcile continuously. Periodically compare live accounts against the HR roster. Accounts with no matching active employee are orphans — investigate every one.
• Kill the session, not just the account. Disabling an account does nothing to an active token or session; revoke sessions and rotate secrets the identity could have cached.

The leaver you can measure

The single most useful metric here is the gap between a departure timestamp in HR and the moment the identity's access is fully gone across every system. In neglected environments that number is measured in months, and sometimes the access never dies. Shrinking it to hours — and being able to prove it — is the difference between a controlled lifecycle and a graveyard of live credentials.

Orphaned and over-accumulated identities are, definitionally, the ones no one is looking at. Finding them is a discovery exercise before it is a cleanup one — you can't revoke access you never knew was granted.