What are the signs that a SaaS discovery programme is still leaving major visibility gaps?

A SaaS discovery programme is still weak when it relies on a few central sources, shows far fewer applications than users actually use, or cannot explain how people authenticate into apps. Large numbers of apps only discovered through browser activity, heavy dependence on manual review, and poor coverage of personal email signups are all strong warning signs.

Why This Matters for Security Teams

A saas discovery programme is only useful if it exposes the applications people actually use, not just the ones that appear in a directory, SSO dashboard, or CASB feed. When discovery is incomplete, security teams miss shadow IT, uncontrolled data sharing, and weak authentication paths, which means policy, access review, and offboarding decisions are all being made against a partial asset inventory.

One of the clearest warning signs is that the programme cannot reconcile user-reported activity with observed application use. If browser telemetry reveals far more SaaS usage than central logs, the gap is not cosmetic, it means the organisation is blind to real exposure. In practice, many teams only discover those gaps after a user leaves, a browser extension surfaces a new app, or a downstream audit asks where data actually flows.

Security teams should treat discovery quality as an operating control, not a one-time inventory exercise. The real test is whether the programme can keep pace with how employees create accounts, sign in with personal email, and adopt tools outside approved procurement channels.

How It Works in Practice

A strong SaaS discovery programme should triangulate multiple sources rather than depend on any single feed. SSO logs show governed applications, proxy or browser telemetry reveals unsanctioned app use, finance and procurement data show billed subscriptions, and manual review fills in the blind spots that automated sources miss. The point is not to maximise raw counts, but to build a defensible map of where business activity is actually happening.

Practitioners usually look for four mechanics when they judge whether discovery is working:

applications first seen through browser activity rather than central control planes;
apps used by a meaningful number of employees but absent from the approved catalogue;
accounts created with personal email addresses, which often bypass enterprise oversight;
poor explanation of how users authenticate, especially when the app supports multiple login paths.

If discovery cannot explain the login path, it is difficult to assess whether access is subject to SSO, MFA, or separate local credentials. That matters because a SaaS inventory is not just a list of brands, it is the starting point for understanding who can get in, how access is provisioned, and how quickly it can be revoked when risk changes.

Where this breaks down most often is in environments with heavy browser-based work, contractor-heavy populations, or widespread self-service adoption, because the organisation may never see a central procurement event before the app is already in use.

Common Variations and Edge Cases

Tighter discovery often improves control, but it also increases noise and review burden, so teams have to balance breadth against the ability to validate what the tool is surfacing. Some gaps are real coverage failures, while others reflect a legitimate architecture choice, such as an app that is intentionally accessed through a federated identity provider and therefore appears sparse in local logs.

There is no universal standard for this yet, but current guidance suggests treating discovery quality as suspect when browser-first apps vastly outnumber centrally registered apps, when personal-email signups are common, or when manual review is doing most of the work that telemetry should handle. Those conditions usually indicate the programme is seeing the enterprise from the provider side, not from the user side.

Another edge case is multi-account behaviour. A user may have one sanctioned tenant and one unsanctioned tenant for the same SaaS product, so the programme must distinguish between product identity and tenant-level access. Without that separation, teams can mistakenly believe they have coverage simply because they know the product name.

When the discovery programme cannot explain where the app was found, who uses it, and how it is authenticated, the inventory is not yet strong enough to support governance decisions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Visibility and Discovery	SaaS discovery gaps often hide unmanaged non-human access paths and blind spots.
Recommendation — Instrument discovery across browser, SSO, and logs to expose hidden identity and access paths.
CIS Controls v8	6.2 — Software Inventory	SaaS discovery is an inventory problem that needs continuous asset visibility.
Recommendation — Maintain a continuously updated inventory of approved and observed SaaS applications.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems are inventoried	The subject is an asset-visibility gap that fits inventory and governance functions.
Recommendation — Create and maintain an inventory of SaaS systems using multiple telemetry sources.
NIST SP 800-63	IAL2 — Identity Assurance Level 2	Discovery gaps matter when apps use local or federated sign-in paths needing stronger assurance.
Recommendation — Require stronger identity assurance where SaaS access is not centrally federated.

Practitioner Guidance

What to prioritise: Focus first on reconcilement, not enumeration. Compare browser telemetry, SSO logs, and procurement data for the same time window, then flag any app that appears in only one source or only through personal-email signups.

What to verify: For each material SaaS app, verify whether access is federated, locally authenticated, or split across both. If the programme cannot name the login path, treat that app as insufficiently governed until proven otherwise.

What good looks like: A mature programme can explain not only how many apps exist, but which ones are employee-created, which ones are business-approved, and which ones have no clear owner or access path. That is the level of visibility needed for access review, offboarding, and risk acceptance.

Practitioner takeaway: The strongest signal of a visibility gap is not that the count is low, it is that the inventory cannot be reconciled back to how real users find, sign up for, and authenticate into SaaS.