They should revoke the application account, remove any role-based privileges, and verify that connected functions such as billing access are also withdrawn. Offboarding is only complete when the identity no longer has a path into the application or its sensitive actions. Partial removal still leaves the governance gap open.
What offboarding should remove in a SaaS-supported role
Offboarding has to be treated as full access removal, not just account closure. If the role used the SaaS application for approvals, billing, admin actions, or other sensitive functions, those privileges must be withdrawn alongside the user account. The practical question is whether any remaining path can still authenticate, authorize, or act inside the service after the person has left.
That matters because many SaaS platforms separate the login from the permissions attached to the account. A disabled login without role cleanup can still leave delegated access, shared access, or lingering entitlements behind. In other words, the person may no longer sign in directly, yet the business function they used can remain available through another path.
For identity teams, the offboarding objective is simple: remove the identity, remove the entitlements, and remove the operational ability to perform sensitive actions. The lifecycle process for managing identities should end with no residual access path, including function-level access such as billing, support, or admin workflows.
Why partial removal still leaves a governance gap
Partial deprovisioning creates an ownership problem as much as a security problem. If an ex-employee still has a role assignment, a group membership, an API token, or a delegated function in the SaaS app, the organisation has not really completed revocation. The application may look clean at the directory layer while the service layer still permits action.
That gap becomes more serious when the SaaS system exposes sensitive business functions. Billing access can allow payment changes, invoice edits, vendor communication, or contract actions. Administrative access can allow configuration changes, user management, data export, or role reassignment. Once those functions survive the departure event, the organisation has an access-control weakness that is easy to miss in standard joiner-mover-leaver workflows.
The control expectation is therefore broader than account disablement. Offboarding must cover the application account, any role-based privileges, and any function-specific permissions that may live outside the main user record. The same principle is reflected in the Identity Security Programme Guide, which treats access governance as an operating model issue rather than a one-time ticket.
What good IAM teams verify before closing the case
A correct offboarding process should end with verification, not assumption. The team should confirm that the user can no longer sign in, no longer holds active application roles, and no longer has access to any connected workflow that can change money, data, or configuration. If the SaaS product uses delegated administration, automation, or shared operational roles, those paths need the same review.
Verification should also include the adjacent controls around the application. The strongest teams check whether the deprovisioning action propagated to the SaaS tenant, whether any cached sessions were terminated, and whether privileged groups or entitlement bundles were actually removed. Where the platform supports it, this is the point to confirm with audit logs that the account cannot still perform sensitive actions.
For broader operational guidance, the IAM and Identity Provider Buyer’s Guide is useful because it frames lifecycle control as a capability teams should evaluate, not just a help desk process. In SaaS offboarding, the standard is not whether the ticket was closed, but whether the application no longer recognises the former employee as an actor with authority.
Risk and Threat Considerations
Residual SaaS access after departure creates a straightforward exposure path: the former employee, or anyone who can use their still-active access, may retain the ability to view data, modify settings, or approve actions. If the remaining permission set includes billing or administrative functions, the risk is not only unauthorized access but also unauthorized business action.
Failure mechanism: The most common breakdown is incomplete deprovisioning, where the human account is removed but roles, entitlements, sessions, or connected functions survive in the application.
Impact: That can preserve a live path into sensitive SaaS functions, delay detection of misuse, and leave the organisation unable to prove that access was fully revoked after offboarding.
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 sets 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 requires revoking credentials, sessions, and other authenticators. |
| AC-2 — Account Management | Employee exit is an account lifecycle event that must remove application access. | |
| AC-6 — Least Privilege | Residual role access after departure is an excessive-permission problem. | |
| Recommendation — Revoke and expire authenticators when a user leaves, including any app-specific credentials. Disable or remove the account and associated access as part of offboarding. Remove unused roles and entitlements so no post-exit privileges remain. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | SaaS offboarding depends on governing identities across their lifecycle. |
| A.5.18 — Access rights | Access rights must be removed when the role ends, including application permissions. | |
| Recommendation — Ensure identity records and lifecycle states are updated when employment ends. Withdraw access rights promptly and verify that permissions are removed in the SaaS service. | ||
Practitioner Guidance
What to prioritise: Treat SaaS offboarding as a control closure event for the application, not just for the directory account. The highest-priority check is whether the former employee can still reach any privileged or business-sensitive function through roles, delegated access, or linked workflows.
What to verify: Require evidence that the application account, role assignments, and connected privileges were removed, and that the SaaS tenant no longer accepts the user for sensitive actions. If the platform cannot produce that evidence, treat the case as incomplete.
Practitioner takeaway: A clean offboarding is one where the former employee has no remaining authority inside the SaaS application, even if a username, record, or historical access trail still exists.
Related resources from NHI Mgmt Group
- How should security teams handle cloud and SaaS data exposure when employees or developers leave sensitive information in public places such as repositories, chat tools, or exposed databases?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How can IAM teams reduce the blast radius of a compromised SaaS identity?
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?