This question comes up a lot because the answer is not as clean as people want it to be.
If every app went through Okta, this would be easy. You would pull a report, look at every SAML and SCIM integration, and call it done.
But that is not how companies actually work.
Teams buy tools on corporate cards. Employees sign up for free trials. Departments adopt apps before IT knows they exist. Vendors invite users directly. Someone grants OAuth access to a third-party app. A service account gets created for an integration and never gets reviewed again.
So when someone asks, “How do I find apps that were never added to Okta?” the real answer is: you have to piece it together from multiple signals.
None of them are perfect. All of them are useful.
The most common place to start is finance.
Look at corporate card spend, AP invoices, expense reports, and recurring SaaS subscriptions. If the company is paying for something, that is usually a strong signal that the app exists.
This catches a lot of obvious tools: project management apps, design tools, sales tools, developer tools, recruiting tools, customer support tools, and all the small SaaS subscriptions that get bought by a team before IT is involved.
But finance data only answers one question: are we paying for this?
It does not tell you who has access. It does not tell you who is an admin. It does not tell you whether former employees still have accounts. It does not tell you whether users are logging in with Google, Microsoft, passwords, or magic links.
Finance is a good discovery source. It is not an access source of truth.
The next place teams look is network or endpoint telemetry.
CASB, SSE, browser, DNS, and endpoint tools can show which SaaS domains employees are hitting. This can uncover tools that never made it into the IdP and may not appear cleanly in finance data.
This is helpful because usage creates a signal. If ten employees are regularly visiting a SaaS app, someone should know why.
But activity is not the same as access.
A user visiting a domain does not tell you what role they have. It does not tell you whether they are an admin. It does not tell you whether they created an account, connected OAuth, uploaded company data, or invited external users.
Network telemetry helps you find smoke. It does not fully describe the fire.
This is where a lot of hidden access shows up.
Employees often connect third-party apps to Google Workspace or Microsoft 365. They grant scopes to read files, send email, access calendars, manage contacts, or operate inside another system on their behalf.
That access may never touch Okta.
OAuth is especially important because it shows delegated access. The app may not be in your IdP, but it may still have access to company data through Google or Microsoft.
This is one of the best places to look for shadow applications and risky app-to-app access.
But it still has limits. It mostly shows what is connected through Google or Microsoft. It does not show every app. It does not show every local role. It does not show the full permission model inside Salesforce, Jira, AWS, GitHub, or whatever else your teams are using.
OAuth tells you a critical part of the story. It is not the whole story.
This sounds basic, but it is still one of the things people do.
Ask department heads what tools their teams use. Ask managers what apps are required for their workflows. Send a spreadsheet. Run an internal survey. Review onboarding checklists. Look at team-specific process docs.
This works because humans often know things the systems do not.
The sales team knows the tool they bought for outbound. Engineering knows the vendor they use for logs. Marketing knows the analytics tool someone added six months ago. Finance knows the weird vendor that keeps showing up on an invoice.
But this approach is manual, incomplete, and stale as soon as you finish it.
People forget. People leave things out. People describe tools differently. Some teams do not know whether a tool is company-approved, personally expensed, or just something they logged into once.
Still, you should do it. Human context matters. Just do not confuse it with control.
A lot of companies discover unmanaged apps during audits.
SOC 2, ISO 27001, internal access reviews, customer security questionnaires, and incident response work all have a way of surfacing the same uncomfortable question:
Can you prove who has access?
That is usually when teams realize the app inventory is incomplete.
The problem is that audit-driven discovery is reactive. By the time the app appears in an audit, it has already been used, accessed, and potentially misconfigured for months or years.
Audits are useful forcing functions. They are not a discovery strategy.
SaaS management platforms can help build an inventory by combining signals from spend, SSO, browser extensions, and integrations.
They are useful for finding apps, assigning owners, rationalizing spend, and identifying unused licenses.
But inventory is not the same as access control.
Knowing that an app exists does not tell you whether access is appropriate. Knowing that a team owns the app does not tell you whether a former employee still has admin rights. Knowing there are 48 licenses does not tell you what each person can actually do.
These tools can help you get organized. They do not always give you the effective access picture.
This is the answer people want to be true.
In theory, if every app goes through Okta, then Okta becomes the source of truth. Every login is controlled. Every user is managed. Every app is visible.
In reality, that breaks down quickly.
Not every app supports SAML. Not every app supports SCIM. Some access happens through OAuth. Some access happens through API keys. Some access belongs to service accounts. Some access is created locally inside the app. Some tools are adopted before IT even knows they exist.
Okta is important. Entra is important. Google Workspace is important.
But the IdP is the front door. It is not the whole building.
Finding the app is only step one.
The better questions are:
Who has access?
What can they do?
How did they get that access?
Is it tied to a human, a group, an OAuth grant, a service account, an API key, or an external user?
Is that access still appropriate?
That is the gap most teams run into. They can eventually build an app list. What they cannot easily build is a reliable view of effective access across all those apps.
And that is the part that matters.
Because risk does not come from the app merely existing.
Risk comes from the access inside it.
