Third-party SaaS integrations create NHIs through OAuth tokens and API keys required for integration. These credentials are typically provisioned once, granted broad scopes, and then forgotten — persisting indefinitely. Management requires: inventorying all SaaS integrations and the credentials they hold, reviewing credential scopes against actual usage, and a decommissioning process that includes credential revocation as a required step when any SaaS tool is retired.
Why This Matters for Security Teams
Third-party SaaS integrations are one of the most common places where non-human identities expand quietly, because every connected app needs credentials, scopes, and ongoing trust. The risk is not just that an OAuth token or API key exists, but that it often outlives the business need that created it. Once an integration is installed, teams frequently stop reviewing what it can access, even as the SaaS vendor, the workflow, or the data classification changes. That is exactly how broad, forgotten privilege becomes a standing NHI problem. NHIs are often exposed to third parties, and that creates supply-chain risk that many teams underestimate, as discussed in Top 10 NHI Issues and the Ultimate Guide to NHIs. The governing principle is simple: if a SaaS tool can call an API, read a mailbox, or sync records, it is operating as an NHI and must be managed as one. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need for asset visibility and access governance, while the OWASP Non-Human Identity Top 10 highlights credential lifecycle weakness as a recurring failure mode. In practice, many security teams encounter SaaS integration abuse only after a retired app or over-scoped token has already been used for data exposure.
How It Works in Practice
A SaaS integration usually introduces at least two NHI artifacts: a bearer credential, such as an OAuth access token or API key, and a trust relationship that grants the tool access to one or more internal systems. The operational failure is that these credentials are often provisioned once, attached to broad scopes, and then left untouched. That is why current guidance suggests treating every SaaS connector as part of the NHI inventory, not as a one-time application setting. The lifecycle approach in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here: discover, classify, review, rotate, and revoke.
A practical management process should include:
- Inventory every third-party SaaS integration and map it to the credentials it holds.
- Review scopes against real usage, not the originally requested permissions.
- Prefer short-lived tokens where the platform supports them, and avoid long-lived static secrets.
- Document ownership so revocation can happen quickly when a tool is retired or replaced.
- Validate that offboarding includes both app deprovisioning and credential revocation.
This matters because NHI compromise is not rare; Oasis Security & ESG reported that 72% of organisations have experienced or suspect they have experienced an NHI breach. That figure is relevant to SaaS connectors because they are a common place for forgotten access to persist. For implementation detail, the NIST Cybersecurity Framework 2.0 supports asset management and access control discipline, and OWASP’s NHI guidance aligns with scope minimisation and secret hygiene. These controls tend to break down when the SaaS vendor has no native revocation API or when integration ownership is shared between security, IT, and business teams.
Common Variations and Edge Cases
Tighter control over SaaS integrations often increases operational overhead, requiring organisations to balance faster business onboarding against stricter review and revocation discipline. Some environments also rely on delegated admin, service-to-service sync, or marketplace apps that cannot be managed like ordinary enterprise accounts. In those cases, best practice is evolving rather than settled: current guidance suggests compensating controls such as tighter scope approval, frequent recertification, and compensating network restrictions when token revocation is not fully supported. The hardest cases are long-lived integrations embedded in automation pipelines, where the SaaS credential is stored outside a secrets manager and used by multiple downstream jobs. The 52 NHI Breaches Analysis shows how quickly forgotten machine access can become a real incident, especially when credentials are reused across tools or environments. For that reason, many teams pair NHI governance with PAM-style processes for approval and review, but there is no universal standard for this yet. The practical goal is to ensure every SaaS integration has an owner, a scope, a review cadence, and a hard revocation path before the tool becomes part of normal operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Scopes, rotation, and revocation are core NHI lifecycle weaknesses here. |
| NIST CSF 2.0 | PR.AC-4 | Access governance fits third-party integration approval and least privilege. |
| NIST Zero Trust (SP 800-207) | Zero Trust helps reduce trust in opaque third-party SaaS access paths. |
Inventory SaaS credentials, right-size scopes, and revoke tokens when integrations are retired.
