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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Shadow SaaS is unmanaged SaaS use outside IT and security control, creating visibility, data exposure, and offboarding risk.
Why it matters: IAM and security teams need to treat unsanctioned SaaS as a governance boundary problem because access, data location, and lifecycle control all become harder to enforce.
By the numbers:
- 55% of employees adopt SaaS without the involvement of the security team.
Context
Shadow SaaS is unmanaged software-as-a-service use that sits outside approved IT and security workflows. The governance failure is not only that the application is unsanctioned, but that the organisation loses sight of where corporate data is stored, who can still reach it, and whether access is ever revoked when people change roles or leave.
This matters to identity and access programmes because the control boundary shifts from centrally administered accounts to user-created SaaS tenants and browser-mediated logins. In practice, that creates a lifecycle blind spot for both human identity governance and any non-human access that is later layered into the same applications.
Key questions
Q: What fails when employees create shadow SaaS accounts outside IT control?
A: The failure is lifecycle governance. Accounts, data stores, and sharing settings are created outside approved onboarding and offboarding workflows, so security teams lose reliable control over who can access the tenant, where data is stored, and when access should end. The result is a parallel application estate that standard IAM records do not fully cover.
Q: Why does shadow SaaS increase security risk even when users have corporate logins?
A: Corporate credentials do not make an unsanctioned SaaS tenant safe. If the organisation cannot see the application, govern the data, or enforce revocation when someone leaves, the account still becomes a durable exposure point. The risk comes from unmanaged authority and data placement, not just from the login method.
Q: What are the signs that shadow IT SaaS governance is failing in a financial services environment?
A: The clearest signs are security blind spots, fragmented data governance, and limited awareness of where employees are storing or sharing sensitive data. If teams can only secure a small portion of the SaaS estate, or cannot track authentication methods and usage patterns, governance is already falling behind the actual risk surface.
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.
Technical breakdown
How shadow SaaS bypasses control boundaries
Shadow SaaS appears when users create or adopt SaaS accounts outside the normal provisioning and review process. That breaks the expected identity lifecycle, because access is no longer tied to approved onboarding, role assignment, or offboarding. The security team may still control corporate directories, but it no longer controls the full path by which data enters a vendor service. Once users move sensitive work into an unsanctioned tenant, discovery, classification, and revocation all become harder because the system is outside the enterprise control plane.
Practical implication: build discovery around actual usage, not just approved applications, so unsanctioned tenants do not remain invisible.
Why browser-level visibility changes detection
Browser-level visibility works by observing the point of interaction where a user authenticates into web applications, including unapproved ones. That gives security teams application-level context they do not get from directory logs alone, such as which SaaS app was accessed and which user account was used. This is important because shadow SaaS often hides behind legitimate corporate credentials. The key technical shift is from inventory based on procurement records to telemetry based on real usage at the browser session.
Practical implication: supplement SaaS inventories with session-level telemetry so unapproved applications surface before they become data repositories.
How remediation closes the offboarding gap
Detection alone does not solve the problem because users can simply return to the same behaviour later. Remediation has to block access to unapproved SaaS, or the enterprise keeps the same shadow surface area. The article’s model effectively places policy enforcement at the authentication step, so access to anything outside the approved list can be flagged and stopped before more data lands in the rogue tenant. That is the difference between awareness and control.
Practical implication: pair discovery with enforced access policy so unsanctioned SaaS use is not merely reported but actually prevented.
Threat narrative
Attacker objective: The immediate objective is not always external compromise, but uncontrolled access to corporate data through an unmanaged SaaS tenant that the organisation cannot reliably govern.
- Entry occurs when employees self-provision SaaS accounts outside IT and procurement channels, often using corporate credentials or a credit card.
- Credential and data use continue inside an unsanctioned tenant where security teams lack routine visibility into sharing, storage, and access scope.
- Impact follows when sensitive corporate data remains exposed in an unmanaged application and persists after employee departure or role change.
Breaches seen in the wild
- Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow SaaS is an identity governance failure before it is a software inventory problem. The core issue is that users can create a parallel access environment outside approved onboarding, access review, and offboarding processes. Once that happens, the organisation has lost the ability to govern the full lifecycle of the account and the data stored behind it. Practitioners should treat this as a boundary-control problem, not a discovery-only problem.
Browser-level telemetry is valuable because it moves SaaS oversight closer to the point of authentication. Directory logs and procurement lists miss the behaviour that actually matters: who is logging into which application, and under what authority. That makes browser observation a useful control layer for human identity governance, especially where approved and unapproved apps coexist in the same workstream. Practitioners should align monitoring with actual session behaviour rather than assumed application inventories.
Shadow SaaS creates governance debt that compounds when offboarding is weak. Sensitive data placed into an unsanctioned SaaS workspace can outlive the employee who created it, which means access removal at HR exit does not guarantee data removal or tenancy closure. The control gap is persistent account and data sprawl, not a one-time policy violation. Practitioners should assume that unmanaged SaaS becomes an orphaned-data problem unless lifecycle enforcement is explicit.
Shadow SaaS is also an early signal of future non-human identity sprawl. Once business users normalise unsanctioned SaaS adoption, those same services often accumulate API keys, automations, integrations, and service accounts outside central governance. That widens the identity attack surface from human access to machine access. Practitioners should govern SaaS usage as a precursor to NHI sprawl, not as a separate issue.
Shadow SaaS visibility works only when discovery and blocking are tied together. A tool that finds unsanctioned apps but cannot stop access simply improves reporting. The article points to a stronger model: detect usage, rank risk, and enforce policy at the point of login. Practitioners should measure success by reduced unsanctioned access, not by the size of the app list.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: Service Account Security Guide
What this signals
Shadow SaaS is a control-boundary issue, not just an awareness gap. Once users can create application tenants outside sanctioned workflows, the organisation has already lost part of its identity governance model. Security teams should focus on where access is initiated and where data lands, because discovery alone does not restore control.
Browser-mediated discovery will become more important as SaaS sprawl expands. Unsanctioned apps are hard to see from directory or procurement records alone, so session-level telemetry gives practitioners a more reliable view of who is using what. That makes governance closer to runtime behaviour, which is where the real risk exists.
Shadow SaaS often becomes the on-ramp to broader NHI sprawl. The same unsanctioned services that start with human sign-ups later accumulate tokens, automations, and service accounts that sit outside ownership and review. Practitioners should treat SaaS discovery as the first line of defence against downstream machine identity growth.
For practitioners
- Map actual SaaS usage, not just approved app lists Correlate browser activity, identity logs, and procurement data to find SaaS tenants created outside normal channels, then classify them by business risk and data sensitivity.
- Enforce approved-access paths at login Block or step up authentication for applications that are not on the approved list so users cannot keep moving work into unmanaged SaaS spaces.
- Build offboarding checks for unmanaged SaaS data Add SaaS tenant review to leaver and role-change workflows so teams verify whether documents, sharing links, and integrations remain active after exit.
- Create a remediation queue for shadow SaaS risk Prioritise unmanaged apps by data type, user count, and external sharing exposure so security teams can shut down the highest-risk tenants first.
Key takeaways
- Shadow SaaS weakens control boundaries because users can create and use SaaS tenants outside sanctioned governance, leaving data and access outside normal identity lifecycle management.
- Visibility into unsanctioned SaaS matters, but the control problem is not solved until access paths are enforced and offboarding reaches external tenants.
- The most durable response is to combine discovery, risk ranking, and login-time blocking so unmanaged SaaS use cannot persist as a hidden parallel estate.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unmanaged SaaS creates orphaned access and data retention after role changes or exits. |
| NHI-10 — Human Use of NHI | Employees are creating and using unmanaged SaaS identities outside governance processes. | |
| Recommendation — Tie shadow SaaS discovery to offboarding so unmanaged tenants are reviewed before accounts are closed. Control human-created SaaS accounts by enforcing approved onboarding and login paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This article is fundamentally about enforcing approved access boundaries for SaaS use. |
| Recommendation — Review entitlements for unapproved SaaS access and revoke permissions that sit outside policy. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shadow SaaS emerges when account creation and oversight escape central management. |
| Recommendation — Inventory externally created SaaS accounts and remove those without an approved business owner. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Unmanaged SaaS can preserve credentialed access and expose data outside monitored channels. |
| Recommendation — Map shadow SaaS findings to credential-access and exfiltration patterns in your detections. | ||
Key terms
- Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
- Control boundary: The line that defines who can administer, observe, and change a system. For NHI and IAM programmes, the control boundary matters because auditors and risk teams care about where authority sits, not just where the software runs. Clear boundaries make assurance easier; blurred ones create governance debt.
- Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
- Browser-layer visibility: Browser-layer visibility is the ability to observe user activity where it actually happens in the web session, including app use, input, consent, and extensions. For AI governance, it becomes the evidence layer that shows what employees used, what data they exposed, and what access they granted.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management in the context of real enterprise control challenges. It helps practitioners connect identity lifecycle decisions to the broader security programme they operate every day.
Published by the NHIMG editorial team on August 27, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org