Why do organisations need to treat offboarding as a lifecycle control?

Why This Matters for Security Teams

Offboarding is not just an HR checklist. It is the point where identity, access, data ownership, and software subscriptions stop being aligned. If a departed employee still has active tokens, delegated access, shared mailbox permissions, or admin roles, the organisation may already be operating with a hidden control failure. That is why lifecycle discipline matters as much as initial provisioning, especially for service access and collaboration platforms.

The risk is larger than most teams expect because stale access often survives in multiple systems after the person has left the directory. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91% of former employee tokens remain active after offboarding in the 2025 Entro Security research. That combination turns departure events into a measurable exposure window rather than a routine admin task.

Security teams also underestimate ownership drift. Data retention, licence recovery, mailbox transfer, and delegated application access are often handled by different teams with different queues. The result is a fragmented release process that leaves secrets, permissions, and content behind long after the user exits. In practice, many security teams encounter the access problem only after an audit, an incident, or a former employee account review has already exposed it.

How It Works in Practice

Lifecycle-based offboarding treats departure as a coordinated revocation workflow, not a single disable action. The practical sequence is: confirm the exit event, identify all human and non-human access tied to that person, revoke interactive and programmatic access, transfer or delete owned data, and verify that licences and delegated permissions have been reclaimed. For Microsoft 365 environments, that means going beyond mailbox closure to include SharePoint ownership, Teams membership, OneDrive retention, app consents, and any linked automation that used the user’s identity.

This is where NHI governance overlaps with identity governance. The NHI Lifecycle Management Guide and the Top 10 NHI Issues both stress that secrets and service accounts need explicit ownership, expiry, and revocation paths. For human offboarding, the same logic applies to delegated tokens, refresh tokens, device trust, and any app registration the employee can still influence. OWASP Non-Human Identity Top 10 reinforces the need to track credential lifecycle, not just account lifecycle.

• Disable interactive sign-in first, then revoke active sessions and refresh tokens.
• Remove group membership, role assignments, and delegated application permissions.
• Transfer ownership of mailboxes, files, calendars, apps, and automation workflows.
• Rotate any secrets or certificates the user could have accessed or embedded.
• Confirm closure with logs, not assumptions, because stale entitlements can persist across synced systems.

Current guidance suggests the control should be measured by evidence of revocation, not by whether the directory object was disabled. These controls tend to break down in hybrid Microsoft 365 and SaaS-heavy environments because identity changes do not propagate cleanly across every application, vault, and token issuer.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid revocation against business continuity for shared services and critical automations. That tradeoff is real when a departing employee owns a mailbox used by a department, a Power Automate flow tied to a business process, or a service account that was never formally documented.

There is no universal standard for every edge case yet, but best practice is evolving toward ownership registries, short-lived access, and explicit break-glass procedures. For example, some organisations allow temporary retained access for legal hold or transition support, but that access should be time-bound, approved, and visible in audit logs. The same is true for contractor exits, where personal identities may be removed quickly but vendor-linked app access lingers much longer.

NHIMG’s research on secret sprawl is relevant here because offboarding frequently fails when credentials live outside the systems being deprovisioned. A user can leave, while tokens in code, config files, inboxes, and chat threads remain valid. That is why offboarding should be tested as a lifecycle control, not trusted as a one-time checklist item. Organisations with decentralised app ownership, unmanaged SaaS sprawl, or weak asset inventories are where this guidance most often falls apart.

Related resources from NHI Mgmt Group

• Should organisations use CSPM before focusing on NHI lifecycle controls?
• How do organisations make SaaS offboarding actually work?
• What is the difference between runtime protection and NHI lifecycle management?
• How can organisations reduce the risk of stale API keys and machine tokens?