Why do SSO and directory data miss so many SaaS applications?

Why This Matters for Security Teams

SSO and directory data are useful, but they are not a complete picture of software use. They mostly capture applications routed through central identity flows, while many business tools appear through browser sign-ups, card-based purchasing, finance-approved subscriptions, or embedded integrations that never touch the directory. That gap matters because discovery and control decisions are only as strong as the sources behind them.

For security teams, the practical risk is undercounting shadow IT, missing active SaaS usage, and assuming a clean app inventory when the environment is already fragmented. NIST Cybersecurity Framework 2.0 treats visibility as a foundational capability, not a one-time inventory exercise, and that is especially true when identities and purchases are spread across multiple control planes. In NHI programs, the same pattern shows up in hidden service connections and unmanaged tokens, which is why the Ultimate Guide to NHIs — Key Research and Survey Results is so direct about visibility gaps. In practice, many security teams encounter the real application footprint only after an audit, incident, or finance reconciliation has already exposed it.

How It Works in Practice

Effective SaaS discovery uses multiple signals and then reconciles them into one inventory. SSO logs show which apps are federated. Directory records show who can authenticate centrally. But neither source will reliably capture browser-only access, direct-to-vendor purchases, or applications linked through payment systems and downstream integrations. Discovery programmes work better when they correlate identity, endpoint, finance, network, and browser telemetry.

That usually means combining:

• SSO and IdP logs for federated application use
• Directory and RBAC data for assigned access and group memberships
• Expense, procurement, and card transaction records for self-purchased SaaS
• Browser and endpoint telemetry for apps used without federation
• CASB or SaaS posture data for external tenant activity and risky integrations

This approach aligns with the visibility and governance themes in Ultimate Guide to NHIs, because application sprawl often creates hidden machine identities, OAuth grants, and API keys alongside human access paths. It also echoes the practical guidance in NIST Cybersecurity Framework 2.0, which expects organisations to identify assets and dependencies across the environment rather than rely on a single authoritative source. Used properly, discovery is not just a report, but a continuous reconciliation process that flags mismatches between what IT thinks exists and what employees actually use. These controls tend to break down when business units adopt SaaS through self-service purchasing, because finance, identity, and browser signals rarely line up on the same day.

Common Variations and Edge Cases

Tighter discovery usually increases operational overhead, requiring organisations to balance completeness against privacy, data quality, and response time. That tradeoff is real, especially in environments with distributed procurement or global teams. There is no universal standard for this yet, but current guidance suggests that teams should prioritise the highest-risk blind spots first rather than chase perfect inventory from day one.

Some SaaS products are intentionally invisible to central SSO because they support guest access, consumer sign-ups, or delegated admin models. Others are embedded into workflows through signed OAuth consent rather than direct logins, which means the app may not appear in the directory at all while still having meaningful data access. This is where incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach matter operationally: they show how access can persist outside the visibility of standard identity reports. In practice, the edge cases are not exceptions to the problem. They are often where the most sensitive usage hides first.

Related resources from NHI Mgmt Group

• How should security teams govern SaaS applications that rely on integrations and shared data?
• Why do SaaS management tools matter to IAM teams?
• Why do malicious OAuth applications bypass so many IAM controls?
• How should security teams govern AI tools that connect to SaaS data?