Who is accountable when a third-party integration is abused?

Why This Matters for Security Teams

When a third-party integration is abused, the issue is rarely limited to the tool that was compromised. It is usually a governance failure across approval, provisioning, monitoring, and revocation. NHI accountability matters because connected apps often inherit broad access through service accounts, tokens, or API keys that outlive the business reason for issuing them. The result is a gap between technical ownership and operational responsibility, which is exactly how abuse turns into a prolonged incident. OWASP’s OWASP Non-Human Identity Top 10 treats this as a core identity risk, not a niche integration problem.

The business owner should be able to explain why the integration exists, the platform owner should know how it is connected, and the identity team should control the lifecycle of the credentials behind it. That shared accountability model is not theoretical. In The 52 NHI breaches Report, abuse patterns repeatedly show that hidden grants and weak offboarding create long dwell time. In practice, many security teams encounter the absence of ownership only after the integration has already been used to move laterally or exfiltrate data.

How It Works in Practice

Good accountability starts with making the integration legible. Every third-party connection should have a named business sponsor, a technical custodian, and an identity owner responsible for credentials, permissions, and revocation. That means the grant request, approval record, purpose, expiry date, and renewal path must all be traceable. For privileged or high-risk integrations, current guidance suggests pairing RBAC with contextual controls, because fixed roles alone do not reflect how integrations behave once they are embedded in workflows.

In practice, the identity team should issue secrets with the shortest viable lifetime, rotate them automatically, and revoke them when the business purpose ends. Where feasible, JIT credentials reduce exposure by limiting the window in which abused access can be used. The operational goal is not just to prevent login, but to prove who approved the grant and who owns the response if the integration starts behaving unexpectedly. NHI Mgmt Group has shown in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack that once an integration is trusted, attackers often inherit that trust faster than defenders can notice.

• Assign a business owner for purpose and risk acceptance.
• Assign a platform owner for deployment, connectivity, and runtime support.
• Assign an identity owner for issuance, rotation, and revocation.
• Record TTL, renewal rules, and break-glass contacts before go-live.
• Review access after vendor changes, scope changes, or incident signals.

These controls tend to break down when integrations are embedded in CI/CD pipelines or unmanaged automation paths because ownership gets distributed across teams that do not share a single approval and revocation workflow.

Common Variations and Edge Cases

Tighter integration governance often increases administrative overhead, so organisations have to balance speed against control. That tradeoff is real for customer-facing APIs, partner platforms, and internal automation that cannot tolerate lengthy approval cycles. There is no universal standard for this yet, but best practice is evolving toward risk-tiered ownership: low-risk integrations can follow lighter reviews, while privileged or externally reachable integrations require stronger approval, shorter TTLs, and more frequent recertification.

One edge case is delegated access through a vendor-managed app. The business owner may believe the vendor owns the risk, but accountability still remains internal for the decision to connect the app and keep it connected. Another edge case is a shared integration used by multiple teams. In those situations, split ownership is acceptable only if the revocation path is explicit; otherwise, nobody acts first when abuse is suspected. The guidance is reinforced by the 52 NHI Breaches Analysis and by the threat patterns summarised in OWASP Non-Human Identity Top 10. The practical test is simple: if an organisation cannot revoke an integration within minutes of abuse being detected, the ownership model is not mature enough.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• When does a third-party integration become a security liability?
• When should teams revoke a third-party SaaS integration?
• How can organisations reduce blast radius after a third-party integration compromise?