Shadow IT in SaaS is an identity governance problem

At a glance

What this is: This is a guide to shadow IT in SaaS and the article’s key finding is that unsanctioned app use creates security, compliance, and budget risk when IT lacks visibility and lifecycle control.

Why it matters: It matters because shadow apps turn access governance into a discovery problem across human, NHI, and third-party identity surfaces, where revocation, monitoring, and least privilege break down.

By the numbers:

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

👉 Read Zluri's guide to shadow IT risks in SaaS environments

Context

Shadow IT is what happens when employees adopt software outside IT approval, which makes the real problem one of identity governance rather than software preference. In SaaS environments, the issue is not just unapproved applications. It is unmanaged accounts, unclear ownership, weak offboarding, and data paths that sit outside normal access controls.

That matters across human IAM, NHI governance, and third-party access because the same sprawl pattern shows up in every case: access is created locally, used informally, and removed too late. For readers who need the wider NHI baseline, the Ultimate Guide to NHIs and the Ultimate Guide to NHIs , use their lifecycle sections as the control reference point.

Key questions

Q: How should security teams govern shadow IT in SaaS environments?

A: Start by treating shadow apps as identity-bearing systems, not just unsupported software. Discover who created the account, what data it can reach, and whether the access can be reviewed and revoked. If the organisation cannot answer those three questions, the app is outside governance and should be contained until ownership is assigned.

Q: Why do unsanctioned SaaS apps create more risk than software sprawl alone?

A: Because the risk is not only the tool. It is the hidden account, the stored secret, the granted OAuth permission, and the data path that bypasses policy. Once those identities exist, they can survive offboarding, be reused across services, and expose information the organisation never formally approved.

Q: What do teams get wrong about SaaS access reviews?

A: They often review the application name but not the actual permission scope. A SaaS account with edit access, vendor delegation, or stale ownership can look harmless in an inventory while still carrying real exposure. Effective review must validate entitlement, purpose, and current business need.

Q: Who is accountable when a shadow app causes data loss or compliance failure?

A: Accountability is shared, but it must be explicit. Security owns discovery and control design, the business owner owns approved use, and the app owner or vendor relationship owner owns access cleanup. If no owner exists, the organisation has already accepted unmanaged risk.

Technical breakdown

How SaaS shadow IT creates unsanctioned identity surfaces

SaaS shadow IT is not just an application inventory gap. Every unsanctioned app creates one or more identities, including user accounts, OAuth grants, vendor access, tokens, and sometimes service integrations that IT never sees. Once those identities exist, they can carry data access, admin rights, and persistence outside central governance. The problem is amplified when employees self-provision apps with free trials or personal accounts, then later connect them to work data. At that point, access is no longer just unauthorized software use. It becomes an unmanaged identity surface with its own lifecycle, permission model, and offboarding requirements.Practical implication: map shadow apps to the identities they create, not just the software names.

Practical implication: map shadow apps to the identities they create, not just the software names.

Why browser-stored secrets and reused credentials increase exposure

The article points to a common failure mode: employees storing credentials in browsers, spreadsheets, or consumer vaults, then reusing them across multiple accounts. That pattern collapses the separation between application access, account recovery, and personal convenience. When credentials are duplicated, one compromise can expose several SaaS tenants at once, and IT loses the ability to know where the secret lives or how many services depend on it. In practice, the risk is not only theft. It is also untracked persistence, because those credentials often outlive the employee’s original intent and remain valid after the app is forgotten.Practical implication: inventory where SaaS secrets are stored and remove any credential path outside managed vaulting.

Practical implication: inventory where SaaS secrets are stored and remove any credential path outside managed vaulting.

How third-party app access breaks least privilege in SaaS

Shadow SaaS often expands through integrations, vendor access, and broad permissions granted for convenience. The article notes that external vendors may receive edit access where view access would have been enough, which is a classic least-privilege failure. In SaaS governance terms, the issue is not only who signed up for the app. It is what the app can do after it is connected, which data it can reach, and whether that access is reviewed when the business relationship changes. Without central account management, permission drift and forgotten integrations become the default state.Practical implication: review third-party SaaS grants as living identities with explicit scope, ownership, and expiry.

Practical implication: review third-party SaaS grants as living identities with explicit scope, ownership, and expiry.

Threat narrative

Attacker objective: The objective is to reach sensitive company data through identities and app links that the organisation never properly governed.

1. Entry occurs when employees or departments adopt unsanctioned SaaS applications and connect them to work data without IT vetting.
2. Escalation follows when credentials are reused, stored insecurely, or third-party vendors receive broader access than their role requires.
3. Impact appears as data exposure, compliance violations, duplicate spend, and access that persists after an employee leaves or an app is abandoned.

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 lifecycle failure before it is a software choice. The article describes employees signing up for apps outside IT control, but the deeper issue is that no governed lifecycle exists for those accounts, grants, and integrations. Once access is created locally, IT cannot reliably certify, rotate, or revoke it on schedule. The implication is that SaaS approval is really an identity control boundary, not a procurement checkbox.

Least privilege collapses when SaaS permissions are granted for convenience rather than purpose. The article’s edit-versus-view example is the right warning sign because it shows how quickly scope expands once business users self-serve access. In governance terms, the control failure is not only excess privilege. It is the absence of a reviewable decision trail that explains why the grant exists at all. Practitioners should treat every broad SaaS grant as a governance exception, not a normal operating state.

Credential sprawl is the named concept this article exposes: access that lives outside managed identity systems becomes durable risk debt. Storing secrets in browsers, spreadsheets, or personal vaults creates a hidden persistence layer that outlasts project needs and sometimes employment itself. That is why shadow IT is so hard to unwind once it embeds in workflows. The practitioner conclusion is simple: if access cannot be centrally discovered, it cannot be centrally governed.

Offboarding breaks down when IT never owned the onboarding. The article notes that former employees may still have access and that personal app accounts can outlive the organisation’s ability to recover data. That is not a narrow leaver problem. It is a joiner-mover-leaver gap created by decentralised app adoption. The implication is that offboarding controls must extend to SaaS accounts and integrations the business created outside standard intake.

Shadow IT reveals how human convenience, NHI sprawl, and third-party access converge into one control problem. Employees want easier tools, SaaS vendors get connected quickly, and the organisation inherits identities it never fully mapped. That cross-domain pattern is why NIST Cybersecurity Framework 2.0 style governance needs to be paired with SaaS discovery and identity ownership. The practitioner conclusion is that modern IAM has to govern the app, the account, and the grant together.

From our research:

• From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why shadow access persists after teams lose visibility.
• For a broader control baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that shadow apps routinely bypass.

What this signals

Shadow SaaS now needs to be managed as a discovery and entitlement problem at the same time. The organisations that treat unsanctioned apps as a procurement issue will keep missing the account, token, and sharing layers that actually carry the risk. That is why SaaS inventory, OAuth review, and offboarding discipline now need to sit in the same operating model as access governance.

The practical shift is toward continuous visibility, not periodic clean-up. If an app can be adopted in minutes and abandoned without notice, then recertification, secret handling, and vendor access review must be able to move at the same speed. Teams that cannot trace where data lives inside shadow tools will struggle to defend compliance claims or data retention commitments.

This is where the credential sprawl debt concept becomes useful: every unmanaged secret, personal vault entry, or browser-saved login adds hidden remediation cost later. Programmes that connect SaaS discovery to lifecycle controls will reduce that debt faster than programmes that only block approved-list exceptions.

For practitioners

• Build a shadow SaaS inventory from identity data Correlate SSO logs, browser telemetry, finance records, and OAuth consent data to identify apps that exist outside approved intake. Prioritise systems with data access, admin permissions, or external sharing.
• Classify every unsanctioned app by access risk Separate low-risk personal productivity tools from apps that store customer data, internal files, or privileged credentials. Use that classification to decide which apps need immediate review, containment, or retirement.
• Remove secret storage from unmanaged locations Eliminate browser-saved passwords, spreadsheets, and consumer vaults for work credentials. Move high-value SaaS secrets into managed vaults and verify that recovery, rotation, and sharing are centrally controlled.
• Review third-party SaaS grants as lifecycle-managed identities Assign an owner, purpose, expiry condition, and review cadence to each vendor integration or delegated app. Revoke edit-level access where view-only access is sufficient, especially for collaboration and file-sharing tools.

Key takeaways

• Shadow IT in SaaS becomes an identity governance issue once unsanctioned apps create accounts, permissions, and data access outside IT control.
• The article’s evidence shows that unsanctioned use is common, and the real exposure comes from secret storage, third-party access, and weak offboarding.
• Teams should connect app discovery to ownership, entitlement review, and revocation so that hidden SaaS use can be controlled before it becomes a breach or compliance event.

Key terms

• Shadow IT: Software or services adopted outside formal IT approval and governance. In identity terms, shadow IT matters because it creates accounts, permissions, secrets, and data flows that may never enter standard review, offboarding, or access certification processes.
• SaaS sprawl: The uncontrolled growth of software-as-a-service tools across teams, departments, or individual users. It becomes an identity problem when every new app adds another account, integration, or delegated grant that security teams must discover and manage later.
• Credential sprawl: The spread of passwords, tokens, and other secrets across browsers, files, personal vaults, and unmanaged systems. It increases exposure because the organisation loses visibility over where secrets live, who can use them, and whether they are still valid.
• Third-party SaaS grant: A permission or delegated connection given to an external application, vendor, or integration. These grants often outlive their original purpose unless they are assigned ownership, reviewed periodically, and revoked when the business relationship changes.

Deepen your knowledge

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

This post draws on content published by Zluri: Security & Compliance Shadow IT in the SaaS World - A Complete Guide. Read the original.