How do third-party identities change breach accountability?

Why Third-Party Access Changes the Accountability Model

Third-party identities change breach accountability because the blast radius is no longer limited to employees with managed devices and internal approvals. Vendor users, service accounts, OAuth grants, and API keys often live outside the normal joiner-mover-leaver process, yet they can still reach sensitive data, production systems, and cloud control planes. That makes access governance a shared problem, even when the third party owns the account.

Industry guidance from the OWASP Non-Human Identity Top 10 and NHIMG research such as The 52 NHI Breaches Report both show the same pattern: breach responsibility rarely stays neatly inside one domain when identities are shared, delegated, or long-lived. The organisation that owns the data must still be able to prove who had access, what that access could do, and whether revocation actually occurred after contract changes or offboarding.

One NHIMG finding is especially relevant here: in the 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they had experienced or suspected an NHI breach. In practice, many security teams encounter third-party exposure only after a vendor credential, cloud token, or shared integration has already been used in an incident, rather than through intentional access reviews.

How Breach Accountability Should Be Traced in Practice

Accountability starts with identity inventory, not contract language. Security teams need a complete view of third-party identities across SaaS apps, cloud IAM, CI/CD systems, and machine-to-machine integrations. That means knowing which identities are human vendor users, which are non-human service accounts, and which are delegated through SSO, OAuth, or API keys. The question is not just who owns the relationship, but where the privilege actually exists.

Runtime evidence matters more than policy documents. A defensible model records:

• who created or approved the access
• what system or dataset the third party could reach
• whether access was temporary, recurring, or effectively permanent
• when the identity was last used
• how revocation was validated after offboarding or scope change

This is where least privilege and JIT controls intersect with vendor management. If a supplier needs access, current best practice is to issue the narrowest possible entitlement for the shortest practical duration, then revoke automatically when the task ends. For machine access, that usually means short-lived secrets, workload identity, and policy checks at request time rather than relying on standing accounts. The JetBrains GitHub plugin token exposure and similar supply-chain incidents show how quickly third-party credentials can become enterprise exposure when secrets are embedded in tools or integrations.

Security and legal teams should also separate contractual responsibility from operational accountability. A vendor may be responsible for misusing their own account, but the data-owning organisation remains accountable for granting, monitoring, and removing access to its environment. These controls tend to break down when third-party access is federated across multiple tenants, because revocation must be coordinated across systems that do not share a single source of truth.

Where the Standard Answer Breaks Down

Tighter third-party control often increases operational overhead, requiring organisations to balance faster vendor onboarding against stronger proof of access governance. That tradeoff becomes especially visible in fast-moving environments such as software development, cloud marketplaces, and managed service relationships, where access is granted through nested roles or reused automation accounts.

Current guidance suggests treating some third-party access patterns as shared-risk identities rather than simple external users. That is not yet a universal standard, but it is the most practical way to assign accountability when vendors chain access through SaaS platforms, ephemeral tokens, or nested admin roles. In these cases, the real question is whether the organisation can attribute actions to a specific identity and revoke that identity cleanly when the relationship ends.

There is also a common edge case: outsourced operations where the vendor administers systems on behalf of the customer. Even then, the customer still needs logging, scoped authorization, and verified offboarding. NHIMG’s LiteLLM PyPI package breach illustrates how quickly third-party trust can become credential exposure when tooling is compromised. The practical lesson is simple: accountability cannot be outsourced with the contract, only shared with evidence.

Related resources from NHI Mgmt Group

• Why do third-party identities become a governance problem when assessment models change?
• Who is accountable when third-party access stays active too long?
• How should security teams govern third-party integrations in audit and response tools?
• How should security teams govern non-human identities at scale?