Shadow IT in SaaS is an identity governance problem

At a glance

What this is: Zluri argues that Shadow IT in SaaS is fundamentally an identity governance problem because unsanctioned apps, unmanaged access, and hidden data paths create control gaps IT cannot easily see or revoke.

Why it matters: This matters because IAM, IGA, and SaaS governance teams have to control access and offboarding for apps they did not approve, not just inventory the ones they did.

By the numbers:

• 80% of employees admit that they use apps that aren’t approved by IT.
• 57% of IT leaders are concerned about shadow IT.

Context

Shadow IT in SaaS is the use of applications without IT knowledge, approval, or governance. In practice, the problem is not only unsanctioned software but the identity and access paths that form around it, including local admin decisions, stored credentials, and vendor access that sit outside central oversight.

In SaaS-heavy environments, employees can adopt tools directly, connect them to other apps, and store business data outside approved systems. That creates an identity governance gap because access, ownership, termination, and data retention decisions move away from IT while the organisation still carries the security and compliance risk.

The article frames shadow IT as both a productivity behaviour and a governance failure. That combination is typical in SaaS-first organisations, where decentralised adoption expands faster than account lifecycle controls and review processes.

Key questions

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. Start with continuous discovery, then map each app to owners, data types, delegated scopes, and revocation paths. The control goal is to reduce hidden access paths before they become business-critical dependencies.

Q: Why does shadow IT increase cyber risk even when employees are trying to improve productivity?

A: Shadow IT creates blind spots. When assets appear outside IT and security oversight, teams lose visibility into domains, APIs, apps, and integrations that still belong to the organisation. That weakens control over exposure, makes incident response slower, and increases the chance that sensitive systems are left unmonitored or ungoverned.

Q: What happens when SaaS applications are adopted without IT approval?

A: When SaaS is adopted without IT approval, the organisation accumulates shadow IT, which creates gaps in visibility, policy enforcement, and data protection. Teams may lose track of where sensitive information lives, who can access it, and whether the application meets compliance expectations. Over time, that makes incident response, auditing, and access governance materially harder.

Q: What happens when organisations block unapproved SaaS apps without offering approved alternatives?

A: Blocking without an alternative often shifts the problem rather than solving it. Users look for workarounds, adopt unsanctioned tools, or delay work while trying to regain access. A better approach is to pair blocking with clear messaging, redirection to approved services, and role-based exceptions where justified. That preserves control while keeping work flowing.

Technical breakdown

Why SaaS shadow IT becomes an identity governance issue

SaaS shadow IT creates a governance problem when app adoption happens outside approved procurement and identity workflows. Employees can sign up for tools directly, connect them to other services, and begin storing company data without any central record of who owns the account, who approved the access, or how it will be revoked later. The result is not just a software sprawl problem. It is a broken identity control plane, because entitlement, vendor trust, and offboarding all become fragmented across business units, browsers, and consumer tools.

Practical implication: Treat unsanctioned SaaS as an identity inventory and lifecycle problem, not only a procurement issue.

Why stored credentials and reused logins increase SaaS risk

The article calls out credentials stored in browsers, spreadsheets, and consumer vaults, plus repeated use of the same login across multiple accounts. That pattern removes separation between applications and makes compromise much easier to scale. Once one credential is exposed, it can unlock several SaaS services and any connected integrations. In governance terms, the problem is that authentication state becomes informal and undocumented, so the organisation cannot reliably prove where access exists or whether it has been rotated after exposure.

Practical implication: Map where SaaS credentials are stored and eliminate any path that allows one reused secret to unlock multiple applications.

How third-party access and overbroad sharing break least privilege

Shadow SaaS often extends beyond employee accounts into third-party vendor access and file-sharing permissions. The article notes that vendors may receive edit rights where view rights would have been enough, and that central account management is often absent. That means least privilege is being decided ad hoc at the point of use rather than governed through policy. The practical failure is not abstract risk. It is an access model where scope, review, and revocation are all weakened because the organisation cannot see the full sharing chain.

Practical implication: Review SaaS sharing and vendor permissions against least-privilege requirements before data spreads beyond controlled accounts.

Threat narrative

Attacker objective: The objective is to reach business data or usable SaaS access through unmanaged identities and poorly governed sharing paths.

1. Entry occurs when employees independently adopt SaaS apps, connect them to work data, and create accounts outside IT approval and inventory.
2. Credential exposure follows when those apps rely on stored browser credentials, reused passwords, or unmanaged consumer vaults.
3. Escalation and lateral movement happen through connected integrations, overbroad sharing, and third-party vendor access that exceeds the minimum needed.
4. Impact appears as data leakage, compliance exposure, lost access after termination, subscription waste, and broken ownership of business information.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow IT in SaaS is not just a tooling problem, it is an identity governance failure. When employees adopt applications outside IT approval, the organisation loses the ability to govern who owns access, who can revoke it, and where business data ultimately lives. That makes SaaS shadow IT a lifecycle issue as much as a discovery issue, and it belongs in IAM and IGA operating models, not only in procurement review.

Unmanaged SaaS access turns least privilege into an assumption rather than a control. The article shows how vendor permissions can drift to edit rights, how employees share data informally, and how local teams manage access without central oversight. That pattern creates privilege sprawl in the exact places where review and recertification are weakest, so practitioners should read shadow IT as a signal that access governance is already partial.

Shadow SaaS creates trust debt across the application estate. Every unsanctioned app adds another place where credentials, data sharing, and offboarding can fail, and that debt compounds as remote work and product-led adoption expand the SaaS perimeter. The practical implication is that identity teams need governance coverage for all externally reachable applications, not only the ones in the approved catalogue.

Access termination is the hidden weak point in shadow IT programmes. The article notes that former employees may still retain access and that personal accounts can hold critical data after departure. That means offboarding, recertification, and ownership transfer are not back-office tasks here; they are the controls that decide whether shadow IT becomes a recoverable exception or a permanent blind spot.

SaaS sprawl should be treated as a measurable control gap, not an acceptable by-product of productivity. The article acknowledges real employee value in bottom-up app adoption, but that does not remove the need for governance. The field should stop treating shadow IT as a behaviour to suppress and start treating it as a managed surface that requires policy, visibility, and enforcement.

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.

What this signals

Shadow IT is a perimeter problem for IAM, not just for network security. As SaaS adoption decentralises, identity teams need visibility into app creation, app-to-app connections, and offboarding paths that never pass through central IT. The control objective shifts from blocking every unsanctioned tool to governing the identities and permissions that grow around them.

Access reviews are weaker when the application inventory is incomplete. If teams do not know which SaaS apps exist, they cannot certify access, validate ownership, or confirm that former users have been removed. That is why SaaS discovery and lifecycle governance need to be linked instead of managed as separate workstreams.

For practitioners

• Inventory unsanctioned SaaS usage Build a living list of employee-adopted apps, business-unit purchases, and connected tools that sit outside approved procurement and security review.
• Review credential storage paths Find where users keep SaaS credentials in browsers, spreadsheets, personal vaults, and shared notes, then remove those storage paths from the normal workflow.
• Tighten third-party sharing rights Check whether vendors and external collaborators have edit access when view access is sufficient, and align each shared account to a documented business owner.
• Fix offboarding for personal SaaS accounts Add checks for employee-owned app accounts and personal storage locations so departures do not leave data or active access behind.

Key takeaways

• Shadow IT in SaaS becomes a governance problem when access, ownership, and data handling move outside central IT control.
• The article points to broad exposure across security, compliance, data loss, and budget waste, with employees using apps that IT never approved.
• IAM and IGA teams need discovery, ownership assignment, and offboarding coverage for unsanctioned SaaS, not just for the approved stack.

Key terms

• 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.
• SaaS Sprawl: SaaS sprawl is the uncontrolled spread of software-as-a-service applications across teams and business units. It creates fragmented ownership, duplicated functionality, and weak visibility into who can access what. For IAM and NHI teams, the main risk is not only cost but persistent entitlements that outlive business need.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.

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.