The account can remain active across SaaS tools, collaboration platforms and admin consoles after the endpoint leaves management. That leaves a former user or contractor with usable access even though the device appears to be removed from control.
Why un-enrolling the device does not end access
Device removal and account removal are different control actions. If offboarding only unenrols the endpoint, the identity that was using it can still authenticate from another browser, laptop, mobile device or remote session. That is why SaaS access, collaboration access and admin access can outlive endpoint management unless account deprovisioning and session invalidation happen as separate steps.
This is especially visible when the user signed into cloud apps with SSO or had tokens cached outside the device. Endpoint control may disappear while the account, refresh token, browser session or delegated access path still works.
Where the residual access usually sits
Residual access usually remains in the places that are not tied to a single managed endpoint: identity provider sessions, SaaS app sessions, API tokens, privileged console logins and shared administrative credentials. If the offboarding process only targets device management, those access paths can remain valid even after the hardware is wiped, returned or disabled from MDM.
In practice, this means the former user may still reach Joiner-Mover-Leaver (JML) Guide outcomes through another device unless deprovisioning also removes entitlements, revokes sessions and closes any indirect access routes. The same lifecycle gap is why IAM and IGA Basics treats provisioning and deprovisioning as distinct from endpoint control.
What good offboarding has to remove, not just the device
Effective offboarding must remove the account, not just the device. That means revoking active sessions, disabling or deleting the primary account where appropriate, rotating shared secrets, and removing any standing admin rights, API access or delegated credentials that were issued to the departing person.
The distinction matters because unmanaged residue is often broader than a single login. NHIMG’s NHI Lifecycle Management Guide shows the same pattern for lifecycle hygiene: if offboarding stops at the asset layer, access can survive in the control plane. A similar failure is discussed in Coupang Signing Key Breach, where credential exposure persisted after a lifecycle failure.
Risk and Threat Considerations
When offboarding only unenrols the device, the main risk is false closure. Teams may believe access is gone because the endpoint is no longer managed, while the real exposure remains in cloud sessions, browser tokens, federated logins, shared admin paths or long-lived credentials.
Failure mechanism: The control action removes device trust but leaves identity trust intact, so the former user can re-enter through any still-valid session, token, password, federated assertion or secondary device.
Impact: A departed employee or contractor can continue to access SaaS data, collaboration content or administrative functions, which increases data exposure, fraud potential and the chance of delayed detection after separation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Device-only offboarding leaves NHI access active after departure. |
| NHI-07 — Long-Lived Secrets | Residual access often survives through cached or persistent tokens. | |
| Recommendation — Revoke accounts, sessions and secrets together with device unenrolment. Shorten secret lifetimes and rotate any credential tied to the departed user. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke or rotate authenticators and tokens, not just devices. |
| AC-2 — Account Management | Account termination is the control that ends user access, not endpoint removal. | |
| AC-6 — Least Privilege | Standing access after departure violates privilege minimisation. | |
| Recommendation — Disable and rotate authenticators when a user leaves. Disable or remove accounts as part of offboarding. Remove unnecessary entitlements and privileged access at separation. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Separation depends on maintaining the assurance of who is still entitled to authenticate. |
| Recommendation — Verify that the authenticated identity is no longer entitled before accepting continued access. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed when employment or contract ends. |
| Recommendation — Revoke access rights promptly at offboarding. | ||
Practitioner Guidance
What to verify: Confirm that offboarding evidence includes account disablement or deletion, session revocation, token rotation where needed, and removal from privileged groups or shared access paths. Device unenrolment alone is only a hygiene step, not an access-ending step.
Decision rule: If the person had any cloud app access, privileged console access, or reusable secrets, treat device removal as incomplete until you can prove the remaining credentials and sessions are dead.
What good looks like: A completed offboarding record should show the endpoint removed from management, the user blocked from sign-in, active sessions invalidated, and any standing access reviewed for residual dependencies.
Practitioner takeaway: Offboarding is only effective when it closes the identity, session and entitlement paths that survive beyond the device; if those paths remain, the endpoint has been removed but the access problem has not.