When offboarding is incomplete, former employees can retain active accounts, linked integrations, and access to shared data long after departure. That creates unnecessary exposure, complicates investigations, and can leave business records reachable by people who no longer need them. The risk grows when access is spread across many SaaS apps with no central reconciliation.
Why SaaS Offboarding Gaps Become a Security Problem
When an employee leaves, the real issue is not just the badge or laptop. SaaS access often includes direct logins, delegated access, OAuth grants, shared folders, app-specific roles, and connected workflows that survive long after HR separation is complete. If those entitlements are not fully removed, the former employee may still reach records, billing data, customer information, or internal collaboration spaces that no longer need to be visible to them.
This matters because SaaS environments are usually fragmented. One person can have access spread across dozens of applications, each with its own admin console and export path, so a partial revoke can look successful while useful access still remains. The weakness is not always malicious intent; it is persistent trust in an account that is no longer governed. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful signal for how often residual access is missed in practice.
In practice, many security teams only discover the gap after an audit, an incident review, or a data request reveals that a departed user still had live access somewhere in the SaaS stack.
How Incomplete Offboarding Works in Practice
Incomplete SaaS offboarding usually fails in layers rather than all at once. An account may be disabled in the primary directory, but the same user can still retain access through local SaaS credentials, invited guest status, shared mailbox delegation, group membership, or a token that authorises an integration on their behalf. In some platforms, removing the user does not automatically remove exported data, linked apps, or admin-approved connections created during employment.
The operational problem is that entitlement review and identity revocation are not always the same control. A team may confirm that an HR record closed, yet never reconcile which applications trust that person directly, which apps trust a token they created, and which collaboration spaces expose business records to former members. This is where central visibility matters. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, and the same visibility gap affects human offboarding when SaaS permissions are distributed across many systems. The OWASP Non-Human Identity Top 10 is useful here because it highlights the governance problem around lingering machine access and stale trust relationships.
- Disable the primary account, then verify that app-local accounts and SSO-linked sessions are also removed.
- Revoke OAuth grants, API keys, service tokens, and delegated mailbox or workspace access.
- Check shared folders, project spaces, and admin groups for residual membership.
- Confirm that integrations created by the user are either transferred or deauthorised.
For teams that need a broader control baseline, the NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant for access revocation, account management, and auditability. These controls tend to break down when SaaS admin rights are decentralised, because no single team can prove that every downstream permission has been removed.
Common Variations and Edge Cases
Tighter offboarding often increases administrative overhead, so organisations have to balance speed against completeness. That tradeoff becomes sharper when workers use SaaS tools outside the core IT directory, because the offboarding process must catch subscriptions, guest links, and team-owned integrations that are easy to overlook.
Contractors and temporary staff often create the most confusion. Their access may be provisioned outside standard employee workflows, or it may be tied to shared project spaces rather than a named enterprise directory. Best practice is evolving here, but current guidance suggests treating every externally managed SaaS grant as a separate revocation item, not as a byproduct of standard account closure. Another edge case is data persistence: even if the login is removed, cached exports, synced files, and copied records may still exist in shared systems, so access removal does not always equal data removal.
NHIMG research on the Ultimate Guide to NHIs is especially useful when SaaS offboarding also touches tokens, shared automation, or service accounts tied to the former employee’s work. Only 5.7% of organisations have full visibility into their service accounts, which shows why offboarding frequently fails once the access path is no longer a simple username and password problem.
Risk and Threat Considerations
Incomplete SaaS offboarding creates residual access risk, data exposure risk, and accountability risk. A departed employee with still-active access can reach content that should no longer be available, and if that access was tied to integrations or shared workspaces, the exposure can extend beyond a single account into broader business systems.
Failure mechanism: The control fails when identity deprovisioning is treated as a single event instead of a full entitlement reconciliation. Residual SaaS grants, OAuth tokens, delegated access, guest memberships, and shared resources remain valid because they are not centrally inventoried or individually revoked.
Impact: Sensitive records may remain reachable, investigations become harder because access trails are fragmented, and the organisation may keep trusting a person who no longer has a business need to see or modify data.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Residual SaaS access often persists through untracked identities and grants. |
| NHI-03 — Secrets and Credential Management | Offboarding must revoke tokens, keys, and delegated credentials, not just logins. | |
| Recommendation — Inventory every SaaS-linked identity and assign clear ownership for revocation. Revoke all user-issued tokens, keys, and app credentials during offboarding. | ||
| CIS Controls v8 | 5 — Account Management | Departed users must be disabled and removed from every active account path. |
| 6 — Access Control Management | SaaS access persists when permissions, groups, and shared resources are not reviewed. | |
| Recommendation — Remove or disable all accounts and access paths when employment ends. Review and revoke inherited permissions, groups, and shared-access entitlements. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Offboarding is an identity and access governance failure when access is not withdrawn. |
| Recommendation — Enforce timely access removal and verify termination of all authorised access. | ||
Practitioner Guidance
What to prioritise: Treat offboarding as a full access reconciliation exercise, not a checkbox tied to HR separation. The first priority is to identify every SaaS application, delegated permission, and integration that still recognises the departing user.
What to verify: Confirm revocation by checking the SaaS admin layer, not just the identity provider. A clean directory record is not enough if the user still has app-local access, retained tokens, or workspace membership in a downstream system.
Decision rule: If the account can still read, export, approve, or delegate in any business system, treat the offboarding as incomplete and escalate it before closing the case.
Practitioner takeaway: The real control objective is not account deletion alone; it is proving that no remaining path exists for a former employee to access business data, integrations, or shared SaaS trust relationships.
Related resources from NHI Mgmt Group
- What happens when risky SaaS access is revoked without fully offboarding the user?
- What happens when terminated employee access is not removed promptly?
- What happens when technical staff leave and privileged infrastructure access is not fully revoked?
- Why does revoking access to shared passwords still leave residual risk?