Lakshya

Identity & Access · Chapter 3

The lifecycle — joiner, mover, leaver

The least fashionable part of identity and the source of the most real exposure.

Identity governance lives or dies on one asymmetry: granting access is easy, automated and welcomed, while removing it is manual, invisible and nobody's priority.

WHY ACCESS ONLY EVER GOES UP JOINERsupport deskMOVER 1+ billingMOVER 2+ financeLEAVERshould be zero WHAT THEY ACTUALLY HOLD 1233 — still Grants are automated. Revocations are a ticket somebody has to remember to file. Every move adds. Almost nothing subtracts. After three years an employee holds the union of every role they have ever had — which is called privilege creep, and is how one phished account reaches systems the attacker could never have guessed that person could touch. The control is not a better joiner process. It is time-bounded access and an honest review.
Access accumulates because only one direction is automated. A person who has moved twice holds the union of three roles, and the organisation has no single place where that is visible. This is why a phished account in support can reach finance systems.

Where each stage actually fails

StageThe real failureWhat to check
JoinerAccess copied from a colleague — “give them what Priya has”Are grants role-derived, or cloned from a person?
MoverThe old access is never removedDoes a role change trigger revocation, or only addition?
LeaverHR termination does not reach every systemTime from termination to last access revoked, measured
ContractorsNo HR record, so no lifecycle at allWho owns non-employee identities? Is there an end date?
Service accountsNo owner, no expiry, no reviewCan you name a human owner for each one?

The contractor and service-account rows are where audits find the worst material. Both sit outside the HR-driven process that the rest of the lifecycle depends on, so both accumulate silently and neither appears in the metrics anyone reports.

Why access reviews fail, and what to do instead

The standard control is a periodic access review: send managers a list, ask them to confirm. It fails predictably, because a manager facing 400 entitlements with cryptic technical names and a deadline will approve all of them. This is rubber-stamping, and a rubber-stamped review is worse than none because it produces evidence of a control that is not operating.

  • Review by exception — show what changed and what is unused, not the full list.
  • Lead with usage data. “These 40 entitlements have not been used in 180 days” is a decision a manager can actually make.
  • Make revocation the default for unused access, with a simple path to reclaim it.
  • Prefer time-bounded grants so access expires without anyone having to decide — which converts an unreliable human control into an automatic one.
← Federation, SSO, SAML and OIDCEntitlements, RBAC and ABAC →