SaaS discovery engines expose the identity gap behind shadow IT

At a glance

What this is: This is an explanation of how Zluri’s discovery engine assembles multiple enterprise signals to identify SaaS applications, with the key finding that discovery only matters if it closes the governance gap behind shadow IT.

Why it matters: For IAM and IGA teams, the issue is not just app visibility but lifecycle control, because unmanaged SaaS often means unmanaged access, approvals, and offboarding obligations.

Context

SaaS discovery is the process of finding the applications people actually use across an organisation, including tools purchased outside central procurement or accessed through browser activity, finance data, and identity signals. In this article, the identity governance problem is not discovery itself but what happens after an app is found: whether it is approved, assigned, monitored, and removed when no longer needed.

For IAM, IGA, and SaaS governance teams, that distinction matters because discovery creates an inventory, not assurance. If the discovery layer can identify applications but the lifecycle layer cannot prove ownership, permissions, and offboarding, shadow IT remains a control gap rather than a visibility gap.

Key questions

Q: What breaks when SaaS discovery finds apps but no one owns them?

A: Discovery without ownership breaks governance because the organisation can identify an application but cannot prove who approved it, who should review it, or who is responsible for offboarding. The result is visibility without control, which leaves shadow IT in place even after it has been detected.

Q: Why do hidden SaaS apps create access governance risk?

A: Hidden SaaS apps create risk because governance depends on knowing what exists, who owns it, and which accounts still have active access. Without discovery, reviews miss applications, deprovisioning misses accounts, and spending controls miss redundant licences. The result is unresolved access that persists beyond business need.

Q: How do teams know when SaaS discovery is producing actionable results?

A: They should look for a catalog that is both broad and clean, with accepted applications carrying enough metadata to support policy and licensing actions. If enrichment is missing or false positives remain high, discovery has produced volume but not governance value.

Q: What is the difference between SaaS configuration and SaaS governance?

A: SaaS configuration is the on or off state of a feature. SaaS governance is the policy, ownership, monitoring, and cleanup process that determines whether the feature can be used safely. A disabled setting may reduce exposure, but only governance ensures identities, content, and exceptions are managed over time.

Technical breakdown

How SaaS discovery engines correlate identity and usage signals

A SaaS discovery engine does not rely on a single source of truth. It correlates identity provider data, SSO events, finance records, browser activity, CASB telemetry, MDM inventory, HR attributes, and directory records to build a view of applications in use. Each signal captures a different part of the same problem: who is using what, whether the use was authorised, and whether the application is visible to central IT. That makes discovery a correlation problem, not just an application lookup problem. The technical challenge is matching partial evidence across systems that were never designed to govern SaaS together.

Practical implication: validate whether your discovery stack correlates identity, expense, and endpoint signals, not just SSO logs.

Why app discovery does not equal governance

Discovery identifies that an application exists and may even show usage, permissions, and spending. Governance requires a stronger conclusion: that the app has an owner, an approval path, an access model, and a retirement path. Without those lifecycle controls, discovery can expose shadow IT without reducing it. In practice, the gap appears when an application is detected in expense data or browser telemetry but never enters the joiner-mover-leaver, recertification, or offboarding workflow. That is why app discovery is necessary but insufficient for SaaS control.

Practical implication: tie every discovered app to ownership, approval, review, and offboarding workflows before treating it as managed.

What browser, finance, and directory data reveal about shadow IT

Browser extensions, finance systems, and directories each reveal different governance blind spots. Browser data shows active use even when no sanctioned integration exists. Finance data reveals employee-purchased tools that bypass procurement. Directory data shows who can authenticate, which groups inherit access, and where permissions may be broader than intended. When combined, those sources expose the difference between an application that is known and one that is governed. The important point is that shadow IT is often a lifecycle issue disguised as a discovery issue, because visibility without control still leaves unmanaged access in place.

Practical implication: use multi-source discovery to surface unsanctioned apps, then route them into review and offboarding processes immediately.

NHI Mgmt Group analysis

Discovery is only the first half of SaaS control: finding an application does not prove that the organisation can govern it. The article shows how multiple telemetry sources improve visibility, but visibility alone does not establish approval, access ownership, or retirement discipline. In identity programmes, that means discovery must be treated as an input to governance, not a substitute for it.

Shadow IT is often lifecycle failure, not just procurement failure: employee-purchased software, browser-accessed SaaS, and directory-visible entitlements all create the same underlying problem when no one owns offboarding. The governance failure is not that the app was hidden, but that its lifecycle never entered the control plane. Practitioners should read shadow IT as a sign that lifecycle coverage is incomplete.

Discovery engines create a new control expectation for IGA teams: once an app is visible, the organisation is expected to know who uses it, who approved it, and when access should end. That expectation changes SaaS governance from periodic review to continuous reconciliation across identity, finance, and endpoint data. Teams should treat discovery output as evidence that must be acted on, not a reporting layer to be archived.

App visibility becomes useful only when it is linked to accountable ownership: unmanaged SaaS is not solved by a bigger inventory alone. The operational requirement is to connect each discovered app to a responsible owner, an access decision, and a removal path. Without that accountability, the discovery layer simply documents the sprawl that the governance layer has not yet contained.

Identity surface management now extends beyond sanctioned applications: the article reflects a broader market shift where identity governance must account for where software is bought, opened, and used, not just where it is provisioned. That makes SaaS discovery a foundational control for modern IGA, but only if the organisation can convert visibility into lifecycle action.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Discovery maturity is now an identity governance question: the organisations that get value from SaaS discovery are the ones that can turn app sightings into accountable lifecycle actions. If a discovered application cannot be assigned, reviewed, and retired, then discovery has only documented the problem.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That gap is a useful warning for SaaS governance too, because visibility without ownership leaves access sprawl unresolved.

Identity surface management now has to include shadow IT: SaaS discovery increasingly sits at the boundary between procurement, access governance, and offboarding. Teams should prepare to reconcile app visibility with recertification evidence, not just with inventory data.

For practitioners

• Map discovery signals to lifecycle owners Require every discovered SaaS application to be assigned to a business owner, technical owner, and review cadence so visibility becomes accountable governance.
• Reconcile finance data with sanctioned app inventory Compare expense records and reimbursement data against approved SaaS inventories to identify employee-purchased tools that bypass procurement.
• Treat browser telemetry as evidence of active use Use browser extension and CASB signals to identify SaaS that is actively in use even when it is missing from central app records.
• Route newly found apps into recertification workflows Place discovered applications into access review and approval workflows so permissions, business need, and retirement status are checked on a recurring basis.

Key takeaways

• SaaS discovery helps organisations find unmanaged applications, but that visibility does not by itself establish control.
• The deeper risk is governance drift, where apps are detected but never tied to ownership, access review, or offboarding.
• IAM and IGA teams should treat discovery output as the start of a lifecycle workflow, not the end of the job.

Key terms

• SaaS Discovery: SaaS discovery is the process of identifying all sanctioned and unsanctioned software-as-a-service applications in use across the organisation. It matters because cloud assurance increasingly depends on seeing where apps share data, what permissions they hold, and which identities can reach them.
• Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Identity Surface: The identity surface is the full set of credentials, tokens, tool permissions, and delegated identities an AI agent can use during execution. It matters because agents often do not operate through a single account, and partial visibility into that surface creates false confidence about control coverage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.