Identity Lifecycle Management: From Hire to Retire

Offboarding is where most organizations have the largest gaps. More than a third of former employees still had access to company files on personal devices. The gap between "HR notified IT" and "access actually revoked" is where risk accumulates. How long is that delay in your organization? Have you tested it?

Deprovisioning timeline must be explicit. When does access get disabled: end of day on the last day, immediately upon termination, or "when someone remembers"? Best practice is immediate disablement upon termination notification. The process should be: receive termination notice from HR, disable identity account and revoke sessions, disable VPN and remote access, revoke privileged roles, close SaaS accounts including direct logins and API tokens, rotate shared credentials, transfer data ownership, and document completion.

Data retention and legal hold require advance planning. What happens to their mailbox, files, and project folders? Who inherits ownership, and for how long? If there's a legal hold, what data needs to be preserved, and who's responsible for ensuring it isn't deleted? Without a data handoff process, critical business information gets lost, or worse, remains accessible only to someone who no longer works there.

The offboarding checklist should capture evidence at each step. Ticket ID, timestamp, who performed each action, confirmation from each system owner. This isn't paperwork for its own sake. It's the record you need when an auditor asks, "How do you handle departing employees?" or when an incident investigation traces back to an orphaned account.

Testing is essential. Have you actually run through the full offboarding process end-to-end? Does access get revoked as fast as you think it does? Are there SaaS apps IT doesn't know about? Do API tokens survive SSO disablement? The only way to know is to test with a real departure (or a controlled simulation).

Post-departure risk is what happens after offboarding "completes." Orphaned accounts survive when someone disables the main identity but misses app-specific accounts, API tokens, or direct logins. Dormant accounts survive when someone leaves but their account is never disabled. Both create breach paths that attackers actively exploit.

Credential abuse initiates 22% of all breaches (Verizon DBIR 2025). The delay between deactivating a user and them no longer being a risk is your exposure window. If that delay is hours, you're in good shape. If it's days or weeks, you have a problem. Measure your actual delay: time from HR termination notice to last successful authentication. If you can't measure it, you can't improve it.

What happens to their data after departure? Email forwarding rules that auto-forward to personal accounts. Shared drives with their personal folders still accessible. Project management tools where they own critical tasks. GitHub repos where they're the only admin. These data residues create ongoing risk and operational drag. A working post-departure process identifies and remediates these residues within a defined timeframe.

Dormant account detection should run continuously. 38% of all accounts are dormant (Veza 2025). Flag accounts that haven't authenticated in 30, 60, 90 days. Investigate: is this person still employed, is this a service account, should this account be disabled? Without continuous detection, dormant accounts accumulate until an audit forces a painful, rushed cleanup.

The hard question: what happens when offboarding breaks? Who gets paged? What's the escalation path? If someone discovers a former employee still has access, who fixes it, and how fast? Without an incident response path for lifecycle failures, you rely on heroics and luck. With a path, you have a chance of containing the risk before it becomes a breach.

Identity lifecycle fails when accountability is ambiguous. The hard questions need explicit answers: Who approves permissions? Who creates new users? Do all applications support provisioning, and what's the manual fallback? Who manages and approves license counts? How do we forecast costs? How do we deprovision users, and what do we do with their data? Do we know what happens to their data? Have we tested all of this?

A working accountability model assigns owners to each lifecycle stage. HR owns the trigger (hire/role change/termination notices). IT owns execution (account creation, permission changes, deprovisioning). Department managers own role-based access approvals. Security or compliance owns access reviews and evidence retention. The model should be documented, visible, and reviewed quarterly.

Application provisioning gaps require explicit handling. Not all applications support SCIM or API-based provisioning. For each application, document: does it support automated provisioning, does it support automated deprovisioning, what's the manual process if automation isn't available, who owns that manual process, and what's the SLA for completion? Without this inventory, you assume applications are covered until an audit or incident proves otherwise.

Testing and validation are non-negotiable. Have you tested the full lifecycle end-to-end? Do you know what happens to data after departure? Have you measured the actual delay between deactivation and risk elimination? Without testing, you're operating on assumptions. With testing, you have data to drive improvements.