Who is accountable when a third-party connector expands the identity attack surface?

Accountability should sit with the business owner of the integration and the identity team that approved the trust relationship. If a connector can expose data or extend access, it needs a named owner, an approval record, and a revocation path when the relationship changes.

Why This Matters for Security Teams

A third-party connector is not just an integration choice. It is a trust extension that can inherit data access, tool execution, and sometimes delegated identity privileges. That means accountability has to follow the trust boundary, not the code repository. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is why connector risk is a supply chain and identity governance issue at the same time.

The common failure is assuming the vendor or platform team owns the risk by default. In practice, the business owner who wants the integration and the identity team that approves the trust relationship both have accountability, because one defines the operational need and the other defines whether the access model is safe. If the connector can read data, create sessions, or trigger downstream actions, it has expanded the attack surface and needs explicit ownership, documented scope, and a revocation path. The OWASP Non-Human Identity Top 10 treats over-privileged machine access as a core control problem, not an abstract policy concern. In practice, many security teams discover the accountability gap only after a connector has already been granted broad access and used outside its intended workflow.

How It Works in Practice

Accountability should be assigned at three levels: business ownership, technical approval, and operational control. The business owner defines why the connector exists and what outcome it is allowed to support. The identity team validates the trust relationship, scopes the permissions, and determines whether the connector uses a service account, OAuth delegation, workload identity, or another pattern. The operational team then monitors usage, rotation, and offboarding. This creates a clear chain of responsibility when a connector expands access unexpectedly.

Practitioners should treat connector onboarding like a privileged access decision, not a procurement checkbox. Current guidance suggests the following controls:

• Assign a named owner for every connector, including a backup approver and an expiry date for the trust relationship.
• Document the minimum data sets, APIs, and downstream systems the connector may touch.
• Use short-lived credentials or scoped tokens where possible, rather than long-lived shared secrets.
• Require revocation steps that can disable the connector without waiting for vendor intervention.
• Log approval, refresh, and access events so the business owner and identity team can both answer for changes.

NHIMG research highlights why this matters: the 52 NHI Breaches Analysis shows how machine identities often become the weak link when access is not tightly governed. For implementation detail, CISA threat guidance and the CISA cyber threat advisories are useful for understanding how attackers abuse trusted connections and legitimate access paths.

These controls tend to break down when connectors are deployed inside low-code platforms or SaaS ecosystems with weak identity telemetry, because ownership, entitlement changes, and revocation events are often split across multiple admins and vendor consoles.

Common Variations and Edge Cases

Tighter connector governance often increases operational overhead, so organisations have to balance speed of integration against the risk of uncontrolled trust expansion. There is no universal standard for this yet, especially when the connector is managed by a SaaS vendor, embedded in an agent workflow, or configured by a business team outside central identity operations.

One common edge case is delegated access through OAuth consent or marketplace apps. The vendor may process the data, but the enterprise still owns the approval decision because it authorised the connector to act in its environment. Another is agentic automation, where a connector gives an AI agent access to systems it can chain together in unexpected ways. That is where the question becomes not only who approved the connector, but who can stop it when behaviour changes. The NHIMG Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames third-party exposure, excess privilege, and weak offboarding as recurring failure modes.

Where possible, best practice is evolving toward workload identity, time-bound access, and policy-based approval rather than permanent trust. But if the connector sits in a business-critical workflow with no clean revocation path, accountability must also include the service owner, because the risk cannot be transferred away once the trust relationship is live.

Related resources from NHI Mgmt Group

• Who is accountable when a secure email gateway misses an identity-led attack?
• Who is accountable when patient access is shared across third-party apps?
• Who is accountable for third-party access that outlives its intended use?
• Why do third-party users create outsized identity risk in critical industries?