Best practice is to make offboarding a single governed workflow that revokes cloud access, locks or retires the device, and closes any remaining account state. Teams should test the full leaver path, not just individual steps, because partial offboarding leaves residual access in place.
Why secure offboarding has to cover devices and SaaS together
Offboarding fails when teams treat device return, account disablement, and session revocation as separate tasks owned by different systems. The practical goal is to remove the person’s ability to authenticate, keep using cached sessions, or recover access through secondary routes after departure. That means the workflow must cover endpoint state, cloud entitlements, and any residual credentials or tokens in one coordinated process.
In a modern environment, the same leaver can still reach data through a laptop profile, a browser session, a synced password manager, or a SaaS app that was never fully deprovisioned. Secure offboarding therefore depends on both Joiner-Mover-Leaver (JML) Guide style workflow design and IAM and IGA Basics discipline, because entitlement removal and access review only work if the process is driven by an authoritative leaver event.
The offboarding sequence also needs to reflect how access is actually used. A device can be locked, but if SaaS sessions, API tokens, delegated app access, or shared accounts remain active, the user can still operate indirectly. For that reason, a complete leaver path should terminate access at the identity layer, then confirm that the device has been isolated, retired, or remotely wiped according to policy. The most useful internal checklist is one that spans Workforce Identity Security Guide controls and lifecycle cleanup, not one that treats endpoint and application offboarding as unrelated workstreams.
What good offboarding looks like in practice
Good offboarding starts with a single trigger, usually HR or contractor termination, and then propagates to every place that can confer access. That includes SSO, SaaS app accounts, privileged tools, endpoint management, collaboration platforms, and any recovery paths that could restore the account later. If the organisation cannot show where the leaver’s access existed, it cannot reliably prove that removal was complete.
On the device side, the decision point is whether the asset is corporate-managed, personally owned, or shared. Corporate-managed devices should be locked, escrowed if needed, and then wiped or reimaged once evidence is preserved. Personally owned or BYOD devices need a different treatment, usually removal of corporate profile, certificates, containers, and managed app data rather than a full wipe. The right control is the one that removes access without overreaching beyond ownership and policy boundaries.
On the SaaS side, the most common failure is assuming that disabling the primary login is enough. In reality, the leaver may still have active refresh tokens, connected apps, mailbox delegation, role assignments, or residual group membership. A strong offboarding standard includes verification that app-specific access has been revoked, not just that the directory account is disabled. That is why lifecycle guidance such as Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is useful here, because the same offboarding discipline applies to credential-bearing accounts and delegated access paths that outlive the original user context.
Where offboarding breaks, and how to catch it early
The biggest failure mode is partial deprovisioning. Teams close the directory account, but they do not revoke app grants, remote access, local admin rights, or device trust relationships. Another common issue is delayed execution, where the termination event is known but the actual revocation happens hours or days later, creating a window for post-departure access. A third problem is stale inventory, where no one can tell which devices, apps, or tokens were attached to the person in the first place.
These gaps matter because an exited user often still has the strongest legitimate path into systems and data. If they were a power user, contractor admin, or support operator, the blast radius can be wider than the directory record suggests. Offboarding should therefore be tested end to end, including a login attempt after termination, device access checks, SaaS permission validation, and confirmation that recovery mechanisms cannot resurrect the account without governance review. The case for complete offboarding is reinforced by Top 10 NHI Issues, especially the patterns around excessive permissions, stale access, and lifecycle drift that appear when removal is only partial.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke credentials, tokens, and recovery paths tied to the leaver. |
| AC-2 — Account Management | Leaver processing is fundamentally account disablement, termination, and reconciliation across systems. | |
| IA-9 — Service Identification and Authentication | SaaS and device-connected integrations often rely on non-human credentials that can survive offboarding. | |
| Recommendation — Revoke or disable authenticators and rotate any shared secrets tied to the departing user. Disable, remove, and reconcile accounts promptly across directories and SaaS apps. Revoke service and application credentials that could preserve access after user departure. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secure offboarding depends on timely removal of user and application access. |
| Recommendation — Automate account deprovisioning and verify that access removal completes everywhere. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Offboarding requires removal and review of access rights when employment or role ends. |
| Recommendation — Revoke access rights immediately on termination and confirm residual privileges are removed. | ||
Practitioner Guidance
What to verify: Confirm that the leaver event reaches every authority that can still grant access, including directory, SaaS admin, endpoint management, and any identity recovery process. If one control plane is manual, it becomes the most likely gap.
Implementation sequence: Disable interactive access first, revoke active sessions and tokens next, then retire or wipe managed devices, and finally reconcile app memberships and residual entitlements. The order matters because device and app access can persist through different technical paths.
Common mistake: Treating account disablement as completion. The real test is whether the former user can still open a session, recover an account, or use a managed device to reach corporate resources after offboarding is declared finished.
Practitioner takeaway: The best offboarding programmes are measured by what the former user can no longer do, not by which task was marked complete. If access removal is not verified across identity, device, and SaaS state, the organisation has only paused the account, not closed it.
Related resources from NHI Mgmt Group
- How should MSPs centralise identity governance across users, devices, and SaaS apps?
- Who should be accountable for governing access across SaaS apps, devices, and AI workflows?
- How should security teams automate SaaS user offboarding at scale across shadow apps and dormant accounts?
- How should security teams secure productivity agents that can read email and act across SaaS apps?