Should organisations treat SaaS integrations like non-human identities?

Why This Matters for Security Teams

SaaS integrations are not “just app connections.” They are trust-bearing identities with API keys, OAuth grants, refresh tokens, service accounts, and delegated admin permissions that can outlive the business process they were created for. When those credentials are not discovered, owned, and retired, they become quiet persistence paths. That is why NHI governance applies here, and why guidance such as the NIST Cybersecurity Framework 2.0 should be mapped to these integrations as part of normal identity control.

The risk is not theoretical. In the Salesloft OAuth token breach and the BeyondTrust API key breach, attackers demonstrated how one abused integration can expose downstream SaaS data and widen access without needing a user’s password. NHIMG research shows that 80% of identity breaches involved compromised non-human identities, which is a strong signal that integrations need the same governance discipline as service accounts and machine credentials.

In practice, many security teams encounter SaaS integration abuse only after a token has already been harvested, reused, or forgotten during a vendor change.

How It Works in Practice

Treat each SaaS integration as a workload identity with an owner, a purpose, a scope, a review cadence, and an offboarding path. That means inventorying OAuth apps, API tokens, webhook secrets, and service accounts; tying each one to a business process; and deciding whether the integration needs persistent access at all. Where possible, use intent-based authorisation and JIT credentials so the integration receives only the permissions needed for the current task, not a standing grant that can be reused indefinitely.

For mature environments, the practical model is closer to NHI lifecycle management than classic user IAM. Short-lived secrets, scoped consent, and automated revocation reduce exposure when an integration is no longer needed. Workload identity also matters here: if a platform can prove what the integration is through cryptographic identity, policy can be evaluated at request time rather than inferred from a static role. That is the direction implied by modern Zero Trust guidance and by standards-oriented thinking in the NIST Cybersecurity Framework 2.0.

• Assign an accountable owner for every integration and record the business justification.
• Separate read, write, and admin scopes so one token cannot silently expand into broad access.
• Set expiry dates on secrets and refresh tokens, then automate renewal only when the use case still exists.
• Revoke access on vendor offboarding, project closure, and incident response events.
• Monitor for unusual API volume, new geographies, and tool-chaining that indicates lateral movement.

The Snowflake breach and the JetBrains GitHub plugin token exposure both show how exposed integration secrets can become broad enterprise access paths when they are not tightly governed. These controls tend to break down in highly distributed SaaS estates because ownership is fragmented, token sprawl is invisible, and revocation depends on manual coordination across teams.

Common Variations and Edge Cases

Tighter control over SaaS integrations often increases operational overhead, requiring organisations to balance faster delivery against more frequent review, rotation, and consent management. That tradeoff is real, especially when marketing, engineering, and business operations all rely on low-friction app connections. Current guidance suggests that the answer is not to exempt these integrations, but to tier them by risk: low-risk read-only apps may use lighter review, while write-capable or privileged integrations need stronger approval, monitoring, and time limits.

There is no universal standard for this yet, but best practice is evolving toward explicit ownership, least privilege, short-lived credentials, and documented offboarding. Shared integrations are a common edge case. If multiple teams depend on one SaaS connector, access reviews should focus on the connector’s effective blast radius, not just the initial approval record. Another difficult case is vendor-managed automation, where the service provider asks for standing access. That should trigger deeper scrutiny, because the organisation is still responsible for the trust relationship even when the workload runs outside its perimeter.

For incident response, integration tokens should be treated as revocable credentials, not configuration details. If a SaaS app can call downstream systems, it belongs in the same containment workflow as any other non-human identity. The Dropbox Sign breach illustrates how quickly a single integration compromise can turn into a broader trust problem when revocation is delayed.

In practice, the organisations that manage this well do not ask whether the integration is “human” or “machine”; they ask how much trust it has, how long that trust lasts, and how fast it can be removed.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities in Salesforce?