Shadow IT from SaaS sprawl is widening identity governance gaps

At a glance

What this is: This article explains how SaaS-driven shadow IT expands the identity governance gap by letting employees adopt apps and access outside IT control.

Why it matters: It matters because IAM and IGA teams now have to govern app adoption, access assignment, and offboarding across tools that enter the estate without review.

By the numbers:

• 57% of IT leaders are concerned about shadow IT, according to Zluri research.
• 76% of employees say they prefer to work from home, according to Zluri research.

Context

Shadow IT is the use of software or hardware without IT team knowledge. In this article, the identity governance problem is not only that unapproved apps exist, but that they are being adopted, accessed, and retired outside the normal controls that IAM and IGA programmes depend on.

SaaS makes that gap wider because employee-led adoption is easy, integrations are simple, and access decisions often happen locally rather than centrally. The result is SaaS sprawl, where governance, compliance, and cost control all degrade at the same time.

The source article frames shadow IT as a control problem created by modern SaaS usage patterns, remote work, and decentralised buying. That is a typical pattern in organisations that have allowed business units to move faster than their identity governance processes.

Key questions

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: Why does shadow IT become more risky as SaaS adoption and cloud use increase?

A: Shadow IT becomes riskier as SaaS and cloud usage grow because procurement, configuration, and access controls spread across more teams and more endpoints. That widens the chance of unreviewed data handling, weak oversight, and unmanaged dependencies. When tools are adopted outside formal governance, organisations lose visibility into where information lives, who can access it, and how quickly risks can be corrected.

Q: How can security teams tell whether SaaS chaos is still generating sprawl?

A: Look for a widening gap between the official application inventory and what multi-source discovery reveals in practice. If transaction records, browser activity, network signals, or direct integrations expose many tools that were never reported through governance channels, SaaS chaos is still active. That gap is a strong indicator that identity, access, group, and data sprawl will keep expanding.

Q: How should IAM teams govern SaaS purchases before rollout?

A: IAM teams should treat SaaS purchasing as a control checkpoint, not a post-contract cleanup exercise. Before rollout, they should confirm federation, role design, privileged access, integration ownership, and offboarding paths. That prevents business demand from creating unmanaged access paths and makes the application governable from day one.

Technical breakdown

How SaaS sprawl creates shadow IT outside IAM control

SaaS sprawl occurs when app adoption outpaces the organisation’s ability to discover, vet, and govern those apps. In practice, employees can sign up for tools through free trials, freemium plans, or one-click onboarding, then share them across teams before security or IT sees the app at all. That bypasses standard identity governance controls such as approved application inventory, access review scope, and lifecycle oversight. Once the app is embedded in daily work, it becomes harder to remove or rationalise without disrupting users.

Practical implication: maintain an authoritative app inventory that is continuously reconciled against actual user adoption and access activity.

Why employee-led SaaS adoption weakens access governance

When departments or employees procure apps directly, access administration often shifts away from central IAM into local team ownership. That may speed up onboarding, but it also breaks consistent policy enforcement for joiner, mover, and leaver events. Offboarding becomes especially fragile because a local manager may remove access in one app while related accounts, shared links, or connected SaaS services remain active elsewhere. This is an identity governance issue, not only a procurement issue, because the control point has moved downstream from IT.

Practical implication: require central lifecycle governance for apps even when business teams retain operational ownership.

How SaaS integrations expand the blast radius of shadow IT

Modern SaaS stacks are tightly connected through native integrations, automation services, and API-driven workflows. That makes one unsanctioned app more than a standalone risk, because it can inherit or propagate data, tokens, and access paths into other systems. The more connected the app is, the more difficult it becomes to contain a single governance failure. In identity terms, every unreviewed integration can extend the trust boundary beyond what the organisation originally approved.

Practical implication: review third-party integrations with the same discipline used for the primary SaaS app, including data flow and access scope.

NHI Mgmt Group analysis

Shadow IT is now an identity governance problem first and a procurement problem second: when employees can adopt SaaS without central review, the organisation loses visibility into who can access what, where data is flowing, and which apps should be offboarded. That shifts risk from purchase oversight into lifecycle control, which is where IAM and IGA teams must reassert authority.

SaaS sprawl exposes a governance gap that conventional review cycles do not close: access reviews assume the application estate is known and stable long enough to certify. In SaaS-heavy environments, apps can appear, spread, and disappear faster than annual or quarterly governance processes can react. The implication is that discovery and lifecycle control have to move closer to the point of adoption.

Decentralised app buying weakens the accountability model for non-human access too: once SaaS platforms integrate with other services, each unreviewed connection can create new machine identities, tokens, or delegated permissions outside normal oversight. That broadens the identity surface beyond human users and makes the hidden estate the real control problem.

Remote work accelerates the spread of unmanaged access, but it does not change the governance requirement: organisations still need a single policy model for app approval, access ownership, and offboarding. The strongest programmes treat shadow IT as a signal that the identity operating model is too slow for the way the business buys software now.

SaaS sprawl produces an identity blast radius larger than most teams budget for: a single unsanctioned application can create data leakage, compliance exposure, and redundant spend at the same time. Practitioners should read this as evidence that app governance, access governance, and vendor governance are now one control problem.

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

Identity governance now has to track software adoption as closely as it tracks user access: SaaS sprawl means the control problem starts before formal provisioning. If teams only review accounts after an app is already embedded, they are reacting to governance drift rather than preventing it.

Shadow IT widens the hidden identity surface: every employee-purchased app can add local administrators, shared credentials, connected integrations, and data pathways that never pass through central policy. The practical signal is that app inventory and lifecycle control must be treated as one programme, not separate tasks.

The governance gap is structural, not accidental: product-led SaaS, remote work, and easy integrations all reward fast adoption. That makes discovery, approval, and offboarding the limiting controls, and it is why identity teams need continuous visibility rather than periodic clean-up.

For practitioners

• Implement continuous SaaS discovery Reconcile SaaS usage from expense data, SSO logs, browser telemetry, and cloud app connectors to build a live app inventory.
• Govern employee-purchased apps centrally Require business-owned apps to meet the same vetting, access ownership, and offboarding requirements as IT-managed applications.
• Review SaaS integrations and connected accounts Map every third-party integration, API token, and delegated connection attached to approved apps before granting broader data access.
• Tighten access review scope Include locally managed apps, freemium tools, and department-owned services in certification cycles so shadow IT is not excluded from recertification.

Key takeaways

• Shadow IT in SaaS environments is an identity governance problem because access, ownership, and offboarding often happen outside central control.
• The risk is not limited to compliance. It also includes data leakage, duplicate spend, and unmanaged integrations that expand the trust boundary.
• IAM and IGA teams need continuous discovery and lifecycle governance for employee-purchased apps, not just periodic access reviews.

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.
• Software Lifecycle Governance: Software lifecycle governance is the management of software from procurement through active use to retirement. It becomes an identity issue when the software creates accounts, tokens, API connections, or delegated access that must be tracked and removed when the software itself is no longer needed.

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.