Who is accountable when third-party OAuth connections create NHI visibility gaps?

Why This Matters for Security Teams

Third-party OAuth connections are not just integrations. They are active identity pathways that can grant persistent access to mail, files, APIs, and SaaS data long after the original approval. That makes accountability harder to assign than with a normal user account, because the risk sits across application owners, identity teams, and vendor management. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s analysis of Klue OAuth Supply Chain Breach shows how quickly hidden authorisations become governance failures when no one owns revocation and review.

The practical issue is that OAuth consent often bypasses the usual service-account lifecycle. A vendor app can remain connected with stale scopes, excessive privileges, or no meaningful business owner watching it. NHIMG’s Top 10 NHI Issues research and the State of Non-Human Identity Security report highlight the visibility gap clearly: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. In practice, many security teams discover the issue only after a vendor compromise, not through intentional review.

How It Works in Practice

Accountability should be built around the control points that can actually see, approve, and revoke the connection. That usually means the application owner owns business need, the identity team owns policy and monitoring, and the vendor risk function owns due diligence and contract terms. Security may coordinate, but it should not be the only accountable function unless it also owns the system and the revocation path.

For operational clarity, organisations should treat each OAuth connection like a non-human identity with an owner, scope, purpose, expiry review, and rollback path. Current best practice is to record:

• who approved the integration and why it exists
• which scopes were granted and whether they match the use case
• when the access was last reviewed
• who can revoke it without waiting for a separate committee
• how alerts are generated when scopes expand or tokens are reused

This aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially least privilege, access review, and audit logging expectations, and with the 52 NHI Breaches Analysis, which shows how often hidden access paths become incident fuel. The key control is not just visibility, but named ownership with authority to act.

Teams should also require continuous inventory of approved OAuth apps and periodic recertification of each connection. If the vendor cannot explain the data path, or if the business owner cannot justify the scope, the connection should be removed or downgraded. These controls tend to break down in decentralised SaaS environments where employees can self-authorise apps faster than governance teams can enumerate them.

Common Variations and Edge Cases

Tighter approval and recertification often increases operational overhead, so organisations have to balance faster productivity against stronger control over hidden access. That tradeoff becomes sharper when business units buy SaaS directly, because the person who granted consent may leave before anyone understands the exposure.

There is no universal standard for this yet, but current guidance suggests assigning accountability based on control ownership rather than organisational hierarchy alone. For example, if a marketing team authorises a third-party analytics connector, marketing should own the business justification, IT or identity should own technical review, and vendor risk should verify contractual and security terms. The security function should enforce policy and reporting, not absorb all responsibility by default.

Edge cases include delegated admin grants, cross-tenant integrations, and “shadow IT” apps installed by individual users. In those cases, the accountable party may shift to the platform owner or directory administrator, but the principle remains the same: every active OAuth path needs one named owner, one review cadence, and one revocation authority. NHIMG’s Vercel Context.ai OAuth Supply Chain Breach and Salesloft OAuth token breach show how fast third-party access can outgrow informal oversight. Where ownership is vague, revocation usually arrives only after exposure is already public.

Related resources from NHI Mgmt Group

• Who is accountable when unsigned webhooks or legacy OAuth connections are left in place after a security alert?
• Who is accountable when insecure app-to-app connections create a supply chain exposure?
• How should security teams secure third-party connections in DevOps pipelines without creating new standing access risk?
• How do third-party SaaS integrations create NHI risk and how should they be managed?