SaaS security is an identity and configuration problem

At a glance

What this is: This is an analysis of SaaS security as an identity and configuration problem, with the key finding that most incidents stem from drift in access, settings, and integrations rather than platform exploits.

Why it matters: It matters because IAM, NHI, and human access programmes all intersect inside SaaS apps, where stale permissions and third-party connections can widen blast radius faster than teams can review them.

👉 Read Orca Security's analysis of SaaS security, SSPM, and identity risk

Context

SaaS security is the discipline of controlling access, data handling, and integrations in applications a third party hosts, while the customer still owns configuration and governance. In practice, that makes SaaS risk an identity problem first, because the most damaging failures come from who can access what, which integrations are trusted, and whether those permissions are still valid.

The shared responsibility model leaves the customer responsible for identity, sharing settings, auditability, and data governance. That is where SaaS security often fails: defaults remain unchanged, OAuth apps accumulate permissions, and access reviews lag behind the pace of app adoption. For practitioners, the question is not whether the SaaS platform is secure enough, but whether the organisation can govern the identities and integrations it has granted into that platform.

Key questions

Q: How should security teams govern SaaS app access and integrations?

A: Start by treating each SaaS app as a governed identity surface. Require a named owner for every connected app, limit OAuth scopes to the approved use case, and re-certify access on a fixed cadence. The goal is to prevent delegated access from becoming persistent access after the original business need has changed.

Q: Why do SaaS security failures so often start with identity drift?

A: Because SaaS platforms are usually not compromised through code defects first. They are exposed when sharing defaults stay open, OAuth grants expand, and access reviews do not keep pace with app adoption. Identity drift turns a trusted application into a long-lived exposure path.

Q: What do teams get wrong about SSPM and CSPM?

A: They treat the tools as separate queues instead of one exposure picture. SSPM finds misconfigurations and risky permissions inside SaaS, while CSPM shows the cloud assets and identities connected to them. Without both views, teams often remediate the symptom instead of the full attack path.

Q: How do organisations reduce SaaS blast radius after an app is deployed?

A: Use least privilege, remove unused integrations, and review connected apps before they accumulate unneeded reach. The most effective reduction comes from revoking stale delegated access and aligning each app with an explicit business owner, not from a one-time security review.

Technical breakdown

Shared responsibility in SaaS security

In SaaS, the vendor owns the platform, but the customer owns the configuration, access model, and data governance. That division matters because security controls stop at the application boundary. You cannot patch the SaaS code or rework the underlying infrastructure, so security outcomes depend on identity policy, sharing rules, connected apps, and logging. The practical effect is that many SaaS incidents are not software defects. They are governance failures that persist because no one treats SaaS configuration as part of the broader identity control plane.

Practical implication: map each SaaS application to an explicit ownership model for access, configuration, and review rather than assuming the vendor has covered those risks.

OAuth apps, permissions drift, and shadow access

OAuth-connected apps extend SaaS attack surface by granting delegated access to data and actions inside the application. The risk is not the protocol itself, but the way scopes widen over time, tokens outlive the original approval context, and unused integrations remain connected. This is why SaaS environments often develop shadow access paths that never show up in ordinary user reviews. Once a third-party app has broad permissions, it can become a persistent control bypass unless someone continuously evaluates scope, purpose, and usage.

Practical implication: inventory every connected app, review scopes against actual business need, and remove integrations that no longer have a defined owner or purpose.

SaaS security posture management and cloud posture together

SSPM focuses on misconfiguration and permission risk inside SaaS applications, while CSPM covers the infrastructure and platform layers around them. Used together, they show how a SaaS finding connects to the broader environment, including identities, workloads, and data stores. That connection matters because a SaaS issue may be low severity in isolation but high impact when paired with exposed cloud assets or sensitive data paths. The right model is not separate reporting streams, but one exposure picture across cloud and SaaS layers.

Practical implication: correlate SaaS posture findings with cloud identity and workload context before prioritising remediation work.

Threat narrative

Attacker objective: The attacker objective is to turn trusted SaaS access into durable reach across data, integrations, and downstream cloud services.

1. Entry begins when a misconfigured sharing rule, excessive OAuth scope, or unrevoked credential creates an exposure path into SaaS data and functionality.
2. Escalation follows when delegated access, stale permissions, or weak review processes let an attacker or insider expand from a single app foothold to broader data access.
3. Impact occurs when exposed SaaS data, connected systems, or regulated records are copied, modified, or used to move into adjacent cloud workloads.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

SaaS security is fundamentally an identity governance problem, not a platform problem. The vendor secures the service boundary, but the customer owns configuration, delegated access, and review discipline. That means the real exposure path is usually identity drift inside third-party applications, not application code. Practitioners should treat SaaS as part of the identity control plane, not as a separate SaaS-only exception.

Over-permissive OAuth access creates a standing delegation problem that outlives the original business need. When apps keep broad scopes after their purpose changes, the organisation inherits a permission structure that no longer matches intent. That is not just excess privilege. It is delegated access without lifecycle offboarding, and it is one of the clearest failure modes in modern SaaS environments. Practitioners need to see connected-app governance as lifecycle management, not application housekeeping.

SSPM only becomes useful when it is joined to cloud context and identity context. A SaaS misconfiguration by itself may look narrow, but its risk changes when the same identity also touches cloud workloads or sensitive data stores. That is why one isolated finding rarely tells the full story. The governance question is whether the exposure path crosses SaaS, identity, and infrastructure at the same time. Practitioners should prioritise joined-up exposure analysis over standalone point findings.

Public sharing defaults and stale access reviews expose the identity blast radius inside SaaS. Defaults that remain unchanged after deployment create open-ended reach, while delayed recertification lets access continue long after the original justification has expired. This is where SaaS programmes often underperform: they inherit human IAM review habits but do not extend the same rigor to app-level sharing and integrations. Practitioners should measure whether reviews are actually closing exposure or simply documenting it.

Connection sprawl is now a governance signal, not just an integration convenience. Every new OAuth app, API token, or admin role widens the number of paths that must be governed, monitored, and retired. That growth is cumulative, and it is rarely visible from a single dashboard. The field needs to stop treating integrations as low-risk plumbing and start treating them as first-class identity assets. Practitioners should assume that unowned connections will become unmanaged access.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: For the lifecycle controls behind SaaS access governance, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which covers provisioning, rotation, and offboarding across non-human identities.

What this signals

Connection sprawl is becoming the SaaS governance problem that most programmes undercount. Each new connected app adds another identity to inventory, another scope to review, and another revocation path to maintain. As SaaS portfolios grow, the security question shifts from whether the platform is trusted to whether the organisation can still account for every delegated connection before it becomes shadow access.

The practical signal for security teams is that SaaS review cycles need to match the pace of integration growth, not the pace of annual audit. That means pairing app inventory with access recertification, token review, and cloud context so orphaned access does not survive by default. For a broader control model, teams should anchor their programme in the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0.

For practitioners

• Inventory every SaaS integration and owner Build a register of connected apps, API tokens, and delegated accounts for each SaaS platform. Record business owner, technical owner, scope, and last review date so you can remove orphaned access quickly.
• Tighten OAuth scope and sharing defaults Review the default sharing posture for each app, then reduce scopes to the minimum required for the approved use case. Pay special attention to public link sharing, offline access, and admin-granted consent paths.
• Join SSPM findings to cloud identity context Correlate SaaS misconfigurations with the identities, workloads, and data stores that can reach them. Prioritise issues that connect a SaaS app to sensitive cloud assets rather than treating each finding in isolation.
• Re-certify third-party access on a fixed cadence Treat connected apps and external integrations like any other privileged access path. Re-approve them on a fixed schedule, and remove any connection that no longer has a documented business purpose or owner.

Key takeaways

• SaaS security failures usually come from identity drift, over-permissive integrations, and unchanged defaults rather than from platform exploits.
• The exposure is measurable in connected-app sprawl, stale delegated access, and SaaS findings that only become meaningful when joined to cloud context.
• Teams should govern SaaS like a first-class identity surface by inventorying integrations, limiting scopes, and re-certifying access on a fixed cadence.

Key terms

• SaaS Security Posture Management: SSPM is the practice of continuously checking SaaS application settings, permissions, and connected apps for risky drift. It focuses on the controls customers can actually change, such as sharing, consent, admin roles, and logging, rather than the vendor's underlying infrastructure.
• Delegated Access: Delegated access is permission granted to one application or service to act within another system on a user's or admin's behalf. In SaaS, it often arrives through OAuth or API tokens, and it becomes risky when the original approval outlives the business need or expands beyond the intended scope.
• Identity Drift: Identity drift is the gradual mismatch between current business need and the access that still exists in systems. In SaaS, it shows up as stale app consents, unused connections, over-broad roles, and sharing rules that remain in place long after deployment.
• Shared Responsibility Model: The shared responsibility model splits SaaS security between the vendor and the customer. The vendor secures the service and platform layer, while the customer remains responsible for access, configuration, data handling, and governance decisions that determine real-world exposure.

Deepen your knowledge

SaaS security governance, delegated access, and integration review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a practical control model for SaaS and non-human identities, it is worth exploring.

This post draws on content published by Orca Security: SaaS security as an identity and configuration problem. Read the original.