The Security Risks of Third-Party SaaS Sprawl

Ask most IT teams how many SaaS applications their organisation uses. They’ll give you a number. Then ask them how many applications are actually connected to company data, processing company email, or authenticating with company credentials.

The second number is almost always significantly larger than the first. Sometimes by an order of magnitude.

This gap between the SaaS tools an organisation knows about and the ones it doesn’t is one of the more consistently underestimated attack surfaces in modern enterprise security. It doesn’t require a sophisticated attacker to exploit. It doesn’t require a zero-day vulnerability. It requires a developer who connected a productivity tool to a corporate GitHub account two years ago and has since left the company. It requires a sales rep who signed up for a prospecting tool using their work email and granted it access to their calendar and contacts. It requires an HR manager who uploaded a spreadsheet of employee salaries to an AI tool to help format a report.

None of those people did anything with malicious intent. All of them created a security problem.

What SaaS Sprawl Actually Looks Like

SaaS sprawl is the accumulation of software-as-a-service applications across an organisation, typically without centralised oversight, procurement, or security review.

It happens because SaaS tools are frictionless by design. A free trial requires only an email address. An OAuth connection to grant a new app access to Google Workspace or Microsoft 365 takes thirty seconds and a click. A file upload to a third-party service to use a particular feature requires no IT involvement whatsoever. Individual employees, teams, and departments make these decisions independently, optimising for their own productivity without visibility into the cumulative security picture.

Research consistently puts the number of SaaS applications in use at mid-sized enterprises in the hundreds. Some estimates for large enterprises go into the thousands. The IT-sanctioned list the tools that went through procurement, security review, and formal approval is typically a fraction of that total. The rest is shadow IT: applications running on company data with no formal oversight.

The problem isn’t that employees are reckless. The problem is that the security model breaks down completely when you can’t see what you’re dealing with.

The OAuth Problem

The most significant technical mechanism driving SaaS risk is OAuth, the authorisation protocol that powers those “Connect with Google” and “Sign in with Microsoft” buttons.

OAuth is convenient and, used correctly, reasonably secure. The issue is what happens when employees grant OAuth permissions without understanding what they’re authorising.

When a SaaS application requests OAuth access, it typically asks for a defined set of permissions access to email, calendar, contacts, files, or in some cases the ability to send email on behalf of the user. Most users click through these permission screens without reading them. Many applications request far broader permissions than they actually need. A tool that wants to read your calendar to schedule meetings will often ask for permissions that cover reading and sending your email as well, because the developer built the permission request to be maximally broad.

The result is a sprawl of third-party applications that have been granted significant access to corporate data access that persists indefinitely, regardless of whether the employee still works there, regardless of whether the application is still being used, and regardless of whether the vendor has since had a data breach of their own.

An attacker who compromises a SaaS vendor or finds a vulnerability in a SaaS application inherits whatever permissions that application was granted. If a poorly-secured productivity tool has read and send access to the email of fifty employees in your organisation, a breach of that tool is effectively a breach of those inboxes.

The Supply Chain You Didn’t Know You Had

Every SaaS application your organisation uses is a third party with access to your data. Every one of those third parties has their own security posture, their own vulnerabilities, their own subprocessors they share that data with in turn.

This is the SaaS supply chain, and most organisations have almost no visibility into it.

When a SaaS vendor is breached, the question isn’t just whether the vendor’s own data is compromised it’s what data belonging to their customers was accessible. The 2023 breach of Okta’s support system is instructive here. Okta is an identity provider. A compromise of systems within Okta’s support environment exposed data related to customer tenants. The breach didn’t happen within those customer organisations at all it happened at a vendor they trusted to manage authentication. The attack surface for those customers included a third party they couldn’t directly control.

This pattern repeats. An organisation invests heavily in securing its own environment and pays relatively little attention to the security posture of the dozens of SaaS vendors processing its data. Attackers increasingly understand that vendors are softer targets than their enterprise customers, and that compromising a vendor achieves the same result as compromising the customer directly access to the data.

Offboarding Failures at Scale

Employee offboarding is a known challenge in SaaS environments, but the scale of the problem is often not fully appreciated.

When an employee leaves, a typical offboarding process covers the obvious systems the corporate laptop, the email account, the VPN, the sanctioned tools in the IT inventory. What it almost never covers is every SaaS application that employee signed up for using their work email, every OAuth connection they authorised, every shared account or team login they participated in.

Some of those applications will continue to work with cached credentials or persistent sessions long after the account has been disabled. Others are tied to personal accounts using a work email address, and so aren’t disabled at all they’re just orphaned. The former employee retains access, potentially to shared workspaces, customer data, or internal communications, indefinitely.

In organisations with high turnover or rapid growth, this compounds quickly. A three-year-old company that has hired and lost a hundred employees across sales, marketing, and engineering has potentially hundreds of dangling access threads to third-party services, most of them invisible to IT.

Offboarding completeness is only as good as your inventory. If you don’t know what applications exist, you can’t revoke access to them.

Data Ends Up Where You Don’t Expect

SaaS sprawl isn’t just an identity and access management problem. It’s a data governance problem.

Employees use the tools available to them to get work done. When the approved tools don’t support a particular workflow or when an unapproved tool does something better they use what works. Data follows.

Customer records end up in a CRM that never went through a data processing agreement review. Contracts are stored in a file sharing service that isn’t subject to the same retention and security controls as the approved document management system. Employee data is processed by an HR tool that stores records in a jurisdiction with different data protection standards.

In some cases, this creates direct GDPR liability personal data being processed by a subprocessor with no data processing agreement in place, in a location that doesn’t meet adequacy requirements, with no legitimate legal basis for the transfer. The organisation is responsible for all of it, even though the data ended up there because a department head chose a convenient tool without legal or security review.

The proliferation of AI-powered SaaS tools has made this significantly worse. Employees are uploading documents, data, and internal communications to AI platforms at scale, often without understanding that doing so may train models on proprietary or personal information, or that the data may be retained and processed in ways not covered by any agreement the organisation has in place.

How Attackers Exploit This

SaaS sprawl creates exploitable conditions at several levels.

Credential reuse across platforms. If employees are signing up for SaaS tools using their corporate email address and a password rather than SSO those credentials are as secure as that SaaS vendor’s password storage. A breach of a minor SaaS tool with poor security practices can expose corporate email and password combinations. If those combinations are reused elsewhere which they often are the blast radius expands.

OAuth token theft. Applications store OAuth tokens to maintain persistent access. If a SaaS application or the device accessing it is compromised, those tokens can be extracted and used to access corporate resources email, files, repositories without ever touching the corporate identity provider. Token theft bypasses MFA because the authentication already happened when the token was originally granted.

Exposed integrations as a pivot. Many SaaS applications integrate with each other. A marketing automation platform connected to a CRM connected to a customer data platform creates a chain. If any link in that chain is compromised, an attacker can traverse it. The weakest vendor in a chain of integrations determines the effective security level of the whole chain.

Social engineering via impersonation. Attackers who know which SaaS tools an organisation uses often discoverable through job adverts, LinkedIn profiles, or simply guessing common tools by industry can impersonate those vendors in phishing campaigns. A convincing “Your [Known Tool] account requires re-authentication” email is a more credible pretext than a generic phishing attempt.

Getting It Under Control

The scale of the problem can make it feel unmanageable, but there are practical starting points.

Discover what’s actually in use. This requires tooling that goes beyond the IT asset register. SaaS discovery tools work by analysing network traffic, SSO logs, or browser extensions to identify what applications employees are actually connecting to. The results are often a significant surprise. You cannot manage what you cannot see.

Enforce SSO wherever possible. If every SaaS application authenticates through a corporate identity provider, offboarding becomes tractable disabling the identity provider account cuts access across every connected application simultaneously. Many SaaS vendors support SAML or OIDC integration. Prioritise SSO enforcement for applications with access to sensitive data.

Audit OAuth permissions regularly. Both Google Workspace and Microsoft 365 provide administrator visibility into OAuth applications connected to accounts in the tenant. Review this list, identify applications with excessive permissions, revoke access to applications that are no longer in use, and restrict which applications employees are permitted to authorise without IT approval.

Apply a data classification lens. Not every SaaS tool is equally risky. An application that accesses nothing beyond user identity is a different risk profile to one that reads email and files. Prioritise scrutiny for tools that touch the most sensitive data categories.

Establish a lightweight approval process. A security review that takes two weeks and requires a twelve-page questionnaire will be circumvented. A review that takes two days and focuses on the questions that actually matter what data does this tool access, where is that data stored, what does the vendor’s security posture look like, is there a DPA in place can work at the speed employees expect while catching the most significant risks.

Takeaways

SaaS sprawl is a structural feature of how modern organisations operate. It isn’t going away, and it can’t be solved by trying to lock everything down that approach just pushes usage underground. The goal is visibility and proportionate control.

• The gap between the SaaS tools an organisation knows about and the ones in actual use is where most of the risk lives
• OAuth permissions granted without oversight create persistent third-party access that survives employee departures and vendor breaches
• Every SaaS vendor is a node in your supply chain their security posture affects yours
• Offboarding completeness is impossible without a complete inventory of what employees are connected to
• SaaS discovery, SSO enforcement, and OAuth audits are the three controls that move the needle most quickly

The attack surface is as large as the number of third-party applications with access to your data. For most organisations, that number is larger than anyone in the building currently knows.