Access becomes effectively permanent, even when the vendor relationship changes or the integration is no longer needed. That creates audit failure, data exposure, and hidden attack paths through API connections and delegated permissions. The governance gap is not only trust in the vendor, but the absence of a reliable offboarding process.
Why This Matters for Security Teams
Never reviewing third-party SaaS access turns a temporary business relationship into an open-ended trust grant. That is risky because SaaS connections often carry delegated permissions, API tokens, and service accounts that are easy to forget but hard to detect after the original business need has changed. The result is not just overexposure, but weak auditability and a persistent path for data access that bypasses normal user lifecycle controls.
NHIMG research shows the scale of the problem: only 20% of organisations have formal processes for offboarding and revoking API keys, while 92% expose NHIs to third parties. The patterns behind these failures are also visible in the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs, where missing offboarding and weak visibility repeatedly extend exposure long after the original integration should have ended.
Practitioners often assume SaaS access will be reviewed during vendor renewal, but in practice many integrations remain active because no one owns the cleanup once the initial project closes.
How It Works in Practice
Third-party SaaS access usually persists through one or more non-human identities: OAuth grants, API keys, bot accounts, sync users, webhooks, or delegated admin permissions. If those entitlements are never reviewed, the organisation loses track of what the external app can still read, write, export, or automate. That creates a silent control gap because the vendor may still have access even when the business owner believes the tool is unused.
In mature environments, review is not just a checkbox. Teams inventory every external integration, map it to an owner, confirm the business purpose, and verify the exact scopes granted. They then compare actual usage against expected usage, revoke dormant tokens, and shorten expiry windows where possible. Guidance from the OWASP Non-Human Identity Top 10 supports this lifecycle approach, because overprivileged and untracked NHIs are a common path to data exposure.
- Identify every SaaS-to-SaaS connection, including hidden app consents and service principals.
- Assign a named internal owner for each integration and require periodic recertification.
- Review scopes, token age, and last-use telemetry before each renewal cycle.
- Revoke or rotate access when the business purpose, vendor, or data classification changes.
The operational lesson is simple: offboarding must be built into the access lifecycle, not handled as an afterthought. The Salesloft OAuth token breach and the BeyondTrust API key breach both underscore how long-lived delegated access can outlive the original trust decision. These controls tend to break down when SaaS admin data is fragmented across business units because no single team can prove what external access is still active.
Common Variations and Edge Cases
Tighter review cycles often increase operational overhead, requiring organisations to balance governance depth against the speed at which teams provision new integrations. That tradeoff is real, especially in SaaS-heavy environments where marketing, finance, engineering, and support all connect tools independently.
There is no universal standard for review frequency yet. Current guidance suggests higher-risk integrations should be reviewed more often than low-risk productivity tools, particularly when they touch customer data, sensitive APIs, or administrative scopes. Some organisations use quarterly recertification for privileged or data-bearing connections and annual review for low-impact apps, but best practice is evolving.
Edge cases matter. An integration may appear dormant while still receiving scheduled exports, webhook callbacks, or background sync activity. Similarly, a vendor may have been removed from procurement records while an OAuth grant remains active in the identity platform. This is why review must include both contract status and technical access status. The NHI risk patterns described in the Ultimate Guide to NHIs — Key Challenges and Risks help explain why stale third-party access is so difficult to spot once permissions spread across multiple systems.
In practice, the hardest failures emerge when ownership is unclear and the organisation assumes procurement offboarding automatically removes technical access.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses stale non-human credentials and revocation gaps. |
| NIST CSF 2.0 | PR.AA-1 | Identity and credential management must cover external SaaS connections. |
| NIST AI RMF | GOVERN | Governance requires ownership and accountability for third-party access decisions. |
Tie SaaS app recertification to identity governance and remove inactive delegated access promptly.
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
