Employee offboarding exposes the limits of SSO deprovisioning

At a glance

What this is: This is a Zluri case study showing that employee offboarding becomes a security and data-retention problem when SSO sessions, app-specific access, and data handoff are not fully removed.

Why it matters: It matters because IAM, IGA, and SaaS operations teams need offboarding controls that terminate access across applications, preserve company data, and reduce the chance of post-exit misuse.

By the numbers:

• 76% of executives agreed that employee offboarding represents a significant security threat.
• 58% of executives reported that offboarding processes have changed because of COVID-19 and an enforced remote workforce.
• 67% of executives believe that employees exiting the organization are more likely to cause security breaches by accident than intentionally.

👉 Read Zluri's case study on employee offboarding and SaaS deprovisioning

Context

Employee offboarding is the point where identity governance, SaaS access, and data ownership converge. In remote and hybrid environments, the risk is not just removing a user from a directory, but making sure every application session, license, and data copy is properly closed out.

The problem is familiar to IAM and IGA teams: SSO can simplify access, but it also creates a session layer that may outlive the offboarding event. Once the user is authenticated, application access can continue until that session expires or is explicitly revoked, which is why deprovisioning has to extend beyond the identity provider.

Key questions

Q: What breaks when offboarding only disables the SSO account?

A: A disabled SSO account can still leave active application sessions, cached tokens, and application-owned data in place. That means the former employee may continue to access SaaS tools or leave behind information the business still needs. Effective offboarding must remove access, verify termination, and preserve company data before the case is closed.

Q: Why do offboarding workflows need more than HR approval?

A: HR confirms the employment change, but it does not automatically close every access path. IAM, IT, and application owners must remove entitlements, revoke sessions, reclaim licenses, and transfer data ownership. Without those steps, the organization can keep an ex-employee partly connected to business systems after departure.

Q: How do security teams know if deprovisioning actually worked?

A: They should check application sign-in logs, audit logs, and access logs after the offboarding event. If there is any post-exit activity, residual access still exists somewhere in the SaaS stack. Evidence, not the disablement ticket alone, is what proves the lifecycle step succeeded.

Q: Who should own access and data cleanup during employee offboarding?

A: Ownership should be shared across HR, IT, IAM, and the application business owner, because each controls a different part of the exit. HR confirms the departure, IT and IAM remove access, and the business owner confirms data transfer or retention. Clear ownership prevents gaps between systems.

Technical breakdown

Why SSO sessions outlive offboarding decisions

Single sign-on centralises authentication, but it does not guarantee immediate termination of every active application session. If an app accepts existing tokens or cached sessions, the user may continue to operate even after central access is removed. That is the core limitation in offboarding: identity revocation at the source does not always propagate fast enough to every downstream SaaS service. In practice, the gap widens when app-specific sessions, mobile clients, and long-lived browser sessions are not individually invalidated.

Practical implication: verify that offboarding runbooks explicitly revoke active sessions, not just disable the user in the identity provider.

Deprovisioning across SaaS apps and licenses

Deprovisioning is the coordinated removal of access, entitlements, and application ownership across multiple systems. In a SaaS-heavy environment, that means the identity team needs visibility into which apps the employee used, what permissions were granted, and whether the account is linked to shared workflows or business data. The hard part is that offboarding is not only about access removal. It also involves preserving data, transferring ownership, and removing the former employee from licenses without breaking business continuity.

Practical implication: map every offboarding step to a specific SaaS owner, data handoff requirement, and entitlement removal action.

Why app-level logs matter during offboarding

Identity providers often show that a user was disabled, but they do not always show what happened inside each application before or after deprovisioning. Sign-in logs, audit logs, and access logs are what prove whether access was actually terminated and whether any residual activity continued. That makes application telemetry essential for offboarding assurance. Without it, teams can assume a clean exit while the application layer still contains active sessions, orphaned data, or retained privileges.

Practical implication: require app-level evidence of revocation and post-offboarding activity checks before closing the case.

Threat narrative

Attacker objective: The objective is to retain access long enough to read, copy, or misuse company data after employment has ended.

1. Entry occurs through a still-valid SSO session or application session that was not terminated when the employee left.
2. Credential or access abuse follows when the former user continues to use retained app permissions, cached sessions, or incomplete deprovisioning.
3. Impact appears as unauthorized access to company data, delayed license reclamation, or loss of control over business-owned information.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Offboarding exposed a governance gap, not just a workflow gap. The article shows that removing a user from SSO is not the same as removing their ability to act across the SaaS estate. Session persistence, app-level entitlements, and data ownership transfer all sit outside a simple directory-disable event. The practitioner lesson is that offboarding must be governed as a cross-application identity closure process, not an HR checklist.

Standing application access after employment is a lifecycle failure mode. When sessions remain active for days or months, the issue is no longer an isolated delay in deprovisioning. It becomes a persistence problem across the identity lifecycle, where access outlives the business relationship that justified it. That makes offboarding controls a core part of identity governance, not an administrative afterthought.

Residual data ownership is the hidden risk in SaaS offboarding. The article correctly points out that account removal alone can strand company data in the wrong place. Once an employee leaves, the organization still has to preserve, transfer, or back up data tied to their account. The implication is that access governance and data governance are inseparable during leaver processing.

Visibility into app activity is what turns offboarding from assumption to evidence. Monitoring access logs, audit logs, and sign-in logs is the only way to verify that the deprovisioning action actually changed the state of the application layer. That makes evidence collection a governance control, not just an operational convenience. Teams that cannot prove revocation have not fully completed offboarding.

Identity closure needs to follow the business relationship, not the authentication event. The article reflects a common enterprise pattern where identity teams treat account disablement as the end state. In reality, the end state is when the former user can no longer authenticate, authorize, or retain company data anywhere relevant. Practitioners should treat offboarding as complete only when access, data, and ownership are all reconciled.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For a broader lifecycle view, see NHI Lifecycle Management Guide for provisioning, rotation, offboarding, and visibility controls.

What this signals

Identity teams should treat leaver processing as a lifecycle closure problem, not a ticket to close. The next maturity step is proving that every exit removes access, ownership, and residual activity across the SaaS estate. That means offboarding evidence must become part of access governance reporting, not an after-the-fact audit scramble.

The practical signal is that application telemetry will matter more than directory state. If a platform cannot show who had access, when it was removed, and whether any session persisted, the organization is still operating on assumption rather than control.

Residual access debt: this is the accumulating gap between employment termination and complete SaaS access removal, and it becomes visible only when IAM, HR, and application logs are correlated. Teams should expect this to become a recurring governance metric in mature identity programmes.

For practitioners

• Build a SaaS offboarding checklist that spans identity, license, and data handoff Define the exact steps for disabling access, removing licenses, preserving business data, and transferring account-owned content to a named owner before the leaver process closes.
• Require proof of session termination after deprovisioning Do not rely on directory disablement alone. Confirm that active SSO sessions, application sessions, and device-authenticated access have been revoked across the core SaaS stack.
• Tie offboarding to application audit evidence Use sign-in logs, audit logs, and access logs to verify that the account stopped acting in each application after the offboarding event and that no residual activity remains.
• Separate data preservation from access removal Make sure each leaver workflow includes a data backup or transfer step so that business records are retained even when the former employee’s account is removed.

Key takeaways

• The article shows that offboarding risk persists when session termination, license removal, and data transfer are treated as separate tasks instead of one lifecycle event.
• Zluri’s survey data points to a broad governance problem, with 76% of executives calling offboarding a significant security threat and 58% saying the process became harder during COVID-19.
• The control that changes the outcome is not just SSO disablement but end-to-end deprovisioning evidence across applications, logs, and data ownership.

Key terms

• Deprovisioning: Deprovisioning is the process of removing a user’s access, entitlements, and related accounts when they leave or change roles. In SaaS-heavy environments, it must also account for session termination, license recovery, and ownership transfer so the business does not retain hidden access paths.
• Offboarding: Offboarding is the broader leaver process that manages an employee’s exit across HR, IT, security, and application ownership. It includes access removal, data handoff, device return, and audit evidence, making it an identity lifecycle control rather than a pure HR workflow.
• SSO Session Persistence: SSO session persistence is the condition where a user’s authenticated session remains valid after a central account change. It matters in offboarding because disabling the identity provider account does not always end app-level access immediately, especially when tokens or cached sessions remain active.
• Residual Access: Residual access is any remaining ability to act in an application or dataset after the organisation believes access has been removed. It often appears when account disablement, app sessions, and data ownership are not reconciled together during the identity lifecycle.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security 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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: SaaS Management Employee Offboarding for IT & HR. Read the original.