SaaS integration security gaps are widening beyond traditional IAM

At a glance

What this is: This is a best-practices guide on securing SaaS integrations, centered on the finding that hidden connections often create more exposure than the applications themselves.

Why it matters: It matters because every integration is an NHI trust relationship, and those relationships can bypass MFA, SSO, and traditional app-centric controls.

By the numbers:

• The average enterprise SaaS platform now connects to 42+ third-party applications through OAuth tokens, API keys, webhooks, and automation platforms.
• 86% of organizations now prioritize SaaS security, yet most lack visibility into the integrations connecting their applications.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Obsidian Security's guide to securing SaaS integrations and hidden access paths

Context

SaaS integration security is the discipline of governing the connections between cloud applications, not just the applications themselves. In practice, those connections are often OAuth tokens, API keys, webhooks, and low-code automations that behave like non-human identities with persistent access. For IAM teams, the problem is that these bridges are frequently created outside central approval paths and remain active long after the original business need has changed.

The article argues that the largest risk sits one integration away from the core SaaS platform, because a single authorized connection can expand access far beyond what users or security teams intended. That is a familiar NHI governance pattern: access is granted for convenience, then becomes durable, distributed, and difficult to inventory. The starting position described here is common in modern SaaS estates, not an edge case.

Obsidian Security's guide also points to a practical shift in control design. Security teams need to understand integration classes, permission scope, and behavioral drift, because inventory alone does not show whether an integration is healthy or compromised. In NHI terms, the question is not whether the token exists, but whether its standing access still matches business purpose.

Key questions

Q: How should security teams govern SaaS integrations that use OAuth tokens?

A: Treat OAuth grants as non-human identities with standing access. Assign an owner, record the scopes, set a review cadence, and define how the token is revoked if the business purpose changes. The goal is not to block integrations, but to make their access visible, bounded, and removable.

Q: When does a SaaS integration become too risky to keep?

A: An integration becomes too risky when it has broad scopes, no clear owner, no recent use, or access to sensitive data that exceeds its purpose. If the token cannot be justified, monitored, and revoked quickly, the cost of keeping it usually exceeds the business value.

Q: What is the difference between inventory and behavioral monitoring for integrations?

A: Inventory shows what exists, who owns it, and what it can access. Behavioral monitoring shows whether the integration is acting normally, such as reading expected data at expected times, or whether its use has drifted in ways that suggest compromise or abuse.

Q: How do organisations reduce SaaS integration blast radius?

A: Reduce blast radius by limiting permissions, isolating high-risk connectors, and removing transitive trust wherever possible. If one integration can reach many downstream systems, compromise spreads quickly. The right design is to make each connection narrow, short-lived where possible, and easy to revoke.

Technical breakdown

OAuth tokens as bearer credentials in SaaS integrations

OAuth tokens are bearer credentials, which means possession is enough to use them. After an initial authorization flow, access and refresh tokens can continue operating without repeated MFA or SSO prompts. That makes them different from interactive human authentication, where session controls and step-up checks can interrupt risky behavior. In SaaS integration security, this is the key architectural shift: an approved connection can keep reading, writing, or exporting data even after the original user context changes. Refresh tokens extend that window further, which is why token theft often outlasts password resets.

Practical implication: Treat OAuth grants as standing NHI access and review scope, lifetime, and revocation paths as part of access governance.

Why integration sprawl creates hidden blast radius

SaaS environments accumulate native connectors, iPaaS flows, custom APIs, and user-authorized third-party apps. Each one expands the identity surface, but the risk grows nonlinearly when integrations chain together. A compromised automation platform can inherit tokens for many connected services, while a custom API script may expose broad privileges if it was built without review. The technical failure mode is not just excess access. It is transitive trust, where one approved connection becomes a bridge into several downstream systems that were never evaluated as a single attack path.

Practical implication: Map transitive access paths so you can see how one compromised integration could reach multiple SaaS systems.

Behavioral detection versus static inventory for integration risk

Inventory tells you what is connected, but not whether the connection is behaving normally. Behavioral detection looks for unusual token use, abnormal data movement, strange API calls, or access patterns that diverge from the integration's baseline. That matters because a legitimate SaaS integration can become malicious without changing its name, owner, or declared scope. Static inventories also struggle with shadow SaaS, stale authorizations, and citizen-built automations that never passed through IT review. Monitoring for drift is therefore a control for both compromise and misuse.

Practical implication: Pair integration inventories with behavioral alerts so you can identify abuse before a token is used for exfiltration.

Threat narrative

Attacker objective: The attacker wants durable access to SaaS data and downstream workflows through a trusted integration path rather than a direct login.

1. Entry occurs when an attacker compromises a third-party SaaS vendor or steals an OAuth token, API key, or automation credential tied to an authorized integration.
2. Escalation follows as the token grants persistent access to linked SaaS data without triggering MFA, allowing the attacker to move through connected workflows.
3. Impact comes when the attacker exports data, modifies records, or uses the integration path to reach multiple downstream customer environments.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Integration security is now an NHI governance problem, not just a SaaS admin problem. SaaS connections increasingly behave like non-human identities because they hold persistent access, carry scopes, and operate outside normal user sessions. That means IAM teams have to govern authorisation, revocation, and review across software-to-software trust relationships, not just human accounts. The control question is whether each integration still has a valid business purpose and a bounded blast radius.

OAuth persistence creates what we call integration trust debt. Every long-lived token, over-scoped connector, or forgotten automation adds future risk that is cheap to create and expensive to unwind. The debt compounds when business users can authorise tools without central oversight, because the organisation inherits durable access paths it did not design. Practitioners should assume dormant integrations remain part of the attack surface until explicitly removed.

Behavioral governance must complement inventory if teams want to detect abuse early. A static list of integrations cannot tell you when a legitimate token starts downloading atypical data or calling unfamiliar endpoints. Security programmes need policy, telemetry, and revocation workflows that treat integration drift as a control failure. The practical conclusion is simple: discovery is necessary, but continuous monitoring is what makes discovery actionable.

Least privilege is the only scalable response, but it has to be enforced at the integration layer. The article reinforces a broader NHI pattern seen across SaaS and AI systems: the most dangerous access is often the access granted for convenience. Security teams should downscope permissions, time-box approvals where possible, and separate high-risk connectors from low-risk ones. Without that, SaaS integration security remains a reactive audit exercise rather than an operating model.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• The pattern extends beyond code repositories, which is why teams should also examine Guide to the Secret Sprawl Challenge for lifecycle controls and revocation practices.

What this signals

Integration trust debt: long-lived OAuth grants and automation tokens create standing access that accumulates faster than most governance teams can review it. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader lesson is that machine-facing trust paths are expanding faster than conventional review cycles can absorb. Teams should align integration governance with NIST Cybersecurity Framework 2.0 and make revocation as routine as authorization.

The practical programme shift is toward continuous discovery plus continuous validation. Static inventories will still matter, but they need to be paired with telemetry, owner attestation, and removal workflows that can collapse dormant access quickly. That is especially true for high-value SaaS systems where one connector can expose several downstream datasets through legitimate workflows.

As SaaS estates absorb more agentic automation, the control model should converge with OWASP Non-Human Identity Top 10 thinking: scope minimisation, lifecycle control, and visibility into hidden trust relationships. The organisations that operationalise those controls now will be better positioned when integration paths start carrying AI agent permissions as well as human-delegated access.

For practitioners

• Inventory every SaaS integration and owner Build a living register of native connectors, OAuth grants, iPaaS flows, custom APIs, and low-code automations. Include business owner, data accessed, scopes granted, and last-verified use so stale access can be removed quickly.
• Downscope OAuth and API permissions Review each integration for minimum necessary permissions, then remove write, admin, and broad-read scopes that are not required for the workflow. Prioritise tokens that can access email, files, customer records, or security settings.
• Add behavioral monitoring for integration drift Alert on unusual token usage, new geographies, abnormal data pulls, and access at odd times. Use those signals to distinguish legitimate automation from compromised or repurposed credentials.
• Revoke dormant and orphaned connections Run quarterly reviews for integrations with no business owner, no recent activity, or no documented justification. Remove tokens tied to departed employees and retire automations that were built for one-off projects.
• Separate high-risk connectors from routine workflows Apply stricter approval, logging, and review to integrations that can read mail, modify files, or export customer data. Treat those permissions as privileged access, not routine app setup.

Key takeaways

• SaaS integrations have become a non-human identity problem because the access they create is persistent, delegated, and often invisible to traditional IAM controls.
• The scale of the issue is expanding quickly, with the average enterprise SaaS platform now connecting to 42+ third-party applications and many of those links operating outside central review.
• The right response is not only discovery but lifecycle control, including least privilege, behavioral monitoring, and rapid revocation of stale or over-scoped connections.

Key terms

• SaaS Integration Security: The practice of governing the trust relationships between cloud applications, including OAuth grants, API keys, webhooks, and automations. It focuses on how software connects, what data those connections can reach, and how quickly access can be reduced or revoked when the business need changes.
• Bearer Credential: A credential that grants access to whoever possesses it, without requiring proof of the original user at use time. In SaaS integrations, bearer credentials are risky because theft, leakage, or accidental sharing can create durable access that bypasses normal interactive authentication controls.
• Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
• Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.

Deepen your knowledge

SaaS integration security and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with OAuth grants, API keys, and automation sprawl, it is a practical place to build a control model.

This post draws on content published by Obsidian Security: Integration Security for SaaS Applications: Best Practices Guide. Read the original.