Who is accountable when a third-party token exposes customer data?

Why This Matters for Security Teams

A third-party token is rarely just a technical artifact. It is a delegated access path that can outlive the business purpose it was meant to serve, especially when procurement, security, and service owners do not share a single revocation trigger. That is why accountability usually lands with the organisation that permitted the token to remain valid, not with whichever system happened to use it last.

The risk is visible across real incidents and research. NHIMG’s 52 NHI Breaches Analysis shows how quickly unmanaged non-human access becomes breach fuel, while the OWASP Non-Human Identity Top 10 treats lifecycle failure and overprivilege as core control gaps. The practical lesson is simple: if a token can still reach customer data after the vendor relationship should have ended, then the governance failure is internal even if the exposure originated externally. In practice, many security teams discover this only after the token has already been used for data access rather than during contract offboarding.

How It Works in Practice

Accountability should be mapped across three layers: business ownership, technical ownership, and vendor governance. The service owner is responsible for the token’s intended use, the security team is responsible for control design and monitoring, and the vendor relationship owner is responsible for making sure access ends when the contract, integration, or support need ends. That split matters because regulators and auditors generally look for evidence that access was governed, time-bounded, and removable.

Practically, organisations should maintain a token inventory that records the issuing system, purpose, data scope, owner, expiry, rotation method, and revocation path. Where possible, use short-lived credentials, scoped OAuth grants, and just-in-time access rather than persistent tokens. Guidance from the OWASP Non-Human Identity Top 10 and breach analysis such as Salesloft OAuth token breach show why stale access paths are not a theoretical problem.

• Define who can approve, rotate, and revoke each third-party token.
• Attach every token to a named business purpose and data classification.
• Set expiry dates that match the contract term, not just the technical integration.
• Alert on token use outside expected systems, geographies, or time windows.
• Revoke tokens automatically when a vendor is offboarded or an integration is retired.

For broader secrets governance, NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that detection without revocation is not enough. These controls tend to break down in heavily decentralised SaaS environments because no single team owns the full revocation chain.

Common Variations and Edge Cases

Tighter token governance often increases operational overhead, so organisations have to balance faster vendor onboarding against stronger revocation discipline. That tradeoff becomes sharper when integrations are owned by different departments, because the access path may be technically valid long after the contract or support relationship has changed.

There is no universal standard for this yet, but current guidance suggests treating customer-data tokens as high-risk NHI assets whenever they can reach production data. If a vendor holds the token, the vendor may be contractually responsible for safe handling, but the customer organisation remains accountable for granting and continuing the access. This is especially true when service accounts are shared across applications, when tokens are embedded in CI/CD or ticketing systems, or when offboarding depends on manual reminders.

Edge cases often appear in reseller chains, managed service relationships, and emergency support arrangements. In those scenarios, the question is not just who created the token, but who had the authority and process to remove it. The safest interpretation is to assume accountability follows control: if the organisation could have expired, scoped, or revoked the token, it owns the failure. NHIMG research on token exposure patterns and the 52 NHI Breaches Analysis both show that visibility gaps are where these incidents become expensive.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party integration exposes sensitive healthcare data?
• Who is accountable when a service account breach exposes customer data?
• Who is accountable when a third-party verification provider mishandles identity data?
• Who is accountable when a SaaS integration exposes customer data?