in one lineShadow SaaS is every app employees use without IT review, unknown to the people responsible for securing it.
the numbers
- 305SaaS applications in the average organisationZylo SaaS Management Index, 2026
- 48%of SaaS applications sit outside IT's managementProductiv State of SaaS, 2024
- 1,000+believed under 10 apps vs 1,000+ actualAppOmni, 2024
1what it is
Shadow SaaS refers to SaaS applications that employees or teams use without going through any formal IT review or approval process. The applications are not necessarily forbidden. In most cases they are simply unknown to IT.
An employee finds a tool that solves a problem faster than the corporate alternative. A team lead signs up with a work email address. The tool connects to their Google or Microsoft account for login. Work data starts flowing in. IT never hears about it.
This is distinct from malicious activity. Employees adopting tools this way are being resourceful. The problem is that without visibility into what exists, you cannot check what data reaches it, what the vendor does with that data, or what permissions the application holds in your environment.
2why it accumulates
Shadow SaaS grows because the conditions that create it are structural.
Waiting for IT approval slows work. Department heads and individual contributors choose tools that solve today's problem quickly. The formal process, if one exists, is perceived as overhead. So the step gets skipped, once, then routinely.
Freemium tools lower the barrier further. Many business tools offer free tiers that require only an email address. No purchase order, no vendor review, no IT ticket. The tool is live in minutes.
Once in use, applications persist. Even when a team moves on from a tool, the accounts often stay open. The person who created the account has moved on or left. Nobody is watching the subscription. The application continues to exist in your environment with no current owner.
3what it costs you
The risk sits in the invisible surface area each unknown application creates.
Data exposure. Customer data, employee records, financial information, internal communications: all of it can reach an application whose vendor terms and security posture you have never reviewed. You have no DPA in place. You may not know where the data is stored or who has access to it on the vendor side.
No offboarding path. When an employee who used an unsanctioned tool leaves, IT does not know to close the account. The account stays open. If it was connected to your IdP via OAuth, the grant stays live. If it used independent credentials, the former employee can log in indefinitely.
Audit and compliance gaps. GDPR requires you to know which third-party processors handle personal data and to have agreements in place. An auditor or an enterprise customer asking about your data subprocessors expects a complete answer. Shadow SaaS makes a complete answer structurally impossible.
Security certification exposure. ISO 27001 and SOC 2 both ask about supplier management and data flows to third parties. Applications outside your inventory cannot be included in your controls. The gap appears in audits.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
Discovery works as triangulation, because no single source sees the whole surface. The IdP's OAuth grant list, pulled from Google Workspace, Okta, or Entra, shows every third-party application that connected through the directory, but it cannot show tools running on independent logins, which never touch the directory at all. Finance fills part of that blind spot: recurring charges on department cards and in expense reports, cross-referenced against the known application list, surface tools that are paid for but unregistered. Managed endpoints add the browser layer, where installed extensions often act as lightweight SaaS tools and appear in no other inventory.
The remainder is human knowledge, and it responds to tone. A short, non-judgmental questionnaire to department heads about what their teams use regularly surfaces tools that exist in no system, and it works precisely because shadow SaaS adoption is resourcefulness rather than malice. A survey that reads like an investigation teaches people to stop answering, which costs more than any individual unknown app.
What converts the findings into a control is a lightweight registry: application name, owner or team, data types involved, whether a DPA exists, whether the application connects through the IdP. A spreadsheet carries this comfortably at small scale, and a SSPM tool takes over once the environment outgrows what a spreadsheet can track. The registry matters because discovery without a record decays immediately; the same tools get rediscovered at the next audit, with the same gaps and a year more data in them.
on the record
your turn
what you can do about it
this week
Pull software purchases on company cards from last quarter.
Every unknown tool gets an owner or gets closed.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →