Central logs and SSO data miss SaaS usage because many employees adopt apps outside approved onboarding paths, then sign in with personal email or unsupported login methods. If an application does not require SSO, or if users never reach a monitored authentication path, the central system sees little or nothing. Browser visibility closes that gap at the point of use.
Why This Matters for Security Teams
Central logs and SSO are often treated as the system of record for SaaS usage, but that assumption only holds when applications actually route through managed authentication. In practice, employees adopt tools through browser sign-ups, personal email, invite links, or vendor-native login methods, so the security team never sees the approval, authentication, or consent event in its central identity stack.
The gap matters because missed SaaS usage is not just a visibility issue, it is a governance issue. Unapproved applications can accumulate data, permissions, and collaboration history outside review, while teams continue to believe coverage is complete. That creates blind spots in access review, data loss prevention, vendor risk management, and incident response.
Browser visibility is useful here because it observes the application at the point of use, not only at the point of authentication. When organisations rely only on SSO telemetry, they often discover shadow SaaS after procurement, data sharing, or account sprawl has already become embedded in normal work. In practice, many security teams first learn about unsanctioned SaaS through a downstream incident or audit finding, not through their central login records.
How It Works in Practice
The reason central telemetry fails is simple: different controls observe different moments in the SaaS lifecycle. SSO logs are strongest when an app is integrated, users are forced through the identity provider, and the authentication transaction is visible. They are weak when the app is approved informally, accessed through a personal account, or connected by an email-based invitation that never touches the monitored path.
Browser-level visibility closes that gap by watching the session as the user interacts with the app itself. That can reveal SaaS discovery, login method, repeated use of an app that was never onboarded, and cases where the same tool is being used with both sanctioned and unsanctioned accounts. For security teams, that turns SaaS shadow use from an inference problem into an observation problem.
Common patterns include:
- apps adopted by a single team before central approval;
- personal email sign-ups for work collaboration;
- vendor portals or embedded login flows that bypass SSO;
- frequent use of browser-based SaaS with no corresponding identity-provider event.
That distinction is operationally important. Central logs tell you what the identity provider controlled; browser visibility tells you what employees actually used. The two sources should be correlated, not treated as interchangeable.
Where this guidance tends to break down is in environments that block browser telemetry, rely heavily on desktop clients, or allow significant SaaS usage through mobile apps and API-first workflows, because the browser no longer captures the full user path.
Common Variations and Edge Cases
Tighter SaaS control often increases friction for employees, so teams have to balance visibility against user adoption and privacy expectations. A browser-based control can surface unsanctioned apps quickly, but it may also reveal legitimate tools that were merely undocumented rather than maliciously shadowed.
Current guidance suggests treating these cases differently. If the app is business-relevant but unmanaged, the next step is usually onboarding and control alignment. If the app is unapproved and data-bearing, the issue is broader, because access, retention, and third-party risk may all be outside normal governance.
Edge cases are common with:
- freemium tools started by a team and later expanded across the organisation;
- consultants or contractors using non-corporate accounts;
- SaaS apps that support local credentials alongside SSO;
- shadow collaboration channels created to avoid procurement delay.
For teams comparing telemetry sources, the key question is not whether SSO is accurate, but whether SSO is complete for the way people actually acquire and use SaaS. If the application never requires central authentication, central logs will always undercount usage by design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of External Dependencies | Shadow SaaS creates governance gaps in visibility and ownership. |
| DE.CM-01 — Networks and Systems Monitored for Events | Browser visibility adds monitoring where SSO logs miss user activity. | |
| Recommendation — Track unsanctioned SaaS as an external-dependency oversight issue and assign ownership for review. Monitor user activity across browser and SaaS paths, not only identity-provider events. | ||
| CIS Controls v8 | 6.3 — Require and Periodically Review Access Rights | Unmanaged SaaS often reflects access that escaped normal review and approval. |
| Recommendation — Review SaaS access paths regularly and remove accounts or apps that bypass approved onboarding. | ||
Practitioner Guidance
What to prioritise: Correlate SSO logs with browser-observed SaaS usage before assuming a low-usage application is truly inactive. The first control objective is discovery, not enforcement, because you cannot govern what you have not seen.
What to verify: Check whether the application supports alternate login paths, personal email sign-up, or vendor-managed identity that bypasses your identity provider. If those paths exist, treat central login telemetry as partial coverage rather than authoritative coverage.
Decision rule: If browser data shows repeated use of an app with no matching SSO activity, classify it as unsanctioned or unmanaged until an owner proves otherwise. That avoids normalising shadow adoption as an innocent logging gap.
Practitioner takeaway: The important judgement is to measure SaaS usage at the point of actual access, then use SSO as one source of evidence, not the whole control picture.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
