SaaS discovery engines expose the identity gap behind shadow IT

At a glance

What this is: This is an analysis of how SaaS discovery engines work and the key finding is that visibility is assembled from multiple identity and operational data sources, not from one control plane.

Why it matters: It matters because IAM, NHI, and lifecycle teams need a defensible view of app exposure before they can govern access, remove shadow IT, or align ownership across human and non-human identities.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's explanation of how its discovery engine maps SaaS visibility

Context

SaaS discovery is the process of identifying which applications are in use, who is using them, and where access and spend are happening outside formal control. In identity terms, the problem is not just application sprawl, but the governance gap that appears when access, usage, and ownership are split across SSO, finance, browser, device, and directory signals.

For IAM and governance teams, this is a lifecycle problem as much as a visibility problem. If an organisation cannot reliably see the application, it cannot confidently certify access, revoke stale entitlements, or decide whether a SaaS tool should be treated as sanctioned, shadow IT, or a higher-risk integration point.

The article describes a broad discovery model built from identity provider data, expense records, browser telemetry, device inventory, CASB visibility, HR metadata, and direct app integrations. That is a typical starting point for modern SaaS management programmes, but it also shows how fragmented the evidence base remains when ownership and control are distributed.

Key questions

Q: How should security teams govern SaaS apps discovered outside procurement?

A: They should treat them as controlled exceptions until ownership, access, and data handling are mapped. Discovery alone does not make an app safe or approved. The right response is to assign ownership, determine whether the app holds business data, and decide whether to approve, contain, or remove it through a documented governance path.

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

A: Because they only show applications that are tied to central identity flows. Employees can buy software directly, access tools through browsers, or connect apps through finance-approved spend and custom integrations. A discovery programme needs those extra signals or it will undercount shadow IT and miss real usage.

Q: What do security teams get wrong about SaaS discovery?

A: They often confuse discovery with control. An inventory of applications is useful, but it does not tell you whether the app is sanctioned, whether access is still appropriate, or whether machine credentials attached to the app can be revoked. Governance starts after discovery, not at the point of detection.

Q: How can organisations decide which discovered apps need immediate action?

A: Prioritise applications with unsanctioned spend, sensitive data exposure, admin-level access, or machine integrations that cannot be quickly explained. Those signals indicate the highest likelihood of governance drift. If an app has no clear owner or revocation path, it should move to containment or removal review.

Technical breakdown

How SaaS discovery engines correlate identity and usage signals

SaaS discovery engines do not rely on a single source of truth. They correlate login events, directory records, browser activity, expense data, device inventory, CASB telemetry, and direct app integrations to infer whether an application is actually in use. The technical challenge is normalisation: each source describes the same application differently, with different user identifiers, timestamps, and permission scopes. Discovery only becomes useful when those records are deduplicated and mapped into one inventory that can support governance decisions.

Practical implication: require identity matching rules and source-of-truth precedence before trusting any discovered app inventory.

Why SSO and directory data are necessary but incomplete

SSO and directory systems show who can authenticate, which groups they belong to, and often whether a login succeeded. That is useful, but it misses apps purchased outside central procurement, browser-only access, and accounts created through direct integrations. In practice, SSO visibility often describes the controlled perimeter, not the full SaaS estate. Discovery engines that stop at SSO undercount shadow IT and can miss applications that still carry data exposure and access risk.

Practical implication: combine SSO data with non-identity signals so access reviews do not stop at managed applications.

How browser extensions and finance feeds reveal shadow IT

Browser extensions capture visits to known SaaS domains and can show frequency and duration of use without reading cookies or content. Finance feeds add another layer by surfacing software bought with corporate or reimbursed personal spend. Together they expose applications that bypass approval paths but still create identity and data risk. The mechanism matters because many SaaS tools become operational before they ever enter an admin catalogue. Discovery therefore has to detect both installed access paths and off-book purchases.

Practical implication: use browser and finance feeds to find uncatalogued apps before you try to govern access or usage.

Threat narrative

Attacker objective: The practical attacker objective in this pattern is not immediate compromise alone, but reaching unmanaged SaaS paths where identity controls, review cycles, and offboarding are weakest.

1. Entry occurs when users adopt SaaS tools through direct purchase, browser access, or untracked integrations rather than through approved procurement and IAM workflows.
2. Credential or access exposure follows when the same apps are connected to SSO, directories, or direct integrations that reveal users, permissions, and login activity without complete governance coverage.
3. Impact emerges as shadow IT, excess license spend, and incomplete security review, leaving the organisation with app usage it can see only after the control gap has already formed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow SaaS is an identity problem before it is a procurement problem: Discovery engines are really trying to reconstruct accountability across fragmented signals. When an organisation buys and uses SaaS outside formal workflows, ownership, approval, and offboarding stop lining up. That is why visibility programmes must be evaluated as identity governance controls, not just inventory tools.

Discovery without lifecycle governance creates an inventory of unmanaged risk: Finding an application is not the same as knowing whether its access was approved, whether it still has valid credentials, or whether it should exist at all. The article shows how easily SaaS usage can be collected from many sources, but the hard part is deciding what to do with that visibility once it appears. Practitioners should treat discovery as the front edge of governance, not the finish line.

Identity provenance is the missing control plane for SaaS sprawl: The real question is not how many applications exist, but whether the organisation can prove where each one came from, who owns it, and which identity systems can revoke it. Without provenance, access reviews become retrospective bookkeeping instead of active control. The implication is that SaaS inventories need ownership, source, and revocation context before they can support IGA or PAM decisions.

Browser, finance, and directory signals need to be reconciled into one governance record: Each source catches a different slice of the SaaS estate, but none is sufficient on its own. This is where a named concept emerges: identity provenance gap, the space between discovering an app and being able to govern its users, spend, and offboarding. Practitioners should focus on closing that gap before expanding discovery coverage further.

NHI lifecycle controls are increasingly relevant to SaaS discovery programmes: SaaS tools often depend on service accounts, API keys, and integrations that outlive the person who created them. That means discovery findings should flow into NHI governance, not just human access management. A mature programme should be able to revoke both user access and machine access when an application is retired or reclassified.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Another finding from our research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader framework on lifecycle, visibility, and offboarding, see NHI Lifecycle Management Guide, which helps translate discovery into revocation and ownership controls.

What this signals

Identity provenance gap: As SaaS estates expand, the question shifts from app count to control lineage. Teams need to know which source introduced an app, which identity systems can revoke it, and whether the app still belongs in the approved estate.

Discovery programmes are becoming an input to NHI governance as much as to SaaS governance. Once service accounts, API keys, and direct integrations are part of the stack, the control problem crosses from application visibility into non-human lifecycle management.

With only 5.7% of organisations reporting full visibility into their service accounts, per the Ultimate Guide to NHIs, the limit is no longer tooling coverage alone. It is whether teams can turn discovered evidence into ownership, revocation, and recertification decisions.

For practitioners

• Map discovery sources to a single ownership model Assign one business owner and one technical owner to every discovered SaaS app, then reconcile SSO, finance, browser, and MDM records before adding the app to governance workflows.
• Require offboarding paths for shadow SaaS Build a retirement workflow that removes user access, revokes app-specific tokens, and closes reimbursement or procurement loops when an app is no longer approved.
• Treat browser telemetry as governance evidence Use browser extension data to identify apps that never entered procurement, then route those findings into access review, exception handling, and application rationalisation.
• Connect discovery outputs to NHI lifecycle review When a SaaS app uses API keys, service accounts, or direct integrations, review those credentials as part of the app's lifecycle, not as a separate exception process.

Key takeaways

• SaaS discovery is really a governance exercise because visibility only matters when it can be tied to ownership, approval, and revocation.
• Multiple discovery sources are necessary because SSO alone misses off-book purchases, browser access, and unmanaged integrations.
• The practical control gap is identity provenance, which means every discovered app needs a clear owner, revocation path, and lifecycle decision.

Key terms

• SaaS discovery: SaaS discovery is the process of identifying which cloud applications are in use across an organisation and who is using them. In practice it combines identity, finance, browser, device, and integration signals so governance teams can move from unknown usage to owned and reviewable application records.
• Shadow IT: Shadow IT is software used outside approved procurement, security, or identity governance processes. It creates control gaps because the organisation may not know who owns the app, what data it holds, or how to revoke access when the app is no longer acceptable.
• Identity provenance: Identity provenance is the chain of evidence that explains where an application came from, who owns it, and which systems can govern it. It becomes critical in SaaS environments because discovery without provenance produces inventories, but not actionable control decisions.
• Lifecycle governance: Lifecycle governance is the discipline of managing an identity or application from introduction through review, change, and retirement. For SaaS and NHI programmes, it means discovery findings must lead to ownership, certification, rotation, and offboarding rather than sitting as static inventory.

Deepen your knowledge

SaaS discovery, shadow IT, and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building visibility and offboarding controls from a similar starting point, it is worth exploring.

This post draws on content published by Zluri: How Zluri’s discovery engine works. Read the original.