Who should own SaaS offboarding when users change roles or leave?

Why This Matters for Security Teams

saas offboarding is not just an HR event. It is an access-removal control that has to cover human accounts, delegated admin rights, service accounts, API keys, OAuth grants, and any shadow access hidden inside the application. NIST’s NIST Cybersecurity Framework 2.0 treats identity governance as an operational discipline, not a one-time checklist, because stale access quickly becomes an exposure path.

The practical risk is simple: if the process ends at account disablement, the SaaS tenant may still contain active tokens, linked integrations, or secondary accounts that continue to work after the employee leaves. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why lifecycle control must include full revocation, not just user deprovisioning. The same problem appears in the Top 10 NHI Issues, where offboarding failures often leave identities valid long after business ownership has changed.

In practice, many security teams encounter residual access only after a former employee’s SaaS token is used from an unexpected system, rather than through intentional offboarding verification.

How It Works in Practice

Ownership is usually split, but responsibility is not. IAM or security should define the offboarding standard, enforce the workflow, and verify that every identity type is removed. Business owners, system owners, and application administrators must confirm the access inventory is complete for their SaaS tools, because they are the only ones who can see app-specific entitlements, delegated permissions, and embedded integrations. The right model is a joint control: security runs the process; the business attests that nothing remains.

For SaaS environments, a complete offboarding workflow should include:

• Disable the primary user account and remove from groups, roles, and shared workspaces.
• Revoke OAuth grants, API keys, refresh tokens, app passwords, and device sessions.
• Transfer ownership of documents, workflows, dashboards, and automation jobs.
• Review admin consoles for hidden accounts, local accounts, and break-glass access.
• Validate downstream integrations such as SCIM, SSO, ticketing, and CI/CD connectors.

NHIMG research shows why this cannot be left to manual memory alone. In the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, lifecycle management is framed as continuous visibility, rotation, and revocation. That matters because SaaS offboarding often leaves machine credentials behind even when the human user is gone. The operational takeaway aligns with NIST CSF 2.0 and common identity governance practice: define the control owner, require application-level attestation, and track closure evidence for every offboarding ticket.

These controls tend to break down in federated SaaS estates because the SaaS owner, IAM team, and business approver each see only part of the entitlement picture.

Common Variations and Edge Cases

Tighter offboarding control often increases ticket volume and approval overhead, so organisations have to balance speed against completeness. That tradeoff becomes visible when users move laterally, not just when they leave, because role changes can require partial removal, replacement access, and preservation of shared business data.

Best practice is evolving for SaaS apps with embedded automation. Some platforms issue long-lived refresh tokens, create service accounts on behalf of users, or inherit permissions through shared resources. There is no universal standard for this yet, but current guidance suggests treating every SaaS integration as a separate identity surface. That means offboarding should not stop at directory sync. It should also validate whether the departing user created hidden access paths inside the application itself.

This is where NHIMG’s research is especially useful. The The 2025 State of NHIs and Secrets in Cybersecurity report highlights how often former employee tokens remain active after offboarding, which is a strong signal that business confirmation alone is not enough. In high-risk SaaS apps, security should require a second-pass review for privileged roles, shared inboxes, admin-owned automations, and any account that is not tied cleanly to the directory. For teams that need a concrete example of how token exposure persists across real-world workflows, the Salesloft OAuth token breach illustrates why offboarding must include token revocation, not just account closure.

Related resources from NHI Mgmt Group

• Who should own SaaS licence revocation when employees leave or change roles?
• Who should own entitlement removal when roles change or staff leave?
• How should security teams handle SaaS offboarding when users also use AI tools?
• How should security teams handle NHIs when employees leave or change roles?