Your SASE tool can show you the traffic. What it can't show you is who has an active account in the Notion workspace marketing set up last year, or the project management tool operations has been running on a shared credit card, or the AI tool someone on the sales team signed up for with their work email six months ago. You can see the connection. You can't govern the identity.

When those users leave the company, the standard offboarding process — disable the Okta account, revoke the M365 license — closes the SSO perimeter. It doesn't touch a single one of those shadow IT accounts. The departed employee's credentials may still be valid. Their data access may still be open. And you have no automated way to know which accounts exist, let alone revoke them.

Why SASE Visibility Doesn't Solve the Offboarding Problem

Network-based discovery shows you traffic. It doesn't show you the identity behind the traffic, what level of access that identity has, or whether the account still exists after the user's corporate SSO is revoked.

The shadow IT offboarding problem has two distinct layers that require different tools. The first is discovery: finding every application a user has access to, including tools that were never onboarded through IT and never connected to SSO. The second is remediation: actually revoking that access when the user leaves, without having admin credentials to every app marketing or sales quietly adopted.

Most IT teams land on one of two default positions when they realize the scale of the problem. The first is to ignore it — "if IT didn't deploy it, it's not ours to manage" is a real and defensible position, right up until an offboarded employee's account is involved in a data incident. The second is to enforce SSO as a non-negotiable for any new SaaS tool, which is correct policy and does nothing about the tools already in the environment.

The commenter in this thread who suggested blocking OAuth/OIDC for new SaaS apps noted the practical problem with that approach: you don't eliminate the behavior, you push it to email/password signups that are even harder to track. Policy enforcement stops the growth of the problem. It doesn't solve the existing footprint.

The manual alternative — documenting app owners, notifying each app owner at offboarding, asking them to revoke access — is reasonable at small scale and described honestly by practitioners in this thread as exactly what it is: manual, based on trust, and workable only if you have the bandwidth to maintain the owner registry and follow up on every departure.

How to Discover SaaS Accounts IT Never Provisioned

Closing the discovery gap requires pulling identity data from sources beyond the network layer. Zluri's Discovery Engine maps SaaS usage across the environment through four integrated data sources that collectively surface accounts that network monitoring can't see.

SSO and identity provider integrations capture every application a user authenticates to via "Sign in with Google" or "Sign in with Microsoft" OAuth. These are the accounts that exist because a user clicked a social login button rather than going through an IT provisioning request — and they're the ones most likely to be missed at offboarding because they were never formally granted.

Financial and expense system integrations — NetSuite, Expensify, corporate card data — identify SaaS subscriptions that were purchased by departments and expensed outside the IT procurement process. These are the tools marketing bought on a team credit card and the subscriptions operations is paying for from their own budget. They show up in finance before they show up in IT.

Browser and desktop agents detect application usage directly at the endpoint, bypassing network restrictions entirely. A user who accesses a SaaS tool over their home network, through a VPN that routes outside your SASE perimeter, or on a mobile device still generates a browser-level signal that surfaces the app in Zluri's discovery map.

The combination of these sources produces an access map that reflects what users are actually using, not just what IT formally provisioned. Once that map exists, the offboarding scope is defined by reality rather than by the IT-managed subset of reality.

How to Offboard Users From Apps IT Never Controlled

Once Zluri has mapped the departing employee's full SaaS footprint — including shadow IT — the offboarding playbook auto-populates with every application they had access to, not just the SSO-connected ones.

The deprovisioning execution takes three paths depending on what each app exposes.

For applications with direct API integrations — over 300 in Zluri's native library — the playbook makes API calls to revoke the license, reset sessions, and remove the account without anyone logging into the app manually. The account is gone, the license is freed, and the action is logged.

For browser-based applications without accessible APIs, Zluri uses AI-powered browser automation — deterministic automation that navigates the application's admin interface and executes the removal the way a human administrator would. This covers the category of apps that are reachable through a browser but have no programmatic interface, without requiring IT to have admin credentials to every tool marketing or operations adopted.

For applications that require genuine human intervention, Zluri identifies the internal app owner — the marketing manager who bought the tool, the operations lead who set up the workspace — and routes a tracked manual task to them automatically. They receive a Slack notification or Jira ticket with the specific action required, must mark it complete inside Zluri's dashboard, and the completion is logged in the offboarding record. The task doesn't fall through silently, and IT has a record that the request was sent and fulfilled even when the action itself was handled by someone outside IT.

Turning Shadow IT From a Risk Into a Governed Asset

The discovery process that supports offboarding also supports ongoing governance. Once Zluri maps the unmanaged applications in your environment, those apps can be categorized — in use, restricted, needs review — and app owners can be formally assigned rather than inferred at offboarding time.

The pattern several practitioners in this thread described — find out who got voluntold into managing the tool, get them a seat in the ticketing system, notify them at offboarding — is essentially the manual version of what Zluri automates. The insight is right: the person who manages the shadow IT tool often doesn't want to manage credentials, doesn't know when someone leaves, and would happily hand that back to IT if there were a structured way to do it. Zluri gives them that structure: the app owner is formally registered, they get notified automatically when a user they manage departs, and they can fulfill the deprovisioning action in a tracked workflow rather than responding to a manual email.

Frequently Asked Questions

How do you offboard users from SaaS apps that IT never provisioned?

The first step is discovery — mapping every application a departing user has access to using sources beyond network traffic, including SSO OAuth logs, financial system integrations, and browser agents. Once the access footprint is mapped, deprovisioning runs through direct API calls for apps with integrations, AI-powered browser automation for apps without APIs, and tracked manual tasks routed to app owners for apps requiring human intervention. A platform like Zluri handles all three paths from a single offboarding trigger.

What is shadow IT and why is it an offboarding risk?

Shadow IT refers to SaaS applications adopted by employees or departments without formal IT approval or provisioning. Because these tools are never connected to SSO or formal provisioning workflows, disabling an employee's Okta or Azure AD account doesn't touch their accounts in shadow IT apps. When an employee leaves, those accounts can remain active indefinitely — with valid credentials, continued data access, and allocated licenses — unless a separate discovery and revocation process addresses them explicitly.

Does blocking OAuth and SSO prevent shadow IT?

Blocking OAuth for new SaaS apps stops new tools from being connected via social login, but it doesn't eliminate the behavior — it shifts it to email/password signups that are harder to track and revoke at offboarding. Policy enforcement stops the growth of shadow IT. It doesn't address the existing footprint of tools already in use. Discovery and governance tooling is required to manage what's already there.

How do you find shadow IT apps used by employees with corporate email addresses?

The most comprehensive approach combines multiple data sources: SSO and IdP logs that surface OAuth-connected apps, financial system integrations that reveal subscriptions purchased outside IT procurement, and browser or desktop agents that detect app usage at the endpoint regardless of network routing. Network monitoring through SASE tools shows traffic but doesn't surface the identity or account details needed for governance and offboarding.

Map Your Full SaaS Footprint Including Shadow IT

If your SASE tool is showing you shadow IT traffic but you have no way to act on the identities behind it, see how Zluri's Discovery Engine maps your full SaaS footprint — including the apps marketing, sales, and operations adopted without IT — and automates the offboarding for each one.