SaaS security is an identity and configuration problem

At a glance

What this is: Orca Security argues that SaaS security is primarily a problem of identity control, configuration discipline, and integration hygiene rather than platform exploitation.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat SaaS apps as governed access surfaces because mis-set defaults, stale permissions, and OAuth sprawl can widen blast radius without touching the underlying platform.

Context

SaaS security is the discipline of controlling access, configuration, integrations, and data use in applications hosted by a third party. In this model, the vendor runs the platform, but the customer still owns the identity, sharing, and governance choices that create most real-world exposure.

The governance gap is that many organisations treat SaaS as a platform problem when the dominant failure modes sit in identity and configuration drift. Once OAuth grants, sharing settings, and admin roles accumulate across apps, exposure can expand quietly even when the SaaS provider is operating correctly.

For identity teams, that makes SaaS a governance surface that sits alongside human IAM, NHI access, and cloud posture. The control question is not whether the vendor is secure in general, but whether your own access model stays aligned to least privilege after deployment.

Key questions

Q: What breaks when third-party SaaS access is never reviewed?

A: Access becomes effectively permanent, even when the vendor relationship changes or the integration is no longer needed. That creates audit failure, data exposure, and hidden attack paths through API connections and delegated permissions. The governance gap is not only trust in the vendor, but the absence of a reliable offboarding process.

Q: Why do compromised OAuth apps create such a high-risk access path?

A: Because the attacker inherits legitimate delegated access rather than forcing a fresh login or password compromise. That lets malicious activity blend into normal application behaviour, especially when permissions are broad and monitoring is weak. The risk is highest where app consent is long-lived and poorly inventoried.

Q: What are the signs that SaaS identity hygiene is failing across the organisation?

A: Common warning signs include reused or shared passwords, accounts without MFA, stale accounts that remain active, and users logging into risky or unauthorized apps. If security teams also lack visibility into shadow SaaS, the organization is likely managing identity only in the managed core while leaving meaningful exposure elsewhere. That is where compromise and credential theft often begin.

Q: How should security teams respond when a SaaS app is misconfigured but still business critical?

A: The first step is to separate business continuity from entitlement preservation. Preserve the workload, application, or user process only where necessary, then narrow sharing, reduce scopes, and remove unnecessary administrative access. The goal is to keep the service usable while shrinking the blast radius created by the misconfiguration.

Technical breakdown

How SaaS shared responsibility shifts the control boundary

SaaS changes the security model because you do not manage the underlying infrastructure or application code. The vendor owns availability, patching, and built-in platform controls, while the customer owns configuration, access policy, data handling, and connected applications. That means the highest-value controls sit above the infrastructure layer: identity provider enforcement, sharing policy, app approvals, and auditability. When security teams assume they can fix SaaS risk the same way they fix IaaS risk, they miss the only layers they actually control. The result is a governance programme that looks complete on paper but leaves permissions, integrations, and defaults untouched.

Practical implication: Map each SaaS app to the controls your team actually owns and remove any dependency on vendor defaults that you cannot verify.

Why OAuth scope and API security drive SaaS exposure

SaaS integrations often rely on OAuth, OpenID Connect, and APIs to move data and automate tasks. That convenience creates a second access plane that is easy to over-grant and hard to review. Excessive OAuth scopes, stale tokens, and unmonitored API calls can expose data even when the human user has limited direct permissions. In practice, the integration layer becomes a hidden extension of identity. If connected apps are not inventoried and reviewed, the effective access path is broader than the official role design suggests. The problem is less about the protocol itself and more about the governance gap around token scope, revocation, and connection lifecycle.

Practical implication: Treat connected apps and OAuth grants as governed identities, not as one-time setup artefacts.

Why configuration drift is the most common SaaS failure mode

SaaS controls fail when defaults remain in place after deployment and no one revalidates sharing, admin roles, or data handling settings. Public links, broad sharing, and permissive workspace defaults can expose information without triggering a classic perimeter alert. Because SaaS applications are constantly changing through new users, integrations, and feature toggles, the risk is drift rather than a single misstep. Continuous posture monitoring matters because point-in-time approval cannot keep up with the rate at which access and configuration change. In identity terms, the control weakness is not just over-permissioning, but the absence of sustained lifecycle governance over settings that behave like credentials.

Practical implication: Build recurring review cycles for sharing settings, admin roles, and connected apps, and tie them to ownership and remediation SLAs.

Threat narrative

Attacker objective: The objective is to gain sustained access to business data and workflows through trusted SaaS integrations rather than by breaking the platform itself.

1. Entry occurs through a misconfigured sharing setting, an over-broad OAuth grant, or a credential that should already have been revoked.
2. Credential access expands when tokens, scopes, or inherited app permissions expose more data than the original user role intended.
3. Impact follows as attackers or insiders use legitimate SaaS pathways to read, export, or synchronise sensitive data without touching the underlying platform.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SaaS security is now an identity governance problem, not a product category problem. Orca Security’s core finding is that the most damaging SaaS exposures come from permissions, defaults, and integration drift rather than from the SaaS platform itself. That matters because identity teams own the only levers that can actually change the exposure profile: access scope, review cadence, and revocation discipline. The practitioner conclusion is that SaaS belongs in the same governance programme as human access, NHI lifecycle, and privileged app integrations.

OAuth sprawl is a form of unmanaged delegated access. Every connected app extends the effective identity boundary of the SaaS tenant, often beyond what the original approval process intended. When scopes are broad and revocation is inconsistent, the organisation loses sight of who can do what through a token rather than a direct login. The implication is that connected app governance must be treated as identity lifecycle management, not as a side task for application owners.

Identity and configuration drift create an identity blast radius that no single SaaS control can contain. Once sharing rules, admin roles, and integration permissions accumulate across multiple applications, exposure becomes cross-domain and difficult to localise. This is where SaaS, IAM, and cloud posture begin to merge operationally. The practitioner conclusion is that blast-radius reduction, not point product coverage, should be the organising principle for SaaS risk management.

Continuous posture review is the only realistic control model for SaaS environments. Static approval at onboarding cannot keep pace with user churn, app additions, and permission changes. That makes quarterly review a floor, not a ceiling, for sensitive applications and their connected identities. The practitioner conclusion is to govern SaaS access as a living control plane, with ownership, review, and offboarding built into the operating model.

Access reviews must expand beyond people to include the integrations acting on their behalf. A human user may look low-risk while the connected OAuth app or API token actually holds the broader privilege set. That creates a gap between nominal user entitlements and effective machine-mediated access. The practitioner conclusion is that IAM and NHI governance need a shared view of who and what can reach SaaS data.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

SaaS programmes now need the same governance discipline that identity teams already apply to privileged access and machine credentials. Once connected apps and delegated tokens are part of the access model, the effective control surface extends beyond user login and into lifecycle management for every integration.

Identity blast radius: This is the practical measure that matters when SaaS apps, OAuth grants, and sharing defaults interact. The challenge is not just preventing one bad setting, but limiting how far any single misconfiguration can spread across data, workflows, and downstream integrations.

For practitioners

• Inventory connected SaaS identities Catalogue every OAuth app, API token, service account, and delegated integration attached to your SaaS estate so ownership and privilege are explicit.
• Enforce least privilege at the IdP Push authentication and authorization through a central identity provider, then remove direct SaaS grants that bypass review, MFA, and conditional access.
• Review sharing and admin defaults Check public sharing, external collaboration, and admin role assignments on a recurring cadence, with remediation tied to data sensitivity and business ownership.
• Revoke unused OAuth connections Remove stale app connections, narrow scopes on active integrations, and require reapproval when the business use case changes.

Key takeaways

• SaaS risk is dominated by identity drift, permissive sharing, and unmanaged integrations rather than by the hosted platform itself.
• A single mis-set default or connected app can create durable exposure because the effective access path often outlives the original approval.
• Identity teams need continuous review, revocation, and ownership of SaaS connections if they want blast radius to stay bounded.

Key terms

• SaaS shared responsibility model: The shared responsibility model in SaaS defines which security duties belong to the vendor and which belong to the customer. The vendor secures the platform and service availability, while the customer remains responsible for identity, configuration, data handling, and connected applications.
• Credential scope drift: Credential scope drift occurs when the access a key effectively receives at runtime is broader than the permissions intended at creation. It often shows up through weak endpoint checks, overly permissive roles, or poor revocation handling, and it turns a narrow credential into an uncontrolled access path.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.