A permission or delegated connection given to an external application, vendor, or integration. These grants often outlive their original purpose unless they are assigned ownership, reviewed periodically, and revoked when the business relationship changes.
Expanded Definition
A third-party SaaS grant is a delegated permission that lets an external application, vendor, or integration act on behalf of an organisation’s account, data, or workflow. In NHI security, the grant matters because it behaves like an identity object with access, even when no human is actively using it.
Definitions vary across vendors, but the core risk is consistent: the grant may be scoped too broadly, refreshed automatically, or left in place after the original business need ends. That makes it different from a one-time authentication event and closer to a standing trust relationship that must be governed like any other OWASP Non-Human Identity Top 10 issue. In practice, organisations should treat the grant as part of the NHI lifecycle, with ownership, inventory, review, and revocation tied to business context. The most common misapplication is assuming a SaaS integration is harmless because it was approved once, which occurs when permissions are never revalidated after scope changes or vendor turnover.
Examples and Use Cases
Implementing third-party SaaS grants rigorously often introduces operational friction, requiring organisations to weigh integration speed against tighter approval and revocation controls.
- A sales team connects a CRM enrichment app that requests read access to contact records, then keeps that access long after the pilot ends.
- A finance workflow uses an external SaaS connector to export invoices into a reporting tool, creating a persistent data path that must be reviewed at offboarding.
- A developer grants a CI/CD platform access to cloud project metadata, and the grant remains active even after the platform is replaced.
- A vendor support tool receives delegated mailbox access for incident handling, then expands into broader visibility than the original ticketing need justified.
- Attackers abuse a compromised grant to move laterally through SaaS data, a pattern seen in incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach.
These patterns align with guidance in the Ultimate Guide to NHIs, where external exposure and lifecycle control are central to reducing shared-access risk.
Why It Matters in NHI Security
Third-party SaaS grants are a frequent source of hidden privilege because they sit at the boundary between identity governance and vendor trust. Once a grant is approved, it can bypass normal password rotation, MFA prompts, and manual oversight, especially when the integration uses OAuth scopes, API tokens, or delegated admin access. That is why the Ultimate Guide to NHIs reports that 92% of organisations expose NHIs to third parties, with only 20% having formal offboarding and revocation processes. Those conditions make grants a practical attack surface, not just a procurement detail.
Practical governance means assigning a named business owner, limiting scopes, logging consent events, and scheduling reapproval before renewal or contract changes. It also means checking whether the external app is covered by SaaS security review, data retention rules, and conditional access policies. Practitioner insight: organisations typically encounter the true risk only after a vendor relationship ends, a token is abused, or a data-sharing path is discovered during incident response, at which point the grant becomes operationally unavoidable to address.
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 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 over-permissioned NHI access and third-party grant exposure. |
| NIST CSF 2.0 | PR.AA-01 | Supports identity and access governance for external application permissions. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies directly to delegated SaaS permissions. |
Review third-party SaaS grants as access assets and validate ownership, scope, and lifecycle.
Related resources from NHI Mgmt Group
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- When should teams revoke a third-party SaaS integration?
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
- When should organisations revoke an OAuth grant or third-party app permission?
