Skip to content
Breachroad
Back to the blog
Risk management

Shadow IT: the apps IT doesn't know about

Employees use several times more applications than IT has approved. Where shadow IT comes from, what it risks and how to control it without bans.

KR
Karol Rapacz
21 May 2026 · 11 min read
Shadow IT: the apps IT doesn't know about

During audits we ask IT departments a simple question: “how many SaaS applications are used in the company?”. The typical answer: a dozen, maybe twenty. Then we look at DNS logs and corporate card statements — and find dozens to hundreds. That difference is shadow IT: tools, accounts and integrations living outside IT’s knowledge and control. It’s not a problem of bad people — it’s a problem of processes that can’t keep up with needs. But the security consequences are entirely real.

Where shadow IT comes from

The mechanism is always the same: an employee has a job to do, the official tool doesn’t exist or is inconvenient, and signing up for a SaaS takes 30 seconds. Marketing registers for a design tool, sales trials a new CRM, accounting drops files into a free PDF converter, and a developer wires production into a personal account on a monitoring service. Each of these decisions is locally rational. Globally, an unmanaged attack surface emerges.

The newest chapter of this story is shadow AI — using ChatGPT and similar tools on company data from private accounts. We covered it in our piece on AI security in business; here let’s treat it as a particularly urgent subset of the wider problem.

What it actually risks

  • Data out of control. Customer files in a private Dropbox, a contact base in an unauthorised CRM — in a breach you’re still the one liable, except you’ll be the last to know. GDPR has no concept of “but it was on the employee’s account”.
  • Accounts without MFA or off-boarding. A tool IT doesn’t know about isn’t in SSO. The password is often shared by a team, and after someone leaves, the account lives on — with their access.
  • Integrations and tokens. Plugins and OAuth apps hooked into company mail or drives (via “Sign in with Google/Microsoft”) receive persistent permissions — the consent-phishing channel we described for M365.
  • Payments and lock-in. Subscriptions on private and corporate cards nobody tracks — a cost problem, but also continuity: a business process can depend on a tool nobody inventoried (TPRM can’t cover a supplier you don’t know exists).
  • No logs. When an incident happens, the official systems show no trace — because everything happened in a tool off the radar.

How to measure the scale (before you block anything)

Discovering shadow IT is detective work across four sources:

  1. DNS/proxy/firewall logs — the list of SaaS domains your network talks to; even without expensive CASB tooling you can extract the top 100 services in use.
  2. Identity logs — in Entra ID/Google Workspace, review the OAuth apps users have consented to; it’s the fastest single source of truth about integrations.
  3. Finance — corporate card statements and expense reports filtered for subscriptions; accounting knows more about shadow IT than the SOC.
  4. A no-blame survey — a simple question to the teams: “which tools do you use for work?” with a promised amnesty. It works exactly once — don’t waste it on hunting culprits.

Compare the result with the official tool list. The difference is your backlog.

Getting control: governance, not prohibition

Experience is unambiguous: blocking alone loses. A blocked tool comes back via a private phone, a hotspot or an even less controlled alternative. The effective model has three parts:

1. A legalisation channel. A simple “I want a new tool” process: one form, an assessment in days (not months), clear criteria (where’s the data, is there SSO/MFA, will the vendor sign a DPA). Most requests can be approved with conditions; a refusal must point to an alternative.

2. A catalogue and SSO. Approved tools get wired into company sign-in (SSO + MFA), which gives you account lifecycle control (off-boarding!) and logs. Publish the “what we use for what” catalogue internally — half of shadow IT comes from not knowing an official tool exists.

3. Rules for data, not tools. A short classification policy: which data may only be processed in approved tools (customer data, finance, code) and what can go anywhere (public materials). People will remember three data categories more easily than a list of 400 allowed domains.

Support this technically: restrict self-service OAuth consents, alert on new apps in the tenant, and at larger scale bring in CASB/SSPM tooling. But the technology supports the process — it doesn’t replace it.

Shadow AI: the accelerated variant

For AI tools, apply the same model urgently: provide a legitimate alternative (business accounts with a DPA and training on your data disabled), define on one page what must never be pasted outside approved tools (customer data, code, contracts), and review OAuth consents for “AI” plugins requesting access to mail and drives. A ban without an alternative moves the problem to private phones — where you see nothing.

Frequently asked questions (FAQ)

Is shadow IT grounds for disciplinary action? In a healthy organisation — no, unless someone deliberately bypassed rules with sensitive data. People picked tools because they wanted to do their jobs well. Punishing the past kills the only cheap source of knowledge about the problem: the teams’ honesty. Amnesty plus clear rules going forward works better.

How many apps does a typical company really use? Industry research has shown the same pattern for years: the number of SaaS apps actually in use is several times higher than what IT knows about — in mid-sized companies usually hundreds. Your exact number matters less than the trend: does the gap shrink once the process is in place?

Is CASB/SSPM a must-have? Not to start. The first 80% of the effect comes from: an OAuth consent review, DNS log analysis, SSO for the top-20 tools and a legalisation channel. CASB-class tools make sense when the scale (hundreds of apps, many sites) outgrows manual work.

What about tools that can’t be put behind SSO? A risk decision: if the tool matters, mandate a password manager with strong unique passwords and native MFA, assign an owner responsible for accounts and a quarterly review. If it doesn’t matter — it’s a candidate for retirement.

How do we check whether something has already leaked through shadow IT? An OAuth consent review (especially apps with mail/drive access), an audit of sharing on company drives, and credential-leak monitoring for the company domain. We do this within a security audit — it’s often exactly where the first “surprises” turn up. Book a review.

Summary

Shadow IT won’t disappear, because its source is the pace of work, not bad intent. You can only control it with the model “an easy legal path + clear data rules + visibility”: then new tools come under control before they become risks. Start with measurement (OAuth, DNS, finance), an amnesty and a catalogue — and within a quarter the gap between “we know” and “we use” will start to close.

Share this article

Services Book a consultation