Shadow SaaS: how unapproved apps get in and how to manage them

Your finance team pays for a tool nobody in IT has heard of. A salesperson connected a note-taking app to the company calendar with two clicks, and it now reads every meeting invite. When someone leaves, you close their email account, but you have no list of the other apps they signed into. You need to know what is in use before you can decide what to allow.

Shadow SaaS is software-as-a-service used for work without the knowledge or approval of the people responsible for IT and security. It is the cloud form of shadow IT, and it is easy to start: a work email and a card are enough. If SaaS itself is new to you, start with What is SaaS?.

Shadow SaaS in plain terms

Think of the keys to an office. Every time someone has a copy cut for a contractor or a friend, the building gets one more key you do not control. Nobody meant harm. But when you change the staff, the copies still open the door.

An OAuth grant is that copy of the key. OAuth is the standard behind buttons such as “Sign in with Google”: the app asks for access to part of your account, such as calendar or files, and keeps it until someone revokes it. The scope is which doors the key opens. A grant that reads only your name and email is a small key. A grant that reads all mail and files is a master key.

The four routes in

1. Card and expense purchases. A team lead buys a subscription on a company card and claims it on expenses. The app holds company data, and the contract sits with one person.
2. Free sign-ups with a work email. Freemium tools need only an address. Data goes in long before any money changes hands.
3. OAuth grants. “Sign in with Google” or “Sign in with Microsoft” connects a third-party app to the company account, often with access to mail, calendar or files.
4. Add-ons inside approved tools. Browser extensions, marketplace apps and integrations installed inside software you already approved.

None of these routes requires the IT team. That is why a policy that bans shadow SaaS is not enough on its own.

How to find it

No single source sees everything. The table compares four discovery methods. It is assembled from the vendor documentation cited in each row and from how each method works.

Method	What it sees	What it misses
Expense and card records	Paid apps, cost, who bought them	Free tools, OAuth grants, apps paid by personal cards
Identity provider app reports	Apps connected with the company account and their scopes. Google Workspace lists configured and accessed apps under Security > Access and data control > API controls (Google)	Apps used with a personal login or a separate password
Network and endpoint logs	Traffic to known cloud apps. Microsoft Defender for Cloud Apps matches logs against a catalog of over 31,000 apps, scored on more than 90 risk factors (Microsoft Learn)	Apps not in the catalog, which “cannot” be discovered by default, and traffic outside your network unless endpoint agents report it
Asking teams	Why each tool is used, who owns it	Anything people forget or prefer not to mention

Use at least two methods. Expenses catch paid apps; identity reports catch the free ones connected to company accounts. Microsoft’s page adds that discovery data is analyzed and updated four times a day, so network-based discovery is continuous once it is running.

How to control it

Discovery gives you a list. Control means deciding, per app, whether it stays. Google Workspace gives a clear model. Each app can be set to one of four access levels (Google Workspace admin help, as of October 2026):

• Trusted: access to all Google Workspace services, including restricted ones.
• Limited: access only to unrestricted Google services.
• Specific Google data: access only to the scopes you specify.
• Blocked: no access to any Google service.

A separate setting covers apps nobody has configured yet. Its default is “Allow users to access any third-party apps”. The other two options allow only apps that request basic sign-in information, or none at all. If you have never looked at that setting, every app your users approve is allowed today. For the wider admin model of the suite, see Google Workspace as SaaS. For what a Microsoft 365 admin owns, see Microsoft 365 as SaaS.

Worked example: cost and review effort

Shadow SaaS has a cost line as well as a risk line. Example: a labeled hypothetical. An expense review finds three teams paying separately for the same note-taking tool, 4, 6 and 9 seats, each at $10 per seat per month billed monthly.

• Seats: 4 + 6 + 9 = 19.
• Current yearly cost: 19 x $10 x 12 = $2,280.
• One company plan at a hypothetical $8 per seat per month, billed annually: 19 x $8 x 12 = $1,824.
• Saving: $2,280 - $1,824 = $456 a year, or $456 / $2,280 = 20%.

The bigger gain is control. On the company plan, the 19 accounts can sit behind single sign-on and close when someone leaves.

The review itself takes time, so size it before you start. In a company of 120 employees, suppose each person has approved 3 OAuth apps on average.

• Grants to review: 120 x 3 = 360.
• At 2 minutes per grant: 360 x 2 = 720 minutes, or 720 / 60 = 12 hours.

Twelve hours is under two working days for one person, not a project. Sorting by scope first, mail and files before profile-only grants, puts the risky ones at the top.

Checklist: the first 30 days

• Export 12 months of expense and card transactions and list every software vendor.
• Export the OAuth app report from your identity provider and sort it by scope and number of users.
• Check the setting for unconfigured third-party apps and decide whether the default stays.
• Mark each app: approved, replace with an approved tool, or block.
• Give every approved app an owner, a renewal date and a place in the offboarding checklist.
• Publish the approved list and a request form with a promised answer time.
• Repeat the expense and OAuth exports each quarter.

For the security controls a vendor should prove before an app is approved, see ISO/IEC 27017 explained.

Common mistakes

1. Blocking everything at once. Teams lose tools they rely on and move to personal accounts, which are harder to see. Why it happens: a long list of unknown apps looks like an emergency. Instead: block the high-risk scopes first and offer an approved alternative for the rest.
2. Relying on one discovery method. Network logs miss OAuth grants, and remote staff unless endpoint agents report; expenses miss free tools. Why it happens: each team owns one data source. Instead: combine expenses with identity provider reports at minimum.
3. Forgetting offboarding. A former employee’s account in an unapproved app keeps company data after they leave. Why it happens: offboarding lists only cover approved systems. Instead: add every approved app to the offboarding checklist and move shadow apps behind single sign-on.
4. Treating discovery as a one-time project. New tools arrive every month. Why it happens: the first cleanup feels like the finish line. Instead: run the expense and OAuth exports quarterly and keep the request form open.

Sources

• Google Workspace admin help, Control which third-party and internal apps access Google Workspace data, checked October 2026.
• Microsoft Learn, Cloud app discovery overview, checked October 2026.

In three sentences

Shadow SaaS is work software used without IT’s knowledge, and it arrives through card purchases, free sign-ups, OAuth grants and add-ons inside approved tools. Find it by combining expense records with your identity provider’s app report; in the example, consolidating 19 scattered seats saves 20% and reviewing 360 grants takes about 12 hours. Decide per app, block risky scopes first, give each approved app an owner and repeat the review every quarter.