How joiner, mover, leaver, certification, and access-review workflows keep permissions aligned with real business need.
Access is not finished when a ticket is approved. People change jobs, contractors leave, systems get retired, data sensitivity changes, and emergency privileges linger. Identity governance exists because access that was reasonable once can become excessive later.
The durable access lifecycle is often called joiner, mover, leaver. It describes how access is granted when someone joins, changed when their role changes, and removed when access is no longer justified.
flowchart LR
J["Joiner: provision approved baseline"] --> M["Mover: adjust for role change"]
M --> R["Review: certify continuing need"]
R --> L["Leaver: remove access"]
L --> E["Evidence: prove completion"]
The model applies to humans, contractors, service accounts, API integrations, partner access, and privileged roles. Any identity that can act needs an owner and a removal path.
Strong provisioning starts from a defined business need:
Provisioning through managed groups or roles is usually easier to review than one-off personal exceptions.
Role changes create permission creep. A user moves from support to engineering, from engineering to management, or from one project to another. If old access remains while new access is added, the user accumulates rights no current job requires.
Mover controls include:
Many organizations fail more often on movers than leavers because movers remain legitimate employees.
Deprovisioning should remove or disable access across:
For contractors and partners, the planned end date should drive expiry. Waiting for someone to remember offboarding manually is weak lifecycle design.
| Review type | Purpose |
|---|---|
| Periodic certification | Managers or owners confirm continuing need. |
| Privileged access review | Elevated roles receive more frequent and stricter review. |
| Triggered review | Role change, incident, project close, or data reclassification triggers review. |
| Exception review | Temporary or policy-exception access expires or is re-approved. |
| Service-account review | Non-human identities retain an owner, purpose, and scoped permissions. |
Reviews are only useful if they can remove access. A rubber-stamp review with no owner accountability is theater.
Auditors and security teams need evidence that the lifecycle works:
This evidence helps both compliance and incident response. During an investigation, a clear lifecycle trail can explain why a principal had access at the time of an event.
| Trap | Corrective rule |
|---|---|
| “Access was approved once, so it remains valid forever.” | Access should follow current need and review cadence. |
| “Leaver deprovisioning is enough.” | Movers and temporary exceptions cause major permission drift. |
| “Service accounts do not need owners.” | Non-human identities still need ownership, purpose, and review. |
| “SSO automatically removes every app account.” | Only federated and lifecycle-integrated apps follow central deprovisioning reliably. |
| “Review means send a spreadsheet once a year.” | Reviews need accurate data, accountable owners, and removal workflow. |
An employee moved from finance operations to cloud engineering six months ago. They received new deployment rights, but still retain access to payroll exports. Which process failure is most directly shown?
A. Authentication strength
B. Mover access review and deprovisioning
C. DNS routing
D. Backup retention
Best answer: B. The user changed roles and accumulated access from the old role. The failure is lifecycle governance around movers and stale entitlements.