TL;DR: Shadow SaaS is widespread because employees can adopt unapproved SaaS tools faster than IT can review them, creating blind spots for data exposure and offboarding risk, according to Unixi and the Cloud Security Alliance. Browser-level visibility helps security teams discover usage, but governance still depends on enforcing approved access paths and lifecycle control.
NHIMG editorial — based on content published by Unixi: shadow SaaS detection and prevention through browser-level authentication
By the numbers:
- 55% of employees adopt SaaS without the involvement of the security team.
Questions worth separating out
Q: How should security teams govern shadow IT in SaaS environments?
A: Security teams should govern shadow IT by treating it as unmanaged access, not just unsanctioned software.
Q: Why does shadow IT create identity governance risk?
A: Shadow IT creates identity governance risk because access happens outside approved inventory, review, and revocation processes.
Q: How do organisations know whether shadow SaaS is actually under control?
A: They should be able to show a current inventory of SaaS apps, the identities using them, the data they hold, and the owner responsible for offboarding and renewal.
Practitioner guidance
- Inventory unsanctioned SaaS by user and business owner Use browser telemetry and identity logs to identify which employees created accounts, which applications they used, and which teams now depend on them.
- Tie SaaS approval to identity and data controls Require application review before corporate credentials can be used for sign-in, and record where sensitive data is stored so access decisions include both authentication and data exposure.
- Enforce an approved app allowlist at the session layer Block or step up authentication for services that have not been reviewed, contracted, or assigned a security owner.
What's in the full article
Unixi's full article covers the operational detail this post intentionally leaves for the source:
- How its browser-based detection identifies shadow SaaS sessions at the point of user interaction
- The remediation workflow for flagging, prioritising, and blocking unapproved SaaS usage
- How the tool reports user-level application data to security teams for follow-up
- Where browser-level authentication enforcement fits into a broader SaaS governance process
👉 Read Unixi's analysis of how to detect and block shadow SaaS →
Shadow SaaS is the governance gap hiding in plain sight?
Explore further
Shadow SaaS is an identity governance problem before it is a SaaS problem. The article shows that users can create business-critical access paths outside managed channels, which means the organisation loses control over who owns the account, who can review it, and who can revoke it. That is why unmanaged SaaS should be treated as an identity lifecycle exception, not just an application inventory issue. The practitioner conclusion is clear: if the identity team cannot govern the login, it cannot govern the risk.
A question worth separating out:
Q: What should teams do when shadow SaaS is discovered in a business unit?
A: Contain the risk by identifying the user, the data stored, and the business purpose, then decide whether to approve, migrate, or block the service. If the application is kept, it needs ownership, review cadence, and offboarding rules. If it is blocked, data removal must be verified.
👉 Read our full editorial: Shadow SaaS visibility gaps are breaking enterprise control boundaries