- SSO logs only see the apps behind SSO
- Three tiers close the gap: SSO analytics, spend data, and an optional desktop agent
- Cross-referencing the tiers surfaces shadow IT, shelfware, and duplicate tools
- Start with SSO, add spend data, deploy the agent only where gaps remain
SSO sign-in logs from Okta, Microsoft Entra, or Google Workspace only show you the applications that authenticate through single sign-on. Desktop software, SaaS tools with direct email-and-password logins, and anything an employee signed up for on a credit card never appear in those logs, which means an SSO-only view systematically undercounts what your company actually uses. Reliable shadow IT detection takes three layers working together: SSO usage analytics, spend and integration data from your ERP and corporate cards, and, for what the first two can’t see, an optional desktop agent.
This gap is not a niche problem. In License Logic’s interviews with 80 mid-market executives, 49% said they lack centralized visibility into their SaaS stack. This article explains why SSO data alone can’t close that gap, and how the three-tier model does.
Why don’t SSO logs show all your software usage?
SSO logs only record authentication events that pass through your identity provider. If an application never authenticates through Okta, Entra, or Google Workspace, it generates no sign-in events, so from the identity provider’s point of view, it doesn’t exist. Several common categories of software fall into exactly that blind spot:
- Desktop applications. Design tools, engineering software, local utilities, and licensed desktop suites often run entirely outside the browser and never touch your identity provider.
- Direct-login SaaS. Plenty of paid SaaS tools are used with a plain email and password because nobody configured SSO for them, sometimes because the vendor charges extra for SSO support.
- Shadow IT sign-ups. An employee who registers for a tool with a personal or corporate card, outside procurement, has by definition bypassed your SSO configuration. These are the apps you most want to find, and they are precisely the ones SSO can’t show you.
- Free-tier tools. Free products spread through teams without a purchase event or an SSO integration, then convert to paid plans once they’re entrenched.
How big is the blind spot? There is no universal measured figure, and you should be skeptical of anyone quoting one. But in our sales conversations, IT leaders commonly estimate that somewhere around a quarter to a third of their software usage happens outside SSO, and when they connect additional data sources, the discovery list tends to confirm the instinct. If your SaaS usage tracking starts and ends with sign-in logs, you are managing the visible portion of the stack and guessing at the rest. For a broader walkthrough of discovery methods, see our guide on how to detect shadow IT.
What is the three-tier model for application visibility?
The three-tier model layers three independent data sources (identity, money, and the device) so that each tier catches what the previous one misses. No single source gives you full software usage visibility; the combination gets you close.
Tier 1: SSO usage analytics
SSO sign-in data is the right place to start because it’s high quality, employee-level, and cheap to get. A read-only connection to Okta, Microsoft Entra, or Google Workspace gives you sign-in activity for every application behind SSO: who uses each app, how often, and who hasn’t signed in for months. That last part matters for license reclamation: inactive users on paid seats are the fastest wasted-spend finding in most environments.
The integration is read-only: it pulls sign-in events and user records, and it cannot modify your identity provider configuration, users, or app assignments. That makes Tier 1 a low-lift first step that most IT teams can approve quickly.
What Tier 1 can’t do is see past its own perimeter. It tells you everything about the apps behind SSO and nothing about the rest.
Tier 2: API and spend integration data
The second tier follows the money instead of the login. Even when an application never authenticates through SSO, someone is usually paying for it, and that payment leaves a trail in your ERP or on a corporate card. Pulling that data in reveals vendors that identity data alone would never surface:
- ERP transactions. A read-only NetSuite integration syncs vendor payments, so software spend recorded in your general ledger becomes part of application discovery, including tools bought by a department that never told IT.
- Card and AP spend. A Ramp integration surfaces software purchases made on corporate cards, the classic shadow IT purchase path.
- Signed-contract imports. DocuSign and Adobe Sign integrations pull completed vendor agreements into the same repository, so contracts signed outside your normal process still land in central view.
Tier 2 is how spend-based application discovery works: a recurring $49 card charge to a vendor you’ve never onboarded is a shadow IT finding, whether or not anyone ever signs in through SSO. Its limitation is the mirror image of its strength: spend data tells you a vendor is being paid, but not who uses the product or how much. And it misses free tools entirely, because there’s no transaction to find.
Tier 3: An optional desktop agent
The third tier looks at the device itself. An optional desktop agent (currently available for macOS) observes application usage directly on the machine, which covers the categories the first two tiers structurally cannot: desktop software that never touches the browser, direct-login web tools, and free products with no payment trail.
The agent is deliberately the last tier, not the first. It requires deployment to endpoints, it raises legitimate employee-privacy questions (addressed below), and many organizations get most of the visibility they need from tiers 1 and 2 alone. Treat it as the precision instrument you add where the first two tiers leave gaps (for example, teams with heavy desktop tooling) rather than a default for every machine.
How do the three tiers work together for shadow IT detection?
The value is in the cross-referencing, not in any single feed. When contract, usage, and spend data sit side by side, mismatches between them become findings:
- Spend with no contract on file: a card or ERP payment to a vendor with no agreement in your repository is unmanaged software: no negotiated terms, no renewal date on anyone’s calendar.
- A contract with no usage: a paid agreement with few or no active users behind it is shelfware, and a candidate for downsizing at renewal.
- Usage with no spend or contract: sign-in or agent activity for a tool nobody is paying for usually means a free tier spreading through a team, worth catching before it converts to an unbudgeted paid plan.
- Duplicate vendors across departments: two teams paying separately for the same product shows up the moment spend and usage are viewed together.
Each of those findings requires at least two tiers to detect. That’s the practical argument for the model: shadow IT detection is a reconciliation problem, and you can’t reconcile data you haven’t collected. If you want to run this as a structured exercise, our shadow IT detection checklist walks through it step by step.
What should a desktop agent disclose about data collection?
Honestly and completely. This is the area where buyer skepticism is most justified, and any vendor should welcome the scrutiny. Before deploying any usage-tracking agent, get clear written answers to three questions:
- Exactly what data leaves the device? An agent built for license visibility needs application usage information: which applications are used and how actively. It does not need keystrokes, screen contents, file contents, or the substance of what an employee is working on. If a vendor can’t enumerate precisely what the agent collects, don’t deploy it.
- Are employees told? Deploying a usage agent silently is a trust failure waiting to happen, and in some jurisdictions a legal problem. Employees should know the agent is installed, what it collects, and why. The legitimate purpose is reclaiming unused licenses and finding unmanaged software, and that’s an explanation most employees accept when it’s actually given.
- Is it optional per machine? You should be able to scope deployment to the teams where tiers 1 and 2 leave real gaps, rather than being forced into all-or-nothing rollout.
License Logic’s agent is optional and scoped to application-usage visibility: it exists to answer “what software is actually used on this machine,” not to monitor employee behavior. Whatever platform you evaluate, hold it to the disclosure standard above.
How should you roll out the three tiers?
Incrementally, in order of effort. The model is a sequence, not a bundle you must adopt on day one:
- Start with SSO usage analytics. A read-only identity-provider connection delivers employee-level usage for your SSO-connected apps quickly, with minimal security-review friction. This alone typically surfaces inactive users and underused licenses worth acting on.
- Add spend data. Connect ERP and card-spend sources so application discovery extends to everything being paid for, and reconcile that against your contract repository.
- Deploy the agent where gaps remain. Once tiers 1 and 2 are live, the remaining blind spots are visible by their outline: teams with desktop-heavy tooling or clusters of direct-login apps. Deploy the agent there, with full disclosure to the affected employees.
This ordering also matches how organizations build the case internally: each tier produces findings that justify the next. To see how the tiers fit into a broader SaaS oversight practice, see our SaaS management overview.
Frequently asked questions
What does a usage-tracking desktop agent collect?
A well-designed agent collects application usage information (which applications are used on the machine and how actively) because that’s all license visibility requires. It should not capture keystrokes, screen contents, or the substance of an employee’s work, and the vendor should be able to list exactly what leaves the device. License Logic’s agent (currently macOS) is optional and focused on application usage.
Is the SSO integration read-only?
Yes. License Logic’s Okta, Microsoft Entra, and Google Workspace integrations are read-only: they pull sign-in activity and user records for usage analytics and cannot change your identity provider configuration, users, or application assignments. Read-only scope is worth verifying with any vendor during security review.
Can SSO logs alone detect shadow IT?
No. By definition, most shadow IT never authenticates through your identity provider, so it generates no SSO events at all. SSO logs are excellent for analyzing the applications behind SSO, but shadow IT detection requires at least one data source that doesn’t depend on the login path, such as ERP or card spend data, or a desktop agent.
Do I need all three tiers to get value?
No. Tier 1 alone typically surfaces inactive users and underused licenses, and adding Tier 2 spend data catches most unmanaged vendors. The desktop agent is optional and best deployed selectively where the first two tiers leave gaps, such as teams that rely on desktop software or direct-login tools.
How does spend data help with application discovery?
Spend data finds software by the payment trail instead of the login. A recurring card charge or ERP vendor payment reveals a tool in use even if nobody ever signs in through SSO, and comparing those payments against your contract repository flags vendors being paid with no agreement on file, which is the classic shadow IT signature.