SaaS offboarding exposes the access revocation gap teams miss

At a glance

What this is: This article argues that SaaS offboarding is still the point where access control breaks down, because revoking identity at the SSO layer does not always remove application or session access.

Why it matters: It matters because IAM teams must govern human identities across SSO, SaaS entitlements, and session lifetime, or leavers can retain access long after deprovisioning.

By the numbers:

• Only 14% of the companies surveyed have systems and processes around SaaS deprovisioning while offboarding.
• 15 days even after access is revoked.

👉 Read Zluri's article on four ways to revoke SaaS access during offboarding

Context

SaaS offboarding is the process of removing a departing employee's access to applications, data, and sessions. In practice, the control problem is broader than disabling a login, because identity, application authorization, and active sessions can all drift apart during deprovisioning.

The article shows why human identity lifecycle management still fails when access is spread across SSO, direct app logins, and shadow IT. That makes offboarding a governance problem, not just an IT task, because incomplete revocation creates residual access after employment ends.

Key questions

Q: How should security teams handle SaaS access during employee offboarding?

A: Security teams should revoke access across the IdP, application layer, and active sessions, then confirm that no remaining permission paths exist. A clean offboarding process also transfers or preserves business data and checks audit logs for residual access. If revocation ends only at SSO, the employee may still have usable access.

Q: Why do SSO-based offboarding processes sometimes leave access behind?

A: SSO revocation removes one authentication path, but it does not always terminate existing SaaS sessions or remove app-specific entitlements. If the application keeps its own session alive, the former employee can continue using the tool after deprovisioning. That is why identity removal and session invalidation must both be part of offboarding.

Q: What breaks when SaaS inventories are maintained in spreadsheets?

A: Spreadsheets go stale quickly and cannot discover shadow IT, so the offboarding team ends up revoking access to only the known applications. That leaves unmanaged tools, personal sign-ups, and browser-based services outside the process. The result is partial revocation and higher residual access risk.

Q: Who is accountable when a former employee still has access after offboarding?

A: Accountability usually sits with IAM, IT, and application owners together, because offboarding failure is a cross-system governance issue. Directory admins may disable the account, but SaaS owners must also invalidate sessions and remove app access. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared control ownership.

Technical breakdown

Why SSO revocation does not always end app access

Single sign-on centralises authentication, but it does not own every application session. If an app maintains its own session cookie or token after the IdP link is removed, the user can continue operating until that session expires or is explicitly invalidated. That separation is common in SaaS environments and is why deprovisioning has to address both authentication and application-level authorisation. The failure mode is not that SSO is broken, but that it only removes one path to access while others remain active.

Practical implication: offboarding must include session invalidation and app-side revocation, not just IdP disablement.

Shadow IT and spreadsheet inventories create blind spots

Manual SaaS inventories and employee surveys cannot reliably capture every application in use, especially when staff adopt tools without approval. Spreadsheets also age quickly, so the offboarding team may revoke access to the known stack while missing unmanaged apps, browser-based tools, and personal accounts used for work. In identity governance terms, the record of where access exists becomes stale before the leaver process begins. That makes the control boundary incomplete and the revocation exercise inherently partial.

Practical implication: maintain continuously updated application discovery before relying on offboarding checklists.

Why offboarding automation changes the revocation workflow

Automated SaaS management platforms can connect identity, device, app permissions, and audit logs into one revocation workflow. The important technical shift is that deprovisioning is no longer a single action at the directory layer. It becomes a sequence that removes device authentication, transfers or preserves business data, deletes the user from the app, and confirms SSO removal. When those actions are coordinated, the organisation reduces the chance that a former employee still has a usable access path after departure.

Practical implication: design offboarding as a multi-step control chain with verification at each revocation point.

NHI Mgmt Group analysis

Offboarding failure is a lifecycle problem, not a point-in-time access problem. The article shows that revocation can be technically correct at the identity provider and still incomplete at the application layer. That is the core governance failure in human identity lifecycle management: access can outlive the event that should have ended it. Practitioners should treat leaver processing as a full entitlement closure workflow, not an account disablement task.

Session persistence is the hidden control gap in SaaS deprovisioning. Removing SSO access does not guarantee that the application session, cached token, or delegated permission dies with it. This is a classic assumption failure in modern IAM programmes, because many offboarding processes still assume authentication removal equals access removal. The practical conclusion is that revocation must be validated against actual session and app state.

Shadow IT turns offboarding into an incomplete inventory problem. If the organisation cannot see every app in use, it cannot revoke every app on exit. Manual spreadsheets and surveys do not scale to the real SaaS surface, which means the leaver process is only as strong as the asset discovery behind it. That leaves governance teams managing known identities while unknown applications continue to expose data.

Human lifecycle governance now depends on cross-system confirmation, not administrative intent. The strongest signal in this article is that offboarding has to prove revocation across directory, SaaS, device, and audit layers. That is the discipline IGA teams need to operationalise: every exit should end with evidence that access paths are closed, data ownership is reassigned, and residual sessions are gone. Practitioners should not accept ticket closure as proof of access closure.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For lifecycle governance, see NHI Lifecycle Management Guide for offboarding, rotation, and visibility controls.

What this signals

Human offboarding is becoming a control-verification exercise rather than an HR handoff. The article's real lesson is that revocation has to be provable across identity, application, and session layers before a leaver is considered closed. In programmes that still rely on directory disablement alone, the gap is structural, not procedural.

Session persistence is the best named concept to watch here. A disabled account is not the same thing as terminated access when SaaS sessions can survive for days. The practical programme change is to treat session invalidation, app permission removal, and inventory freshness as distinct controls rather than a single offboarding step.

The wider signal is that identity teams need stronger lifecycle evidence, not just more policy language. In our research, 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which is why offboarding, rotation, and revocation must be measured as outcomes, not intentions.

For practitioners

• Map every SaaS access path before deprovisioning Build a leaver checklist that includes SSO, direct app logins, device sessions, delegated access, and unmanaged tools so revocation does not stop at the IdP layer.
• Invalidate active sessions as a required exit step Require application-side session termination for critical SaaS tools, especially where token lifetime can outlast the employee's departure or the IdP disablement event.
• Replace spreadsheet inventories with continuous app discovery Use live discovery to keep the SaaS inventory current, because manual tracking cannot keep pace with shadow IT or fast-changing application adoption.
• Verify revocation with post-exit evidence Confirm that the former employee no longer appears in app permissions, audit logs, or access logs after deprovisioning is complete.
• Tie offboarding to ownership transfer and data retention Make data reassignment or archival part of the same workflow so the organisation does not trade access risk for business continuity risk.

Key takeaways

• SaaS offboarding fails when teams confuse SSO disablement with complete access revocation.
• Residual sessions, unmanaged apps, and stale inventories are the main reasons former employees keep access after exit.
• The control that matters is verified closure across identity, application, and session layers, not administrative intent alone.

Key terms

• SaaS Offboarding: SaaS offboarding is the process of removing a departing user's access to cloud applications, sessions, and related data. It goes beyond disabling a directory account and should include app-side revocation, ownership transfer, and verification that no residual access paths remain active.
• Session Persistence: Session persistence is the condition where an application login remains valid after the original identity source has been disabled. In IAM terms, it is a separate control plane from authentication, which means access can continue until the application session is explicitly invalidated or naturally expires.
• Shadow IT: Shadow IT is the use of applications or services without formal approval or visibility from central IT or security teams. It matters in offboarding because unmanaged tools are easy to miss, leaving former employees with unrevoked access that the official inventory never captured.
• Identity Lifecycle Management: Identity lifecycle management is the governance process that controls how identities are created, changed, reviewed, and removed across their usable life. For human users, it includes joiner, mover, and leaver controls, plus evidence that access has been fully closed when employment ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Automation 4 Ways of Revoking Access to Tools While Offboarding Employees. Read the original.