OWASP NHI3 Vulnerable Third-Party NHI: Practitioner Guide

Every SaaS integration, IDE extension and vendor connector you approve becomes a non-human identity that holds your credentials, and when that third party is compromised the attacker inherits everything you granted it. OWASP ranks this as NHI3:2025 Vulnerable Third-Party NHI in the OWASP Non-Human Identities Top 10. This guide explains what the risk covers, what OWASP asks organisations to do, and how to turn that into an inventory, a set of grant rules, monitoring and a vendor-breach playbook. It is written for identity, cloud and SaaS security teams and for the third-party risk owners who approve integrations. Broader OAuth app governance and vendor risk programmes have their own guides, linked below; this page stays on the identity side of the problem.

Key takeaways

The grant is the attack surface. A third-party NHI is only as dangerous as the tokens, keys and scopes you hand it, so least privilege at grant time decides the blast radius of a vendor breach.
Your credentials live in someone else's environment. OAuth refresh tokens, cloud role trusts and API keys held by a vendor are outside your rotation, logging and detection, which is why the Salesloft Drift tokens could be used for days before revocation.
Developer tooling counts. OWASP explicitly includes IDE extensions and plugins that can read code, environment variables, personal access tokens and SSH keys on a developer machine.
Prefer federated, short-lived and constrained access. Cross-account roles with an external ID, GitHub Apps scoped to selected repositories and IP-restricted connected apps all limit what a stolen vendor credential can do.
Plan the vendor breach before it happens. OWASP asks for a crisis playbook to revoke, reissue and review connected tokens; the first hours after a vendor notice are spent finding every grant that vendor holds.

What it is and who it applies to

The OWASP Non-Human Identities Top 10 (2025 edition) lists ten risks: NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI4 Insecure Authentication, NHI5 Overprivileged NHI, NHI6 Insecure Cloud Deployment Configurations, NHI7 Long-Lived Secrets, NHI8 Environment Isolation, NHI9 NHI Reuse and NHI10 Human Use of NHI. NHI3 is about identities that a third party operates on your behalf, or that third-party code uses inside your environment.

OWASP describes the risk in terms of development workflows: IDE extensions and SaaS tools often need broad access to a developer's machine and to the credentials stored there, and a vulnerability or malicious update in that component lets an attacker steal those credentials or misuse the permissions. Hard-coded secrets make it worse, because anything the third party can read, it can exfiltrate.

What falls in scope

SaaS-to-SaaS integrations: OAuth connected apps in Salesforce, Microsoft 365, Google Workspace, Slack or GitHub that hold access and refresh tokens for your tenant.
Cloud vendor roles: cross-account IAM roles, service principals and service accounts that monitoring, backup, FinOps or security vendors assume in your cloud accounts.
Vendor-held static secrets: database credentials, API keys and service tokens you paste into a BI, ETL, observability or support platform.
Developer tooling: IDE extensions, CLI plugins, CI marketplace actions and AI coding assistants running with the developer's tokens. The extension and CI angles overlap with software supply chain risk.
Agents and AI services: third-party AI agents and MCP servers granted delegated access to mail, files or code are the newest form of the same risk.

It applies to any organisation that connects external services to its systems, which in practice is every organisation. The scale differs: Datadog's State of Cloud Security 2024 found the average organisation had 10.2 third-party integration roles in AWS, linked to 2.4 vendors, before counting SaaS grants.

Structure and key requirements

The OWASP page sets out four prevention areas. The table restates them as requirements an auditor or architect can test, with the practical control behind each.

OWASP prevention area	Requirement to test	Practical controls
Vet and limit third-party integrations	Every integration has a security review before approval, least-privilege scopes, and periodic review with revocation of unused access	Admin consent workflow, scope allowlist, vendor security questionnaire covering token storage, quarterly grant review
Monitor third-party behaviour	Activity of each third-party identity is logged and baselined; third-party software is scanned for vulnerabilities and malicious behaviour	SaaS API event logs per connected app, cloud audit logs filtered by vendor role, extension and action allowlists
Use ephemeral and rotating credentials	Long-lived secrets given to third parties are replaced by short-lived credentials, and remaining secrets rotate automatically	AWS STS role assumption, Azure managed identities, workload identity federation, rotation through a secrets manager
Secure SaaS tokens	Each token is treated as an identity: scoped per app, short-lived or refreshable, inventoried, revoked when unused or suspicious, with anomaly detection and a crisis playbook	Token inventory, IP restrictions on connected apps, session timeouts, vendor-breach runbook

Example scenarios OWASP uses

IDE to repository: extensions holding GitHub or GitLab personal access tokens or SSH keys expose repositories if the extension is compromised.
Extensions with cloud keys: deployment extensions holding AWS, Azure or GCP keys could read, change or delete cloud resources.
Third-party service provider: a BI provider such as Sisense receiving privileged database credentials; a breach of the provider puts those credentials in attackers' hands.
Salesloft Drift: UNC6395 used OAuth tokens for the Drift application between 8 and 18 August 2025 to export Salesforce data and search it for credentials.

Identity and NHI requirements

NHI3 is fixed mainly by how you shape the identity you give a third party. The same vendor capability can be granted in very different ways, and the choice decides what a breach at that vendor costs you.

Integration pattern	Weaker grant	Stronger grant	Why it matters
Vendor in your AWS accounts	IAM user access key pasted into the vendor console	Cross-account role with `sts:ExternalId` in the trust policy and a scoped permissions policy	No static key to steal; the external ID blocks the confused deputy problem where another vendor customer reuses your role ARN
Code platform integration	OAuth app or a user's classic personal access token with the `repo` scope	GitHub App installed on selected repositories with read-only contents permission	GitHub documents that OAuth app tokens stay valid until revoked and reach every repository the user can, while GitHub Apps use short-lived tokens and are not tied to a user
CRM or SaaS connector	Connected app with `full` scope, usable from anywhere	Minimum scopes, IP relaxation set to enforce IP restrictions, API access granted by permission set to the integration user only	Google's guidance after the Drift campaign: stolen tokens should fail from unexpected infrastructure
Microsoft 365 or Entra ID app	Users may consent to any app for any permission not needing admin consent	User consent limited to verified publishers and low-impact permissions (`microsoft-user-default-low`), admin consent workflow for the rest	Malicious or unvetted apps cannot gain tenant data through a single user click
Data platform feeding BI or ETL	Shared admin database password	Dedicated read-only service user per vendor, key-pair or federated authentication, network policy to vendor egress ranges	A vendor breach exposes one narrow, revocable identity rather than your admin credential

Decision guidance

Federation available: always choose it over a static key. A role trust or federated identity can be cut off from your side in one change and leaves nothing reusable at the vendor.
Static secret unavoidable: create a dedicated identity per vendor, never reuse an internal service account (that is NHI9 territory), restrict it by network where the platform allows, and put it on a rotation schedule you control.
Delegated user tokens versus app identities: a token issued in a user's name inherits that user's full reach and dies or breaks when they leave. Prefer app-level identities with explicit, reviewable permissions.
Small organisations: start with the consent setting, a spreadsheet inventory of connected apps and a rule that no vendor gets an admin credential. That covers most of the exposure.
Large organisations: route approvals through a single intake that records owner, scopes, data classes and token type, feed grants into the NHI inventory automatically, and tier vendors so the ones holding write or bulk-read access get deeper review.

See the SaaS and OAuth App Governance Guide for the full consent and app review process, the Workload Identity Federation Guide for replacing vendor keys with federation, and the Third-Party Access Guide for human vendor access.

Implementation steps

Build the inventory first. Export connected apps and OAuth grants from each major SaaS platform, cross-account role trusts and federated identity providers from each cloud account, GitHub App installations and OAuth authorisations, and installed IDE extensions from endpoint management. Record vendor, owner, scopes, token type, issue date and last use.
Close the front door. Restrict user consent to verified publishers and low-impact permissions, enable the admin consent workflow, and set marketplace allowlists for IDE extensions and CI actions. Note that Microsoft documents that consent changes apply only to future grants; existing grants need a separate review.
Triage existing grants. Revoke anything unused for 90 days or with no owner. For the rest, reduce scopes, replace user-delegated tokens with app identities, and replace static keys with federated roles. Do this in pilot groups and keep a record of each revoked grant and its scopes so you can restore one quickly if a business process breaks.
Constrain what remains. Add external ID conditions to vendor role trusts, IP restrictions on connected apps where the vendor publishes egress ranges, session timeouts, and dedicated integration users with permission-set based API access.
Remove secrets from shared data. Scan CRM records, support tickets and wiki pages that integrations can read for keys and passwords. In the Drift and Gainsight campaigns the attacker searched exported Salesforce data for AWS keys, passwords and Snowflake tokens.
Turn on monitoring per integration. Log API activity by connected app or vendor role, baseline normal volume and source ranges, and alert on bulk exports, new source networks and anonymising infrastructure.
Write and test the vendor-breach playbook. Pre-build queries that list every grant a named vendor holds across platforms, assign owners for revocation in each platform, and rehearse it with a tabletop exercise. See the OAuth Token Theft Incident Playbook.
Embed it in procurement and offboarding. Add token storage, source control security and breach notification terms to vendor contracts, and revoke grants at contract end. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Evidence and assessment

What to log and watch

SaaS platforms: authentication events from each connected app, query and export events (in Salesforce, Event Monitoring including UniqueQuery events, which GTIG used to reconstruct Drift activity), and new or changed OAuth grants.
Microsoft 365 and Entra ID: consent grants, new service principals, credentials added to applications and app role assignments.
Cloud: AssumeRole calls by vendor principals, calls from vendor roles outside their normal API set, and IAM last-accessed data to find idle vendor roles.
Developer estate: extension installs and updates, new marketplace actions in workflows, and tokens created by integration accounts.
Behavioural signals: unusual user agents and scripted clients, access from Tor exit nodes or hosting providers, deletion of query jobs or logs, and record counts far above baseline.

Metrics

Metric	What good looks like
Third-party grants with a named internal owner	100 percent; ownerless grants revoked
Vendor cloud access using federation or role trust rather than static keys	Rising each quarter, with documented exceptions
Vendor roles without an external ID condition	Zero (Datadog found 2 percent of integration roles in its 2024 data lacked one)
Grants unused for 90 days still active	Zero after each review cycle
Time to enumerate and revoke all grants of a named vendor	Measured in a tabletop; hours, not days
Connected apps with full or admin-equivalent scope	Small, known and justified list

Assessment questions

Can you produce, within an hour, every token, role and key held by a given vendor?
Does each vendor review ask how the vendor stores customer tokens and protects its own source control and cloud?
Would a stolen vendor token work from an arbitrary internet address today?

Mapping to other frameworks

Framework	Reference	Relevance to NHI3
NIST CSF 2.0	GV.SC-07, GV.SC-10, DE.CM-06, PR.AA-05	Supplier risk assessed and monitored, provisions after the relationship ends, monitoring external provider activity, least-privilege permissions
NIST SP 800-53 Rev. 5	SA-9 External System Services, SR-6 Supplier Assessments and Reviews, AC-6 Least Privilege, AC-20 Use of External Systems, IA-9 Service Identification and Authentication	Controls over what external services may do, how suppliers are assessed and how services authenticate
CIS Controls v8.1	Control 15 Service Provider Management	Inventory of service providers, security requirements in contracts, monitoring and secure decommissioning
ISO/IEC 27001:2022 Annex A	5.19 to 5.22 (supplier relationships and supplier service monitoring), 5.23 cloud services	Supplier security agreements, ICT supply chain and change in supplier services
MITRE ATT&CK	T1199 Trusted Relationship, T1528 Steal Application Access Token, T1550.001 Application Access Token, T1176.002 IDE Extensions, T1195.002 Compromise Software Supply Chain	How attackers enter through vendors, steal and replay app tokens, and abuse extensions
OWASP API Security Top 10 2023	API10:2023 Unsafe Consumption of APIs	The mirror risk: trusting data and behaviour from third-party APIs

Within the NHI Top 10, NHI3 overlaps most with NHI5 Overprivileged NHI (vendor scopes), NHI7 Long-Lived Secrets (refresh tokens and keys that never expire) and NHI2 Secret Leakage (secrets readable by integrations).

Common pitfalls

Trusting the vendor's perimeter with your tokens. In the Salesloft Drift breach the attacker reached Drift's AWS environment through Salesloft's GitHub account and took OAuth tokens for many customers at once; no customer was phished.
Tokens that outlive everyone's memory. The Gainsight Salesforce breach involved 285 tokens between two and eight years old, and only about 23 percent still existed in the vendor's own systems.
Integrator-held user tokens. In the GitHub OAuth token breach, tokens stolen from Heroku and Travis CI let the attacker clone private repositories, and a live AWS key in one of them turned code theft into production access.
Incomplete rotation after a vendor incident. The Cloudflare breach followed the Okta support system breach: a handful of credentials believed unused were not rotated and became the entry point.
Revoking the app but not the secrets it could read. Revoking a connected app stops future access, but keys sitting in support cases or CRM notes the integration exported stay valid until rotated.
Ignoring the developer machine. Extension and plugin approval is often left to individual developers, while those tools run with the developer's repository and cloud tokens.

Practitioner checklist

Inventory every third-party grant across SaaS, cloud, code platforms and developer tooling, with owner, scopes, token type and last use.
Restrict user consent to verified publishers and low-impact permissions and enable an admin consent workflow.
Replace vendor static keys with cross-account roles carrying an external ID, or with workload identity federation.
Use app identities (for example GitHub Apps on selected repositories) instead of user-delegated tokens for automation.
Apply IP restrictions, session timeouts and minimum scopes to connected apps; avoid full-access scopes.
Scan data that integrations can read for embedded secrets and rotate what you find.
Log and baseline API activity per integration; alert on bulk export, new networks and anonymising infrastructure.
Maintain and rehearse a vendor-breach playbook that enumerates and revokes all grants of a named vendor.
Revoke unused grants every review cycle and at contract end.

OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide