Shadow IT is a discovery problem. Most companies never solve it because they look in the one place it can't be: the identity provider. Your SSO knows the apps somebody connected to it. The apps nobody told you about are, by definition, the apps nobody connected.
So the inventory that comes out of your SSO isn't your stack. It's your governed stack, which is the part you already had visibility into.
Where the apps come from
Almost never from bad intent, which matters because it changes how you handle what you find.
A designer needs a tool this week and the procurement path takes 3 weeks. A marketer signs up for a trial on a personal card and expenses it. A team lead buys 4 seats of something to test and it quietly becomes load-bearing. An engineer authorises an app against their work Google account and now it holds a read scope on Drive.
None of those people are working around you. They're working around a queue, which is the same mechanism that produces every other governance workaround.
Two things follow. The apps you find are mostly legitimate, so a sweep that ends in shutdowns will be resisted and won't run twice. And the dangerous ones aren't the ones with the most users. They're the ones whose buyer has left, which are still billing, still holding data, and now have nobody who can even answer a question about them.
The four signals
Run all four. Each catches a class the others miss, and the order is by yield per hour.
1. Card and expense data. Every app somebody bought has a payment attached, and payments are centrally visible in a way logins never are. Pull 12 months of card and expense lines and filter for anything recurring that looks like software. This is a morning's work and it catches most of what costs money.
2. OAuth grants. In Google Workspace or Microsoft 365, every app anyone signed into with their work account left a grant behind, along with the scopes it asked for. Almost nobody reads this list. It's the highest-yield signal for free-tier apps, and it's the only one that tells you what the app can reach rather than just that it exists.
3. Endpoint or network telemetry, if you already run it. Good for apps with no payment and no OAuth grant. Not worth deploying something new for.
4. Asking. Genuinely. One question per team lead, once a quarter: what are you using that IT didn't give you. Framed as amnesty rather than audit, this works better than people expect, and it's the only signal that catches the tool somebody uses on a personal account.

Apps in use that nobody told IT about, and what each one can reach.
The column that matters on a discovered app isn't the user count. It's what it can reach. That's why the OAuth signal earns its place: a 3-person tool with a Drive read scope is a bigger finding than a 40-person one holding nothing.
Patterns that break it
- Inventorying from the SSO. The single most common version of this exercise, and it returns the list you already had.
- Ending in shutdowns. Cancel a few tools people depend on and the next sweep gets nothing but silence. Governing beats banning, and it's also easier.
- Counting apps instead of exposure. A list of 60 discovered tools sorted alphabetically produces no decisions. Sorted by what each one can reach, it produces three.
- Leaving ownerless apps ownerless. The finding "this app's buyer left in March" is the one that needs action this week, and it's the one that reads as least urgent on a spreadsheet.
- Running it once. A discovery sweep has a half-life of about a quarter. The first run is interesting; only the third one tells you whether the intake path is working.
Doing this without a tool
The whole of signals 1 and 2 is manual work you can do this week, and they are most of the answer.
- Export 12 months of card and expense lines. Filter for recurring charges under about $2,000 a month, which is where SaaS bought outside procurement lives.
- Read the OAuth grant list in Google Workspace or Microsoft 365. Sort by scope breadth, not by user count. Anything holding a write scope on mail, files or calendar goes to the top.
- Build one sheet: app, monthly cost, user count, what it can reach, who bought it, is that person still here.
- Sort by exposure, then by cost. Two columns, not one, and the sort order is the whole reason the sheet produces decisions rather than discussion.
- Assign an owner to every row before deciding anything else. An app with no owner has no lifecycle, so it will never be offboarded from and never cancelled.
- Add the survivors to your offboarding path. This is the step that converts a discovery exercise into a governance improvement, and it's the step that gets left off.
Signals 1 and 2 take about a day between them and will find things nobody expected. Step 6 is the one that makes the day worth repeating, and it's the one that needs somebody to own it after the interesting part is over.
What still needs a person
The amnesty conversation. Whether a discovered tool stays, gets consolidated, or gets retired is a conversation with the team that depends on it. Run it as an edict and you lose the next sweep.
The free-tier judgment. An app that costs nothing and holds nothing is noise. An app that costs nothing and holds customer records is the most dangerous row on the sheet, and no signal ranks those correctly for you.
And consolidation. Finding that 3 teams pay for 3 different tools that do one job is a discovery. Deciding which one survives is a political exercise, and pretending otherwise is how it stalls.
Where Iden fits
Signals 2 and 6 above, standing rather than run.
Discovered apps sit next to connected ones in the same catalogue, with what each one can reach recorded alongside it. Exposure becomes a column rather than a research project. OAuth grants are read continuously rather than at sweep time, which matters because a grant authorised in week 2 of a quarter is otherwise invisible for 10 weeks.
The step that changes most is the last one. An app that gets discovered and then connected joins the offboarding path on its own. The sweep stops producing a spreadsheet and starts producing coverage. That distinction is the difference between knowing about shadow IT and having dealt with it.