SaaS-to-saas integrations are expanding NHI governance gaps

At a glance

What this is: This is a SaaS security analysis showing that SaaS-to-SaaS integrations create NHI governance gaps through decentralized ownership, excessive access, and stale credentials.

Why it matters: It matters because IAM, IGA, and SaaS security teams need lifecycle governance for service accounts, API keys, and OAuth tokens before business-led integrations become unmanaged trust paths.

By the numbers:

• The 2024 State of SaaS Security Report found 8.6 non-human identities for every human identity on average.
• The 2024 State of SaaS Security Report found that 33% of integrations have access to sensitive data.
• Valence Security says its remediation workflows helped revoke 95% of obsolete or inactive tokens at Lionbridge almost immediately.

Context

SaaS-to-SaaS integrations are a non-human identity problem first and a tooling problem second. Every connected application introduces service accounts, API keys, or OAuth tokens that can outlive the workflow they were created to support, especially when business units adopt tools without central security oversight.

The governance gap is not simply that teams cannot see these integrations. It is that decentralized ownership fragments lifecycle control, so access decisions, offboarding, and monitoring sit outside a single accountable process. That makes least privilege harder to maintain and stale access easier to miss.

In practice, that means the security programme has to treat integrations as governed identity relationships, not as one-time connectivity events. The article’s examples are typical of SaaS sprawl, where business-led adoption expands both the number of NHIs and the number of places where access can drift.

Key questions

Q: What breaks when SaaS integrations are not governed as non-human identities?

A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls. The practical failure is blast radius, not just access. One over-scoped token or service account can expose multiple downstream platforms, especially when ownership, rotation, and review are missing.

Q: Why do overprivileged SaaS integrations and accounts create more security risk than teams often expect?

A: Excessive access expands the attack surface and makes abuse harder to contain. In SaaS environments, permissions can outgrow the original use case, especially after job changes or informal onboarding of integrations. When roles, scopes, or admin rights are broader than needed, a compromised account or app can expose data, alter settings, or move laterally across connected services.

Q: How should security teams detect stale or inactive SaaS credentials?

A: Track last-use signals, owner status, and business purpose for each integration credential, then flag anything that remains valid after the application stops using it. A credential that is still authorised but no longer active is an offboarding failure, not a harmless leftover.

Q: What is the difference between integration visibility and integration governance?

A: Visibility tells you which SaaS connections exist. Governance tells you who owns them, what they can access, when they should be revoked, and how their permissions are reviewed. Without governance, discovery only gives you an inventory of risk.

Technical breakdown

Why SaaS-to-SaaS integrations create NHI sprawl

SaaS integrations depend on non-human identities to move data and actions between applications. In this model, a service account, API key, or OAuth token becomes the machine-to-machine trust anchor. The problem is scale: each integration adds credentials, permissions, and renewal state, often across separate business owners and admin consoles. When ownership is decentralised, no single team has a complete view of which identities exist, what they can access, or whether they are still required. That turns integrations into a distributed identity surface rather than a bounded technical feature.

Practical implication: Map every integration to the NHI it creates, owns, and authorises before you can govern it.

Over-privilege in third-party integrations

Third-party integrations often request broader permissions than the workflow actually needs because setup is designed for convenience, not governance. Once approved, those permissions can expose sensitive records across the core SaaS platform and any connected apps. Least privilege is harder here because the access grant is usually made by a business user or app admin who optimises for immediate function, not for minimum scope. Over time, integration creep accumulates in the same way privilege creep does for human accounts, except the access is embedded in machine relationships that are less visible and less reviewed.

Practical implication: Review integration scopes as access grants, not as configuration details.

Inactive tokens and lifecycle failure

An inactive integration is especially risky because the token or key may remain valid even when the application no longer uses it. That creates a standing access path with no business need behind it. Lifecycle management matters because the security issue is not only initial authorisation but also retirement, revocation, and rotation. In SaaS environments, stale credentials can persist across platform changes, admin turnover, and business-unit shadow IT. The result is a gap between perceived control and actual revocation coverage, which is why token hygiene must be treated as a governance function, not a cleanup task.

Practical implication: Build revocation into integration retirement so unused credentials do not become persistent access paths.

Threat narrative

Attacker objective: The objective is to exploit trusted SaaS integrations as durable access paths into sensitive data and connected business systems.

1. Entry occurs when a business unit connects a third-party SaaS integration using an OAuth token, API key, or service account with broad permissions.
2. Escalation follows when the integration is left active after the workflow changes, allowing the credential to retain access beyond its business purpose.
3. Impact appears when stale or over-privileged machine access is abused to reach sensitive SaaS data or move between connected applications.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

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

NHI Mgmt Group analysis

Decentralised SaaS ownership creates an identity governance gap, not just a visibility gap. When marketing, sales, HR, or R&D can connect tools without central review, the security programme loses control of who authorises machine access and who retires it. That breaks the assumption that every productive integration passes through a governed identity lifecycle. The implication is that SaaS sprawl has to be treated as distributed access governance, not app inventory management.

Over-privileged integrations are a form of machine privilege creep. The issue is not that integrations exist, but that they often inherit or request permissions far beyond the minimum workflow requirement. That creates persistent blast radius across SaaS platforms because the access is hidden inside approved connections rather than visible user entitlements. Practitioners should view integration scope as a privileged-access problem that demands review, segmentation, and ownership clarity.

Inactive tokens expose a lifecycle failure that most identity programmes still underweight. A token can remain valid long after the business use case disappears, which means revocation discipline matters as much as initial approval. This is where SaaS security, IAM, and IGA converge: the machine identity must have an owner, a purpose, and a retirement condition. Practitioners need to close the gap between authorisation and offboarding.

Service accounts and OAuth tokens have become the default trust fabric for SaaS-to-SaaS automation. That makes them more than operational plumbing because they now carry business risk whenever business units bypass central controls. The named concept here is distributed integration trust: trust granted across many small connections that no one team fully owns. Security teams need to govern that trust as a programme-wide control surface.

Visibility without lifecycle control is a false sense of governance. The article shows that teams may believe they manage NHIs while still leaving stale access, excessive permissions, and weak offboarding intact. That is the real operating risk for SaaS security programmes. Practitioners should measure governance by revocation and scope control, not by discovery alone.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Distributed integration trust: SaaS programmes need to treat every third-party connection as a governed identity relationship, because decentralised ownership makes privilege creep and revocation gaps inevitable unless ownership and retirement are explicit.

The clearest operational signal is not how many integrations exist, but how many still have valid access after the business use case has changed. That is where SaaS security, IAM, and IGA have to meet on the same lifecycle control surface.

For practitioners

• Map every SaaS integration to its owning business function Create an inventory that ties each third-party integration to the business owner, the technical owner, and the NHI used for access. Use that map to identify orphaned or shared credentials and to assign a clear offboarding path.
• Enforce least privilege on integration scopes Review OAuth grants, API key permissions, and service account roles as privileged access decisions. Remove scopes that are not required for the workflow and separate read, write, and admin access where the platform allows it.
• Require lifecycle revocation for inactive integrations Set retirement criteria for integrations and revoke the associated token or key when the business use case ends, the vendor relationship changes, or the application is no longer in use.
• Add continuous monitoring for abnormal NHI activity Watch for new connections, unusual token use, configuration drift, and access from dormant integrations. Feed those signals into SaaS security posture management and identity threat detection workflows.
• Tighten third-party assurance before integration approval Assess the vendor’s data handling, access controls, and incident response posture before allowing new SaaS-to-SaaS connections to go live, especially when sensitive data is in scope.

Key takeaways

• SaaS-to-SaaS integrations widen the attack surface because they multiply service accounts, API keys, and OAuth tokens outside central oversight.
• The core evidence is lifecycle drift: inactive integrations can remain authorised, and sensitive access can persist long after the business need has ended.
• Security teams need ownership mapping, least privilege review, and revocation at retirement if they want integration sprawl to stay governable.

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.
• Distributed Integration Trust: A condition where many business-managed SaaS connections each carry their own access grants, but no single team fully controls the whole trust chain. It becomes a governance problem when the permissions, owners, and revocation state are spread across departments and admin consoles.
• Inactive Integration: A SaaS connection whose credential is still valid even though the application no longer uses it. These stale relationships are risky because they preserve access without current business purpose, making revocation and audit evidence the critical controls.
• Machine Privilege Creep: The gradual expansion of permissions granted to non-human identities over time, usually through convenience-driven integration setup or neglected reviews. In SaaS environments, it often appears as broader-than-needed OAuth scopes, service account roles, or API permissions.

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.