Zero-touch employee offboarding exposes the API gap in SaaS governance

At a glance

What this is: This is a SaaS offboarding and identity governance analysis showing that SSO alone does not close the API gap for disconnected applications.

Why it matters: It matters because IAM, IGA, and PAM teams still have to deprovision every app access path at offboarding, including unsupported SaaS, custom apps, and shadow IT.

By the numbers:

• The average business now utilizes over 254 different SaaS applications across its ecosystem.
• Industry analysts estimate that up to 40% of all IT spending occurs outside the purview of the IT department.

👉 Read Josys's analysis of zero-touch offboarding and the SaaS API gap

Context

The primary identity governance problem here is not login control, but lifecycle control across a sprawling SaaS estate. When an employee leaves, every application they touched must be deprovisioned, yet the article shows that many environments still rely on manual cleanup once SSO reaches its limit. The result is a governance gap between central identity policy and the actual application surface.

For IAM and IGA teams, this is the familiar offboarding failure mode that appears whenever the environment extends beyond supported connectors. Shadow IT, niche SaaS, legacy systems, and custom builds break the assumption that a central identity provider can see and control everything. That makes access review and deprovisioning a full-environment problem, not just an authentication problem.

Key questions

Q: What breaks when SSO is used as the only offboarding control?

A: SSO breaks down as an offboarding control when the organisation assumes authentication coverage equals lifecycle coverage. Unsupported apps, shallow APIs, and shadow IT can leave accounts active after departure even if the user is removed from the directory. The result is residual access, orphaned permissions, and audit exposure. The control problem is not login simplicity, it is complete deprovisioning across every application that still holds access.

Q: Why do unsupported SaaS apps complicate employee offboarding?

A: Unsupported SaaS apps complicate offboarding because the identity team cannot rely on the normal connector model to remove access or verify entitlement changes. If the application lacks an API or only exposes partial data, teams must use manual steps or custom scripts, which are slower and easier to miss. That creates a governance gap between leaving the company and actually losing access.

Q: How do security teams know if offboarding is actually working?

A: Offboarding is working only when teams can prove that accounts, admin roles, tokens, and permissions were removed across all relevant systems, including unsupported ones. The best signal is not a completed ticket, but a verified absence of access after the leaver event. If verification stops at the identity provider, the programme still has blind spots that attackers or auditors can exploit.

Q: Who is accountable when an employee keeps access after departure?

A: Accountability sits with the identity, application, and business owners who failed to ensure deprovisioning completed across the full application estate. The problem often spans HR signals, IAM execution, and app ownership, which is why offboarding governance needs clear ownership and evidence. In regulated or audited environments, incomplete revocation becomes a control failure, not just an operational miss.

Technical breakdown

Why the API gap breaks centralized SaaS governance

Single sign-on and identity providers centralize authentication and some provisioning flows, but they still depend on application APIs to manage permissions and accounts. When an app has no API connector, or the API exposes only shallow data, the governance boundary stops at the connector layer. Teams can still authenticate users into core systems, yet they cannot reliably enumerate entitlements, remove lingering roles, or verify that a departed employee has been fully offboarded. That is why SSO can improve access convenience without delivering complete lifecycle control.

Practical implication: Map every critical SaaS app to a real deprovisioning path, not just an SSO tile.

How unsupported apps create offboarding blind spots

Unsupported applications create an identity blind spot because access lives outside the standard integration model. In practice, that means IT may need to log into the app directly, use custom scripts, or accept partial visibility into user and permission data. The risk is not only delay. It is that orphaned accounts, stale admin roles, and missed permissions persist after offboarding. Manual work also varies by operator, which makes the control non-repeatable and difficult to audit. In lifecycle terms, the organisation has a process, but not a dependable enforcement mechanism.

Practical implication: Treat every unsupported app as a lifecycle exception that requires documented owner, process, and verification.

What universal data integration changes for identity enrichment

Universal data integration is the attempt to gather identity and access data from multiple sources, even when the target system lacks a native API. The technical idea is to combine primary identity signals from systems like the directory with secondary signals from HR or application records, then use those signals to trigger lifecycle actions. That can improve coverage, but it also raises the bar for data quality, source-of-truth alignment, and change detection. Without those, the automation may be fast while still acting on incomplete identity context.

Practical implication: Validate which source owns offboarding truth before automating cross-system deprovisioning.

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

SSO is not an offboarding control by itself. The article makes a familiar governance point: central authentication does not equal complete lifecycle enforcement. SSO reduces login sprawl, but it does not solve unsupported apps, shallow APIs, or disconnected permission models. Practitioners should treat offboarding as a deprovisioning problem across the full application estate, not as an identity provider setting.

API dependency is the real control boundary in modern SaaS governance. The article’s “API gap” is more than an implementation nuisance. It is the point where the identity programme loses the ability to see, change, and verify access state. That means governance quality is capped by connector coverage, not by policy intent. IAM and IGA teams should measure control reach, not just tool adoption.

Manual offboarding creates avoidable residual access risk. When teams must log into dozens of applications one by one, every exit becomes an error-prone exception process. That is where orphaned accounts and missed admin credentials persist long enough to become audit findings or attack paths. The field lesson is straightforward: lifecycle governance without repeatable enforcement is only partial governance.

Zero-touch security is really a coverage problem, not a branding problem. The phrase describes a state in which access changes propagate without human handling across sanctioned and unsanctioned apps alike. In practice, that depends on data integration, source alignment, and verification after deprovisioning. Practitioner takeaway: if the environment includes shadow IT, zero-touch claims should be tested against the hardest-to-connect apps first.

Universal integration should be judged by governance completeness, not automation speed. The article emphasises rapid integration and AI-assisted extraction, but the security question is whether the method closes the last mile of access removal. If it cannot prove that offboarding is complete, faster workflows only accelerate incomplete governance. Teams should evaluate coverage, auditability, and exception handling before they evaluate convenience.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, which increases the chance that offboarding misses a hidden copy or stale token.
• For a broader view of lifecycle governance, see NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding steps that reduce residual access.

What this signals

Zero-touch offboarding only works when the organisation can reach the last unsupported application. The practical challenge is not building a smarter dashboard, but closing the coverage gap created by niche SaaS and shadow IT. Teams should expect lifecycle governance to become a connector-assurance exercise, where the question is whether every leaver signal can be acted on and verified across the full estate.

Residual access is the metric that matters once automation enters offboarding. If the process is faster but still leaves tokens, roles, or admin access behind, the programme has only accelerated its own blind spot. That is why leaver reviews, exception tracking, and post-deprovisioning checks belong in the same control conversation as directory sync and SSO.

API coverage should be measured against business exposure, not app count alone. A small set of niche systems can create disproportionate risk if they hold privileged or regulated data. Use the Top 10 NHI Issues to pressure-test where connector gaps and secret exposure tend to combine into the highest-value failure points.

For practitioners

• Inventory unsupported applications before the next offboarding cycle Build a list of SaaS, custom, and legacy applications that sit outside native connector coverage. Include business owner, identity source, deprovisioning method, and verification step for each one.
• Define a fallback deprovisioning path for every API gap Document what happens when an app cannot be governed through the directory or IGA tool. The fallback should specify who removes access, how completion is confirmed, and how exceptions are audited.
• Align HR and identity sources before automating offboarding Confirm which system is authoritative for leaver status, then test that the signal propagates reliably to downstream apps. If the wrong source can trigger deprovisioning, automation will scale the wrong decision.
• Measure residual access after departure, not just task completion Use post-offboarding checks to confirm that accounts, roles, tokens, and admin paths were actually removed. A completed workflow is not the same as a completed security outcome.

Key takeaways

• The article shows that offboarding fails when lifecycle control ends at the SSO boundary instead of the application boundary.
• The scale problem is already large, with more than 254 SaaS applications per average business and a substantial shadow IT footprint outside IT control.
• Practitioners should build verified deprovisioning paths for unsupported apps, because complete access removal matters more than centralised login management.

Key terms

• API Gap: The API gap is the space between what an identity platform can authenticate and what it can actually govern. In SaaS environments, it appears when an application lacks a usable connector or exposes too little data to manage entitlements, leaving lifecycle work partially manual and audit visibility incomplete.
• Offboarding: Offboarding is the process of removing a departing user’s access, credentials, roles, and application entitlements across every system they used. In practice, it is a governance control that depends on accurate source data, connector coverage, and post-removal verification, not just directory deactivation.
• Shadow It: Shadow IT is software and service usage that sits outside normal IT visibility or approval. It matters to identity governance because hidden applications often hold active accounts, admin roles, or tokens that do not appear in standard access workflows, making deprovisioning incomplete.

Deepen your knowledge

Offboarding governance and SaaS lifecycle coverage are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment still depends on manual deprovisioning for unsupported apps, this is a strong place to start.

This post draws on content published by Josys: Achieving Zero-Touch Security, Why SSO Isn't Enough for Secure Employee Offboarding. Read the original.