Notifications
Clear all
Topic starter
12/06/2026 1:24 am
TL;DR: Shadow IT in SaaS grows when employees adopt unsanctioned apps, stored credentials, and unvetted vendor access outside IT oversight, creating security, compliance, and data-loss exposure, according to Zluri. The governance gap is no longer whether people will bypass approved tools, but whether identity teams can still see, scope, and revoke the access they never approved.
NHIMG editorial — based on content published by Zluri: Security & Compliance Shadow IT in the SaaS World - A Complete Guide
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.
Questions worth separating out
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.
Q: Why do unsanctioned SaaS apps create more risk than software sprawl alone?
A: Because the risk is not only the tool.
Q: What do teams get wrong about SaaS access reviews?
A: They often review the application name but not the actual permission scope.
Practitioner guidance
- 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.
- Classify every unsanctioned app by access risk Separate low-risk personal productivity tools from apps that store customer data, internal files, or privileged credentials.
- Remove secret storage from unmanaged locations Eliminate browser-saved passwords, spreadsheets, and consumer vaults for work credentials.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Practical breakdowns of shadow IT categories across IT-managed, department-managed, and employee-purchased SaaS.
- Examples of how remote work, product-led growth, and app integrations accelerate SaaS sprawl.
- Detailed discussion of security, compliance, and financial impacts that follow unsanctioned app adoption.
- Examples of business process disruption, including collaboration inefficiency, duplicate spend, and data recovery loss.
👉 Read Zluri's guide to shadow IT risks in SaaS environments →
Shadow IT in SaaS: where IAM teams lose control first?
Explore further
12/06/2026 11:19 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow IT in SaaS is an identity governance problem
