Teams often focus on the app and ignore the identities behind the connection. In reality, tokens, service accounts, and delegated permissions are what move data, so governance must cover those identities directly. If ownership and review are missing, the trust boundary becomes invisible.
Why This Matters for Security Teams
Third-party SaaS access is usually treated as a procurement or app-integration issue, but the real risk sits in the identities that authorize the data flow. OAuth grants, API keys, service accounts, and delegated tokens can outlive the business relationship, move laterally across systems, and bypass the controls teams believe are protecting the application itself. That is why the problem belongs in identity governance, not just vendor management.
NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a clear signal that external access is now a mainstream trust boundary. The common miss is assuming the vendor’s security posture covers the customer’s token lifecycle. It does not. Once access is delegated, the customer still owns approval scope, review cadence, revocation, and monitoring of the NHI relationship. The OWASP Non-Human Identity Top 10 frames this well: identity sprawl and excessive privilege become the attack surface when machine-to-machine access is not explicitly governed.
In practice, many security teams discover the exposure only after a vendor token has already been reused, over-scoped, or forgotten during offboarding.
How It Works in Practice
The operational mistake is to review the SaaS app without reviewing the identity chain behind it. A third-party integration may look like one approved connection, but under the hood it often includes one or more OAuth consent grants, refresh tokens, API keys, SCIM connectors, mailbox delegates, or service accounts. Each of those should be treated as a separate NHI with its own owner, purpose, privilege scope, and expiry. That is the governance model NHI teams need.
Current guidance suggests mapping third-party access to a clear control set:
- Assign a named business owner for every integration, not just the application.
- Record which NHI artifact is used: token, key, service account, or delegated role.
- Limit scope to the minimum SaaS permissions needed for the task.
- Set short TTLs where the platform supports them, and rotate or revoke on change.
- Review consent, last use, and abnormal activity on a fixed cadence.
For identity lifecycle controls, NHIMG’s 52 NHI Breaches Analysis is useful reading because it shows how often simple credential and permission failures turn into broader compromise. External standards are also converging on this point. The OWASP NHI guidance and SPIFFE both reinforce that workload identity should be explicit, machine-verifiable, and decoupled from human accounts where possible. For third-party SaaS, that means preferring dedicated, auditable workload identities over shared admin logins or long-lived static secrets.
These controls tend to break down when integrations are embedded in low-code platforms or shadow-IT automation, because ownership is unclear and revocation cannot be executed cleanly without disrupting business workflows.
Common Variations and Edge Cases
Tighter control over third-party SaaS access often increases operational overhead, requiring organisations to balance visibility and revocation speed against business convenience. That tradeoff is real, especially for customer support, marketing automation, and finance systems where vendors need broad but time-bound access.
Best practice is evolving for a few edge cases. Some SaaS platforms still do not support granular scopes, short-lived credentials, or clean programmatic revocation. In those environments, teams should compensate with stronger detection, narrower network paths, and compensating manual review. For high-risk integrations, a separate tenant or isolated connector may be safer than sharing a general-purpose integration account. Where federated identity is available, use it instead of static API keys so access can be centrally revoked when a vendor relationship changes.
The key exception is when the third party itself manages the integration on behalf of the customer. Even then, the customer retains responsibility for defining the trust boundary, documenting what data the integration can touch, and proving that offboarding actually removes access. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant here: the risk is not just whether access exists, but whether anyone can say with confidence who owns it, when it expires, and how it is revoked.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers inventory and ownership gaps for machine identities. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Applies to rotation and revocation of long-lived credentials. |
| NIST CSF 2.0 | PR.AA | Identity management and authentication control third-party access paths. |
Replace static SaaS secrets with short-lived credentials and rotate or revoke on a fixed schedule.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
