Shadow SaaS and identity sprawl are outpacing ITAM controls

At a glance

What this is: This podcast-style article argues that SaaS growth and pandemic-era work changes accelerated shadow IT, making manual ITAM processes insufficient for visibility and control.

Why it matters: It matters because identity, access, and software governance now intersect across human users, SaaS accounts, and procurement flows, creating security and audit gaps that IAM and IGA teams have to close.

👉 Read Zluri's podcast discussion on SaaS management and shadow IT

Context

Shadow SaaS is the gap that appears when employees adopt applications outside formal procurement and IAM oversight. In practice, that means security teams lose track of who approved the app, what data it can reach, and which identities are now connected to it. This article is really about how SaaS convenience has outgrown the controls many organisations still use to govern access.

The governance problem is not only discovery. Once SaaS sprawl exists, ITAM, finance, procurement, legal, and security all hold partial views of the risk, but none has a complete one. That makes entitlement review, vendor due diligence, and offboarding harder to execute consistently, especially when adoption happens through a corporate card or an expense claim.

Key questions

Q: How should organisations govern shadow SaaS without slowing down business teams?

A: Start by treating unsanctioned SaaS as an identity and access issue, not just a purchasing issue. Build discovery from finance, procurement, and SSO data, then require security ownership for every application that can handle corporate information. The goal is fast approval with visible accountability, not blanket blocking.

Q: Why does shadow SaaS create more risk than traditional software sprawl?

A: Shadow SaaS often comes with built-in authentication, data sharing, and delegated access that extend beyond the original user. That means a single purchase can create multiple unmanaged identities and access paths. The risk is not only the app itself, but the hidden connections it forms to email, storage, and collaboration systems.

Q: What do security teams get wrong about SaaS inventory management?

A: They often assume a list of applications is enough. In practice, the real governance questions are who approved the app, which identities can access it, what data it can reach, and how it will be removed. Inventory without ownership and offboarding is just a snapshot, not control.

Q: Who should be accountable when an employee buys an unsanctioned SaaS app?

A: Accountability should be shared, but security needs a defined control owner. Procurement should stop unauthorised spend, IAM should track the identities and integrations created, and legal or risk teams should review vendor exposure. Without a named owner, offboarding and recertification usually fail.

Technical breakdown

Why shadow SaaS breaks identity visibility

Shadow SaaS creates identity sprawl because every unsanctioned application introduces its own accounts, permissions, and data-sharing paths. Unlike centrally managed apps, these services often bypass IAM onboarding, so security teams never get a clean inventory of users, scopes, or authentication methods. The governance issue is not just software count. It is the loss of a reliable control plane for identities that can still read, write, sync, or export corporate data.

Practical implication: establish discovery across procurement, finance, and SSO logs before entitlement review can be trusted.

Why spreadsheets fail as a SaaS governance control

A spreadsheet can record inventory, but it cannot continuously correlate identities, spend, approvals, and vendor risk. That matters because SaaS governance is dynamic. Users join and leave, subscriptions renew automatically, and integrations silently expand data access. Manual tracking also makes it difficult to prove ownership when a service account, API token, or delegated admin is involved, because the list becomes stale as soon as it is created.

Practical implication: treat spreadsheets as a temporary intake aid, not as a system of record for access governance.

How SaaS procurement becomes an access problem

The article shows that procurement is now part of identity governance because purchasing decisions often determine who gets access to data and services. When employees buy tools directly, the organisation may inherit hidden authentication paths, unmanaged permissions, and unsupported integrations. That means a finance event can become an IAM event, especially when the application connects to mail, storage, or collaboration platforms that already hold sensitive information.

Practical implication: route SaaS approval through security review and access ownership checks before payment is finalised.

Threat narrative

Attacker objective: The objective is to gain durable, low-friction access to corporate data through unmanaged SaaS connections and hidden identities.

1. Entry occurs when an employee acquires an unsanctioned SaaS application through a corporate card or expense claim, bypassing formal IAM review.
2. Escalation follows when the app connects to existing enterprise services and inherits access to data through user consent, API integration, or delegated permissions.
3. Impact is the loss of visibility and control over where corporate data lives, who can reach it, and how quickly the organisation can revoke access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow SaaS is an identity governance problem before it is a procurement problem. The article shows that buying software outside the approved path creates unmanaged identities, unmanaged entitlements, and unmanaged data flows in one move. That is why the control failure is not simply vendor sprawl but the absence of a trustworthy inventory of who can access what. Practitioners should treat unsanctioned app adoption as a governance event, not a purchasing exception.

Manual ITAM tools cannot keep pace with SaaS entitlement drift. The article's reliance on spreadsheets, expense claims, and ad hoc review reflects a governance model that only works when application boundaries stay stable. SaaS changes those boundaries continuously through integrations, auto-renewals, and delegated access. The named concept here is identity blind spots in software procurement, where access decisions happen before security even knows the application exists. Practitioners should recognise that the blind spot is structural, not accidental.

Procurement is now part of the identity lifecycle. When a user buys a SaaS app directly, the organisation inherits a lifecycle problem that starts at purchase and ends at offboarding, but often has no owner in between. That creates lifecycle gaps for access certification, vendor reassessment, and retirement of dormant accounts. The implication is simple: lifecycle governance must extend to SaaS acquisition paths, not just to accounts already in the directory.

Shadow IT exposes a control gap across human identity and machine identity at the same time. The article highlights employee-driven adoption, but the operational risk often lands in connected tokens, API keys, and application integrations. Once a user authorises a SaaS tool, the organisation may be governing both a human login and a non-human identity without realising it. Practitioners should model SaaS sprawl as a shared identity surface, not a user convenience issue.

The pandemic normalised decentralised buying, which means governance has to be decentralised too. The article links remote work and faster software procurement to more SaaS adoption, but the deeper lesson is that central approval alone no longer catches enough risk. Security teams need discovery, review, and revocation points that operate where spending and access actually happen. Practitioners should redesign oversight for distributed purchasing behaviour.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• For a broader control view, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that help close hidden access paths.

What this signals

Identity blind spots in software procurement: this article shows why SaaS oversight cannot live only in ITAM or procurement. When employees can create new access paths through ad hoc purchases, security teams need a discovery model that follows spend, consent, and integration data, not just directory records.

With 27 days as the average estimated time to remediate a leaked secret in NHI security research, the lesson for SaaS governance is clear: once access escapes the approved path, remediation lags behind business adoption. That lag becomes a recurring exposure window unless access ownership and offboarding are built into the buying process.

SaaS governance is converging with NHI lifecycle management because applications increasingly arrive with tokens, connectors, and delegated privileges. Teams that align discovery with the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0 will be better placed to govern the access surface instead of chasing it.

For practitioners

• Build SaaS discovery from multiple control points Correlate SSO logs, finance spend data, procurement records, and expense claims to identify applications that bypass formal approval. Use the overlaps to find hidden data-sharing paths and unknown owners before recertification begins.
• Classify every unsanctioned app as an access governance exception Assign an owner, a data classification, and an offboarding path to each discovered application so the organisation can revoke access when the business use case ends.
• Move SaaS approval before payment approval Require security review for authentication method, integration scope, and data handling before a corporate card or expense claim can finalise a purchase.
• Review delegated access and embedded integrations separately Do not stop at user accounts. Map API tokens, OAuth grants, and admin consents that keep a SaaS app connected after the original purchaser leaves or changes role.

Key takeaways

• Shadow SaaS is fundamentally an identity governance failure because it creates unmanaged users, permissions, and data paths outside normal controls.
• Manual inventory methods can record applications, but they cannot keep pace with SaaS entitlement drift, delegated access, and offboarding needs.
• Security teams should move approval, ownership, and revocation into the same workflow as procurement so software buying does not create invisible access.

Key terms

• Shadow SaaS: Shadow SaaS is the use of software applications outside approved procurement, security, or IAM processes. The risk is not only unmanaged spend, but unmanaged identities, data access, and integrations that security teams cannot easily discover, review, or revoke.
• SaaS entitlement drift: SaaS entitlement drift is the gradual expansion of permissions, integrations, and access paths after an application has been adopted. It happens when approvals, renewals, and delegated access continue to accumulate while ownership and review processes lag behind.
• Identity surface: The identity surface is the full set of accounts, tokens, roles, and delegated permissions that can access enterprise data and systems. In SaaS-heavy environments, it extends beyond the directory to include app-specific logins, API connections, and third-party integrations.
• Offboarding path: An offboarding path is the documented process for removing access, integrations, and ownership when an application or identity is no longer needed. For SaaS, it must cover human users as well as any tokens, consent grants, and connected services that remain active.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for IAM strategy or identity governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: SaaS Management Software Asset Management with the SAM Beast David Foxen Tathagata Chakrabarti. Read the original.