TL;DR: SaaS-driven shadow IT is expanding as employees adopt apps outside IT oversight, increasing data leakage, compliance exposure, and wasted spend; Zluri says 57% of IT leaders are concerned about shadow IT and 76% of employees prefer working from home. The governance problem is now identity-related as much as procurement-related, because app adoption and access are moving faster than review and control cycles.
At a glance
What this is: This article argues that SaaS adoption is accelerating shadow IT by letting employees bring in apps faster than IT can vet, govern, or decommission them.
Why it matters: It matters because unmanaged SaaS creates unreviewed access paths, fragmented ownership, and lifecycle gaps that affect NHI, autonomous, and human identity programmes alike.
By the numbers:
- 57% of IT leaders are concerned about shadow IT.
- 76% of the employees say they prefer to work from home.
👉 Read Zluri's analysis of how SaaS adoption is driving shadow IT
Context
Shadow IT is software adopted without central IT knowledge or approval, and SaaS has made that problem easier to scale because employees can sign up, integrate, and share access in minutes. The key identity issue is that every unsanctioned app introduces its own accounts, entitlements, and offboarding burden, which turns application sprawl into access sprawl.
For IAM and IGA teams, the governance gap is not just visibility. It is the collapse of lifecycle control when business units and employees can create operational dependencies before IT has assessed data handling, compliance, or privilege boundaries. That pattern now spans human users, service accounts, and the non-human identities created around SaaS integrations.
Key questions
Q: How should security teams control shadow IT in SaaS environments?
A: Security teams should combine discovery, ownership, and lifecycle controls. Start by inventorying unsanctioned apps from identity, finance, and network signals, then assign a business owner, classify the data involved, and require offboarding steps that remove user access, admin roles, and delegated connections before the app is considered retired.
Q: Why does SaaS sprawl create identity risk beyond software sprawl?
A: SaaS sprawl creates identity risk because each app introduces users, admins, tokens, and integrations that must be governed over time. If those identities are not recertified and revoked consistently, access persists long after the app’s original business purpose has changed, widening the organisation’s attack and compliance surface.
Q: What do organisations get wrong about employee-owned SaaS apps?
A: They often treat employee-owned tools as low-risk because procurement is small or the app looks harmless. The real risk is that business teams can create data flow, access, and retention obligations without IT visibility, which makes later remediation harder and increases the chance of forgotten accounts or unmanaged integrations.
Q: When should organisations move a SaaS app from local ownership to central governance?
A: Move it to central governance when the app handles regulated data, supports customer processes, or connects to other systems through OAuth, APIs, or service accounts. At that point, local management is no longer enough because access, revocation, and evidence requirements have outgrown informal control.
Technical breakdown
Why SaaS creates shadow IT faster than central review cycles
SaaS adoption shortens the distance between need and purchase. Product-led trials, freemium plans, and one-click integrations let teams adopt tools without procurement or security review, then connect them to data sources and workflows immediately. That creates a parallel control plane outside the formal identity programme. Once an app is embedded in a team’s work, removing it becomes harder than approving it, because access, data retention, and ownership have already spread across users and integrations.
Practical implication: map where business teams can create app dependencies without central approval, then close the gap between adoption and security review.
How SaaS sprawl turns into identity and access risk
Each new SaaS app brings users, admins, tokens, OAuth grants, and service connections. Those identities often exist outside the same lifecycle controls used for core systems, which means access can persist after a team changes tools or ownership shifts. The result is not just shadow software. It is an expanding identity surface where revocation, recertification, and least privilege are applied unevenly across human and non-human access.
Practical implication: inventory SaaS-connected identities and treat app offboarding as an access removal process, not only a software retirement task.
Why decentralised app ownership complicates governance
When department heads or employees manage software locally, IT loses the single source of truth needed for assurance. Local ownership can work for low-risk collaboration tools, but it breaks down when apps touch regulated data, payroll, customer records, or downstream automations. In practice, this means the organisation may know a tool exists but not who approved it, who administers it, or whether any dormant accounts still have access. That is a classic governance drift pattern.
Practical implication: require business-owned apps to have named technical and governance owners, plus a documented offboarding path.
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 IT is an identity governance problem before it is a software discovery problem. The article treats SaaS adoption as a usage trend, but the deeper issue is that every unsanctioned app creates identities, permissions, and lifecycle obligations outside the authoritative governance process. That is why discovery alone is insufficient: the real control failure is that access can be created faster than it is classified, reviewed, or removed. Practitioners should treat shadow IT as unmanaged entitlement creation.
SaaS sprawl: the governance surface expands when app adoption outpaces account ownership. This is the named concept the article surfaces, even if indirectly. Once teams can adopt tools locally, the organisation inherits fragmented ownership, duplicated permissions, and inconsistent offboarding across human and non-human access. The implication is that lifecycle governance has to follow app adoption at the same speed as procurement and security review, or the control model lags the business.
Decentralised purchasing invalidates the assumption that security can govern apps after formal intake. That assumption was designed for environments where IT controlled onboarding and could inspect data flows before use. It fails when employees can trial, integrate, and operationalise SaaS before central approval. The implication is that governance cannot rely on a single gate at purchase time; it must account for post-adoption drift and local control.
Shadow SaaS also widens NHI exposure through hidden integrations. The article points to one-click connections and third-party tooling, which is where tokens, API keys, and delegated access often enter the environment. Those non-human identities are frequently created to support convenience rather than governed access, so they inherit weak visibility and uneven revocation. Practitioners should assume every unmanaged SaaS app can also be a hidden NHI boundary.
Remote work has changed the shape of governance, not just the volume of apps. The article links WFH and SaaS growth, but the important shift is that identity decisions are now happening at the edge of the organisation, not only inside it. That means IAM, IGA, and SaaS management have converged into one assurance problem. Teams that still separate them will keep finding access issues after the fact instead of preventing them.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
- That confidence gap makes Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs the next practical reference point for teams tightening discovery, ownership, and revocation.
What this signals
Shadow SaaS turns access governance into a distributed control problem. When employees can create app dependencies faster than central teams can classify them, the programme needs discovery, ownership, and revocation to operate as one system. The useful next step is to align SaaS inventory with Ultimate Guide to NHIs lifecycle thinking and with the NIST Cybersecurity Framework 2.0 govern and protect functions.
Shadow SaaS also exposes hidden non-human identities. Every unreviewed integration can create API tokens, service accounts, or delegated OAuth grants that outlive the business need. Teams should assume the unmanaged app is also an unmanaged identity boundary, then use the Top 10 NHI Issues to prioritise visibility, rotation, and offboarding work.
Remote work is not just increasing app counts, it is shifting control decisions to the edge of the organisation where informal adoption happens first and governance happens later. That means the programme question is no longer whether shadow IT exists, but how fast identity, data, and access controls can catch up once it does.
For practitioners
- Build a shadow SaaS inventory from identity and network signals Correlate SSO logs, OAuth grants, DNS, finance records, and browser telemetry to find apps adopted outside procurement. Treat the inventory as a living control surface, not a one-time audit artefact.
- Classify app ownership by business function and access risk Assign a named owner, data classification, and review cadence to every SaaS app that stores or processes company data. Separate collaboration-only tools from apps that hold regulated or customer information.
- Tie SaaS offboarding to entitlement revocation When a team drops a tool, remove admin roles, revoke OAuth grants, delete service accounts, and confirm data export or retention handling. Offboarding is incomplete until the app no longer has active access paths.
- Require security review before integration activation Block new integrations until the app has been vetted for data exposure, compliance impact, and delegated access scope. One-click connectivity should not bypass control just because adoption is low friction.
Key takeaways
- Shadow IT becomes an IAM problem when SaaS adoption creates identities and entitlements outside formal governance.
- The article’s core signal is visibility loss, with 57% of IT leaders already concerned and 76% of employees preferring remote work.
- Teams should connect app discovery to offboarding, delegated access revocation, and named ownership before local adoption becomes permanent sprawl.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Shadow IT creates unmanaged business and technology risk that needs governance. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Untracked SaaS integrations create hidden non-human identities and delegated access. |
| NIST Zero Trust (SP 800-207) | AC-4 | SaaS access should be constrained even when apps are adopted outside IT. |
Inventory tokens, API keys, and service accounts tied to SaaS apps and revoke them when apps are retired.
Key terms
- Shadow IT: Software, services, or hardware used without the knowledge or approval of the central IT team. In identity terms, it creates unmanaged accounts, access paths, and support obligations that sit outside normal governance, making later review and offboarding much harder.
- SaaS Sprawl: The uncontrolled spread of software-as-a-service tools across teams and departments. It is not just an application inventory problem. It is a governance problem because every new app can introduce users, permissions, integrations, and retention requirements that no one is tracking end to end.
- Delegated Access: Access granted indirectly through an app, integration, or OAuth consent rather than by direct human administration. This matters because delegated access can persist after the original business need changes, which makes revocation and ownership tracking central to identity governance.
- Non-Human Identity: Any identity used by software, services, or automation rather than a person. In SaaS environments, that includes API keys, tokens, service accounts, and integration credentials that must be inventoried, governed, and removed with the same discipline as user accounts.
Deepen your knowledge
Shadow IT, SaaS sprawl, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring unmanaged apps and delegated access back under control, it is worth exploring.
This post draws on content published by Zluri: Security & Compliance, What is Shadow IT? How SaaS Apps are Driving the Next Wave of Shadow IT. Read the original.
Published by the NHIMG editorial team on 2026-03-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org