Every other article in this cluster covers how an identity authenticates — the credential, the factor, the protocol. This article covers something that gets far less attention but causes more real incidents: what happens to that identity over time, from the moment it's created to the moment it should stop working entirely. The single highest-risk moment in the whole lifecycle isn't a sophisticated attack — it's a departed employee whose access wasn't fully revoked.
The three stages: Joiner, Mover, Leaver
"Joiner-Mover-Leaver" (JML) is the standard framework for identity lifecycle events:
| Stage | What Happens | Primary Risk If Done Poorly |
|---|---|---|
| Joiner | A new employee, contractor, or vendor account is created and provisioned | Inconsistent access — some staff over-provisioned, others missing what they need |
| Mover | An existing identity changes role, department, or responsibility | Privilege creep — new access is added but old access tied to the previous role is never removed |
| Leaver | An identity's relationship with the organization ends | Access not fully revoked, leaving a departed identity with standing credentials |
Onboarding (Joiner)
Provisioning access ad hoc — granting whatever a new employee's manager happens to request over their first few days — produces inconsistent access levels between people in the same role and makes it hard to later confirm exactly what any given employee holds. The fix is a role-based access template: define, once per role, exactly which systems, applications, and permission levels that role requires, and provision consistently against that template on day one.
Onboarding speed matters operationally, not just for security
A new hire waiting days for access to basic systems because provisioning wasn't templated is a productivity cost, not just a security gap. Standardized, role-based provisioning improves both outcomes simultaneously — it's one of the rare cases where the secure approach and the convenient approach point the same direction.
Role changes (Mover)
A mover event is where privilege creep quietly accumulates. An employee promoted, transferred, or reassigned typically has new access granted for the new role — but the access tied to their previous role is frequently left in place, either because removing it wasn't part of the process or because nobody wanted to risk breaking something the employee might still need. Over years, this produces accounts with far broader access than the employee's current role actually requires, discovered (if ever) only during an access review or an incident investigation.
Every role change should trigger a full access review — not just an addition of new permissions, but an explicit removal decision for anything tied to the prior role that the new role doesn't also require.
Offboarding (Leaver) — the highest-risk stage
Delayed offboarding is one of the most frequently cited findings in security and compliance reviews, and one of the most avoidable. The core requirement is straightforward to state and consistently hard to execute reliably: access should be revoked the same day an employment or contractor relationship ends — not "within the week," not "next time IT does a cleanup pass."
| System/Access Type | Action Required |
|---|---|
| Identity provider account (Entra ID, Okta, etc.) | Disable immediately — this cascades to every SSO-connected application at once |
| Email and calendar | Convert to shared mailbox or set forwarding per policy; do not leave active |
| VPN / remote access | Revoke separately if not fully tied to the identity provider |
| Physical access (badges, keys) | Revoke in coordination with facilities/HR |
| Shared credentials the employee had access to | Rotate — the employee may have viewed or copied them |
| Federated/vendor application access | Confirm removal, since some applications maintain separate local accounts even under SSO |
| Company-owned devices | Recover and wipe per asset management process |
SSO helps, but doesn't automatically cover everything
Disabling the identity provider account revokes SSO-connected application access immediately — a major advantage of centralized identity (see Single Sign-On and Federation Explained). But applications with a local fallback account, or access granted outside the SSO relationship entirely (a shared login, a vendor portal with its own credentials), need separate, explicit revocation.
Access reviews
Beyond event-triggered reviews (a role change, an offboarding), a periodic access review — commonly quarterly or semi-annually — catches drift that individual lifecycle events miss: access granted for a since-completed project, a temporary elevation that was never rolled back, or an account that should have been caught by an offboarding process but wasn't. Access reviews are also a standard, explicitly expected control in most compliance frameworks (see below), making them both an operational and compliance necessity.
HR integration
The single most effective structural fix for offboarding delay is tying the offboarding trigger directly to HR's own termination process, rather than relying on IT being separately notified. When HR marks an employment end date in the system of record and that event automatically (or via a same-day required manual step) triggers identity deprovisioning, the process no longer depends on a person remembering to make a phone call. Organizations with HR and identity platforms that support direct integration (many HRIS platforms connect to Entra ID or similar) should use it; organizations without that integration need an equally reliable manual handoff procedure, tested periodically.
Compliance relevance
Identity lifecycle governance is directly and explicitly relevant to several compliance frameworks referenced elsewhere in this Knowledge Center:
- HIPAA — access authorization and management is a required Security Rule safeguard (45 CFR §164.308(a)(4)); see HIPAA Password Guidance for related authentication requirements.
- SOC 2 — access provisioning and deprovisioning controls are a standard element of the Security trust services criteria examined in a SOC 2 audit.
- PCI DSS — Requirement 8's unique-ID and access management provisions assume identity lifecycle discipline is in place; see PCI DSS Password Guidance.
An auditor reviewing any of these frameworks will typically ask for evidence — not just a policy statement — that offboarding happens promptly and access reviews actually occur on the stated schedule.
Microsoft Entra ID Governance
For organizations on Microsoft 365, Entra ID Governance (a licensed capability tier) provides platform-native tooling for several of the practices above: access reviews, entitlement management (packaging role-based access into requestable bundles), and lifecycle workflows that can automate provisioning and deprovisioning tied to HR events. Organizations without this license tier can still implement the same practices manually — the underlying discipline (templated provisioning, triggered reviews, same-day offboarding) matters more than the specific tooling used to enforce it.
Common mistakes
- No same-day offboarding trigger tied to HR — relying on IT being informed separately, which introduces delay and single points of failure.
- Role changes treated as pure addition rather than a full review including removal of prior-role access.
- No periodic access review, leaving drift (from completed projects, unrolled-back elevations) to accumulate indefinitely.
- Assuming SSO alone fully covers offboarding, missing local-fallback accounts and non-federated vendor access.
- Shared credentials not rotated after an offboarding event, leaving a departed employee's prior knowledge of a shared password still valid.
FAQ
How quickly should access actually be revoked after someone leaves? Same day is the standard expectation in most security and compliance reviews. Same-hour is achievable and preferable when the trigger is directly integrated with HR's termination process.
Do access reviews need to cover every single account every time? A full review of all accounts is ideal but not always practical at scale; risk-based sampling (focusing on privileged accounts and accounts with broad access first) is an acceptable practical approach if a full review isn't feasible on the desired cadence.
What's the difference between identity governance and access management generally? Access management covers granting and enforcing permissions at a point in time; identity governance covers the ongoing lifecycle discipline — provisioning templates, review cadence, and deprovisioning triggers — that keeps access management accurate over time rather than drifting.
Is a manual offboarding checklist good enough, or do we need automation? A well-documented, consistently followed manual checklist is a legitimate starting point and better than an ad hoc process. Automation (HR-triggered deprovisioning) reduces the risk of human error and delay, but the underlying checklist discipline matters more than the specific mechanism — automating an undefined process just makes the gaps automatic too.
Related reading
- Single Sign-On and Federation Explained
- Privileged Identity Management and Privileged Access
- HIPAA Password Guidance
- Governance vs. Compliance — the same accountability discipline applied at an organizational level
- SOC 2 Explained — access review evidence like this is a common SOC 2 control
- Microsoft 365 Copilot Readiness — stale permissions from weak lifecycle governance become active exposure once Copilot can surface them
- Download: Joiner-Mover-Leaver Template
- Download: Identity Governance Checklist
- Download: Identity Governance Review Worksheet
- Identity Governance Assessment tool