SaaS vendor security exposes the governance gap in shared access

At a glance

What this is: This is an analysis of SaaS vendor security risk, arguing that shared access, OAuth exposure, and weak defaults turn SaaS ecosystems into concentration points for compromise.

Why it matters: It matters to IAM and NHI practitioners because SaaS integrations, tokens, and service access now behave like high-impact non-human identities that need the same governance discipline as privileged accounts.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Valence Security's analysis of SaaS vendor security and shared access risk

Context

SaaS vendor security is really an identity governance problem: once a provider, plugin, or OAuth-connected app is trusted, it can inherit broad access without the controls teams would apply to a human administrator. That gap matters because a compromise in one shared service can propagate into many customer environments.

The article uses high-profile breach examples and a CISO warning to show that speed, convenience, and insecure defaults have outpaced the way enterprises assign, review, and revoke non-human access. That starting position is common, which is why the issue belongs in IAM, NHI governance, and third-party risk discussions at the same time.

Key questions

Q: How should security teams govern SaaS integrations that hold delegated access?

A: Treat each SaaS integration as a governed non-human identity. Assign an owner, define its approved scopes, review it on a schedule, and revoke access when the use case changes. The main control goal is to prevent trusted integrations from becoming dormant, over-privileged, or invisible.

Q: Why do SaaS vendor breaches create such a wide blast radius?

A: Because SaaS services often reuse trust across many customers and workflows. A compromise in one provider can expose tokens, data, or downstream actions in multiple environments at once. Teams should evaluate the propagation path of trust, not just the direct permissions on a single app.

Q: What is the difference between SaaS security posture and SaaS identity governance?

A: Security posture focuses on configuration and technical controls such as MFA, logging, and default settings. Identity governance focuses on who or what has access, why that access exists, and when it should be removed. You need both, because strong settings do not fix uncontrolled trust relationships.

Q: When should organisations revoke an OAuth grant or third-party app permission?

A: Revoke it when the business owner cannot justify the access, when the app is unused, when scopes exceed the current need, or when the provider cannot meet your security baseline. Dormant consent is still active risk, and expired business purpose should mean expired trust.

Technical breakdown

OAuth-connected SaaS access as an NHI risk surface

OAuth-connected SaaS applications often act like durable non-human identities. They carry delegated authority, refresh tokens, and API permissions that can survive long after the original use case has changed. The core failure is not OAuth itself, but the way organisations grant broad consent, fail to scope tokens tightly, and rarely revisit app trust. In practice, a “read-only” integration can still expose sensitive data, metadata, or downstream workflows if the token is stolen or the app is maliciously over-permissioned.

Practical implication: Treat each third-party SaaS integration as a governed identity with explicit ownership, review, and revocation rules.

Why insecure defaults and missing controls expand blast radius

Misconfigured SaaS settings become dangerous because they compound. If MFA is optional, SSO is absent, logging is weak, and privileged accounts are not separated, then one credential compromise can move from authentication failure to broad data exposure quickly. This is a shared-responsibility problem: the vendor sets default posture, but the customer must enforce the control baseline. For NHI governance, the lesson is that configuration is not a one-time hardening task. It is part of the identity lifecycle, because app permissions, tokens, and admin roles drift over time.

Practical implication: Build control checks for MFA, SSO, logging, and privileged role boundaries into every SaaS onboarding and review cycle.

Concentration risk across critical SaaS dependencies

When many organisations depend on a small number of SaaS or PaaS providers, a single provider compromise can become a multi-tenant event. That changes the threat model from isolated account abuse to ecosystem-level exposure. Attackers do not need to break every tenant separately if they can exploit shared tooling, common trust relationships, or a popular integration path. For IAM teams, this means third-party access decisions should be evaluated for systemic impact, not just local permission scope. The relevant unit of risk is the shared trust chain.

Practical implication: Rank critical SaaS dependencies by systemic blast radius, then apply tighter approval and review thresholds to the highest-impact integrations.

Threat narrative

Attacker objective: The attacker aims to turn trusted third-party access into broad, low-friction access to corporate data and workflows.

1. Entry occurs when attackers exploit a trusted SaaS or OAuth integration, often through a legacy app or weakly governed token.
2. Escalation follows when the compromised integration has broader access than administrators expected, enabling movement into email, calendars, or data stores.
3. Impact is achieved when the attacker uses that delegated trust to read or extract sensitive corporate data at scale.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared SaaS trust is now an identity problem, not just a vendor risk issue. Enterprises often classify SaaS exposure as third-party risk, but the actual control failure sits in identity, consent, and privilege management. When an app or provider holds delegated access, it behaves like an NHI with persistence and reach. Practitioners should move SaaS integrations into the same governance model used for service accounts and privileged tokens.

OAuth blindness creates a governance gap that most IAM programmes still miss. Teams can have mature human identity processes and still fail to see which apps hold active trust, what scopes they carry, or when they were last reviewed. That is the blind spot that turns convenience into exposure. The practical conclusion is that consent review, token inventory, and business ownership must be part of IAM operations.

SaaS security defaults now function as a policy control, not a feature preference. Whether MFA is enforced, logging is included, and SSO is available changes the security baseline of the entire estate. Organisations that treat those settings as optional are effectively allowing vendors to define their own control floor. Security teams should demand minimum defaults and reject services that cannot meet them.

Identity blast radius is the right concept for shared SaaS ecosystems. A single compromised app can reach multiple tenants, multiple workflows, and multiple data domains because trust is reused across the environment. That means risk scoring must include downstream propagation, not just the app's own permissions. Teams should prioritise controls that reduce blast radius before they chase more detection noise.

Third-party SaaS governance will keep merging with agentic access governance. The same problems appear when autonomous agents, integrations, and external apps all act on behalf of the enterprise without consistent oversight. The market is signalling that isolated point controls are insufficient. Practitioners should design one governance model for every non-human actor that can touch data or execute actions.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Next read: NHI Lifecycle Management Guide for operational guidance on provisioning, rotation, offboarding, and visibility.

What this signals

OAuth oversight will increasingly be measured as identity governance, not app inventory. The practical test for SaaS programmes is whether teams can answer who approved each integration, what scopes it holds, and when it was last revalidated. Once that question becomes part of identity operations, dormant trust starts to shrink and incident response becomes faster.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the likelihood that SaaS integrations are over-scoped is too high to treat as an edge case. Security teams should assume that delegated access will outlive its business purpose unless controls force renewal.

Identity blast radius: this is the governance concept practitioners should carry forward. If a single SaaS provider compromise can ripple across many customers, then resilience depends on reducing the reach of every third-party trust relationship and documenting the failure path before an incident does it for you.

For practitioners

• Inventory every SaaS integration and OAuth consent Create and maintain a complete register of all sanctioned and unsanctioned apps, including scopes, owners, token lifetimes, and business purpose. Review access on a fixed schedule and revoke anything without an explicit owner or current use case.
• Enforce a minimum SaaS security baseline Require MFA, SSO, secure logging, and separate privileged roles before approving any provider for production use. Treat missing controls as a procurement blocker, not a post-deployment cleanup item.
• Reduce OAuth blast radius Scope tokens narrowly, limit refresh token persistence where possible, and revoke unused grants quickly. Tie every approval to a named business owner so dormant integrations do not remain trusted by default.
• Classify high-dependency providers by systemic impact Rank vendors by how many workflows, users, and downstream systems depend on them, then apply tighter review and incident playbooks to the top tier. This is where shared failure would create the most damage.

Key takeaways

• SaaS vendor security is really a non-human identity governance problem because delegated trust can persist long after business need fades.
• The scale of the issue is visible in widespread OAuth visibility gaps and the high prevalence of over-privileged NHIs.
• Security teams should govern integrations like privileged identities, with explicit ownership, scoped access, and recurring revocation checks.

Key terms

• OAuth Grant: An OAuth grant is a delegated permission relationship that allows an application to act on behalf of a user or organisation. In SaaS environments, grants can persist quietly and become high-risk non-human access if scope, ownership, and expiry are not actively governed.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, and workflows exposed when a single identity is compromised. For non-human identities, it is often larger than teams expect because tokens and integrations can be reused across services and tenants.
• SaaS Security Baseline: A SaaS security baseline is the minimum set of controls an organisation requires before trusting a provider or integration. It usually includes MFA, SSO, logging, role separation, and revocation processes, all treated as conditions of access rather than optional hardening.

Deepen your knowledge

SaaS integration governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring third-party apps and service access under one control model, it is a strong fit.

This post draws on content published by Valence Security: SaaS Vendor Security Takes Center Stage. Read the original.