SaaS-to-saas integrations are expanding NHI governance gaps

At a glance

What this is: This analysis shows that SaaS-to-SaaS integrations are multiplying non-human identities, widening visibility gaps, and creating persistent access risk across business-owned tools.

Why it matters: It matters because IAM and NHI teams need to govern machine access that is created outside central security workflows and often persists after it is needed.

By the numbers:

• The 2024 State of SaaS Security Report found that for every human identity, there are 8.6 non-human identities on average.
• The 2024 State of SaaS Security Report identified that 33% of integrations have access to sensitive data.
• Valence Security reported that Lionbridge revoked 95% of obsolete or inactive tokens almost immediately.

👉 Read Valence Security's analysis of secure NHI management in SaaS applications

Context

Non-human identity governance in SaaS environments is the problem of controlling service accounts, API keys, and OAuth tokens that connect business applications without the same oversight applied to people. In this article, Valence Security argues that decentralized SaaS ownership makes that problem harder because integrations are often created by business units, not by central IAM or security teams.

The core issue is not just volume. SaaS-to-SaaS connections create long-lived trust paths, broaden permissions, and make it difficult to know which integrations are still active, which are over-privileged, and which belong to abandoned workflows. That starting position is increasingly typical in modern SaaS estates, not an edge case.

Key questions

Q: How should security teams govern SaaS-to-SaaS integrations that use non-human identities?

A: Treat every SaaS integration as an identity relationship with an owner, a scope, and a lifecycle. Security teams should approve permissions before deployment, review them periodically, and revoke credentials when the business process ends. The goal is to prevent hidden trust paths from becoming standing access across SaaS platforms.

Q: Why do non-human identities create more SaaS security risk than human accounts?

A: Non-human identities often have broad machine-to-machine access, weak user-facing controls, and longer lifetimes than human sessions. In SaaS environments, that means a single token or service account can expose multiple tools, data sets, or workflows if it is over-privileged or left active after use.

Q: What is the difference between SaaS discovery and SaaS NHI governance?

A: Discovery tells you which integrations and machine credentials exist. Governance tells you who owns them, what they can access, how long they should remain valid, and when they must be revoked. Discovery is the inventory step; governance is the control and enforcement layer.

Q: When should organisations revoke a SaaS integration credential?

A: Revoke a SaaS integration credential when the integration is retired, no longer used, cannot be tied to a current business owner, or has scopes that exceed the approved use case. If a token remains valid without an active business need, it becomes unnecessary standing risk.

Technical breakdown

Why SaaS-to-SaaS integrations create NHI sprawl

SaaS integrations work by allowing one application to call another through delegated credentials, usually an API key, OAuth token, or service account. Each integration adds another identity, permission set, and lifecycle burden. The risk grows because these identities are often created outside standard IAM onboarding, then left in place after the original business need changes. If the integration is not continuously inventoried, the security team cannot tell whether access is still required, whether the token scope is too broad, or whether the account is tied to a dead workflow. That is why integration sprawl becomes identity sprawl.

Practical implication: Practitioners need a live inventory of SaaS integrations and the NHIs behind them, not a static spreadsheet.

How decentralized ownership weakens least privilege

When marketing, sales, HR, and engineering each manage their own SaaS tools, access decisions shift away from central policy enforcement. Business users tend to optimise for functionality, which often means approving broader scopes than the integration actually needs. In practice, this creates privilege accumulation across SaaS platforms, especially when one integration is reused across multiple workflows. Least privilege fails not because the principle is wrong, but because the approval path is fragmented and rarely revisited after deployment. The result is durable machine access with weak accountability.

Practical implication: Security teams should require scope review and ownership attribution before SaaS integrations are approved.

Why inactive tokens are a lifecycle problem, not just a cleanup task

An inactive API key or OAuth token is still a valid credential if it has not been revoked. That means the attack surface persists even when the business workflow has stopped using the integration. Lifecycle management is therefore central to NHI security in SaaS: discover the identity, verify ownership, confirm usage, and revoke access when the integration is retired or abandoned. Without that loop, organisations accumulate dormant trust paths that are hard to detect and easy to abuse if compromised.

Practical implication: Treat unused SaaS credentials as standing risk and automate offboarding for integrations that no longer have a business purpose.

Threat narrative

Attacker objective: The attacker wants to abuse delegated SaaS trust to reach sensitive data or privileged application functions without triggering human authentication controls.

1. Entry occurs when attackers compromise a SaaS integration, service account, or OAuth token tied to a third-party workflow.
2. Escalation follows when the compromised NHI has access to sensitive SaaS data or can pivot into another connected application.
3. Impact is data exposure, administrative access, or source code theft through trusted machine-to-machine channels.

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

Distributed SaaS ownership is now an identity governance problem, not just an application management problem. When business units can create their own integrations, the control plane for access moves away from IAM and into shadow operational processes. That weakens entitlement review, ownership clarity, and revocation discipline. Practitioners should treat SaaS procurement and integration approval as part of identity governance.

SaaS integrations create a distinct form of identity blast radius. Once an OAuth token or service account is accepted by a platform, its reach can extend far beyond the originating app. That reach is often invisible to teams that focus only on human access reviews. The practical consequence is that one over-scoped integration can expose multiple systems at once, so blast-radius reduction must be a design goal.

Lifecycle control matters more than discovery alone. Finding NHIs in SaaS is necessary, but it is not sufficient if revocation, rotation, and offboarding remain manual. The article’s Lionbridge example shows how remediation workflows can remove obsolete tokens quickly when ownership is clear. Security teams should use that pattern to move from identification to enforced closure.

Secure SaaS NHI management requires collaboration, but not abdication. The article rightly argues for enabling business users, yet the security team still needs policy authority over scopes, retention, and exceptions. Collaboration works only when there is a consistent control baseline. Practitioners should build guardrails that make secure integration the default path, not the optional one.

OWASP-NHI concerns are visible here even when the article does not name them. Over-privileged access, poor rotation, and weak offboarding are all present in SaaS-to-SaaS integrations. That means the category should be treated as a mainstream NHI risk surface, not a niche implementation issue. Teams that classify these integrations as ordinary app links will understate the identity threat.

From our research:

• The 2024 State of SaaS Security Report found that for every human identity, there are 8.6 non-human identities on average, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• For lifecycle control, see the Ultimate Guide to NHIs for the governance patterns that turn discovery into revocation.

What this signals

Identity ownership must follow the business process, not the application catalog. SaaS integration risk grows when procurement, configuration, and revocation are handled by different teams with no shared identity record. The practical programme response is to tie every integration to a named owner and a defined retirement rule, then audit those records as part of access governance.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, the SaaS integration problem is rarely isolated. When API keys and tokens are embedded in code, configs, or ad hoc workflows, integration sprawl becomes secret sprawl as well. That makes SaaS posture management and NHI governance inseparable in mature programmes.

Programmes should treat NIST Cybersecurity Framework 2.0 as a practical organising model for this problem. Identify the SaaS integrations, protect the credentials they depend on, detect abnormal usage, and recover by revoking stale access quickly. The control objective is not perfect visibility, but faster containment when delegated trust drifts.

For practitioners

• Inventory SaaS integrations by owning team Map every SaaS-to-SaaS integration to a business owner, technical owner, credential type, and permission scope. Include dormant and low-usage integrations so revocation candidates are visible.
• Enforce least privilege at integration approval Require each new SaaS integration to justify its OAuth scopes, API permissions, and data access before production use. Reject broad default scopes unless there is a documented exception.
• Automate lifecycle offboarding for tokens and keys Build a retirement workflow that revokes API keys, OAuth tokens, and service accounts when an integration is replaced, abandoned, or no longer owned. Tie revocation to change management and access review.
• Monitor for drift in third-party SaaS access Review integration activity and permissions continuously so that unused or over-privileged credentials are flagged before they become a breach path. Pair SaaS posture checks with NHI-specific alerts.

Key takeaways

• SaaS-to-SaaS integrations expand the NHI attack surface because business teams can create machine trust paths outside central IAM workflows.
• The scale is already material, with 8.6 non-human identities for every human identity and a third of integrations touching sensitive data.
• The control priority is lifecycle governance, meaning ownership, scope review, rotation, and revocation for every integration credential.

Key terms

• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a machine-to-machine connection that lets one cloud application access another through delegated credentials. In NHI governance terms, it creates a persistent identity, a permission scope, and a lifecycle obligation that must be reviewed like any other access relationship.
• Non-Human Identity: A non-human identity is any digital identity used by software rather than a person, including service accounts, API keys, OAuth tokens, certificates, bots, workloads, and AI agents. These identities often outnumber human users and can carry broad access if they are not governed with the same discipline.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause across systems, data, and workflows. For NHIs, the blast radius often grows quickly because one token or service account can authenticate across multiple applications, making scope control and revocation especially important.
• Lifecycle Governance: Lifecycle governance is the set of controls that track an identity from creation through active use, rotation, review, and retirement. For NHIs, it is the difference between a credential that supports a business process and one that remains valid after the process has ended.

Deepen your knowledge

SaaS-to-SaaS integration governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for business-owned SaaS estates, it is worth exploring.

This post draws on content published by Valence Security: Strengthening SaaS Applications with Secure Non-Human Identity Management. Read the original.