Who is accountable when a third-party integrator exposes user access tokens?

Accountability usually sits with both the organisation operating the service and the third-party integrator that created the exposure. The operator must assess partner risk, define secure integration requirements, and validate configuration. The integrator is responsible for implementation errors. Security teams should document control ownership, escalation paths, and revocation procedures before tokens are exposed.

Why This Matters for Security Teams

When a third-party integrator exposes user access tokens, the issue is not just a vendor mistake. It is a control failure across the operating organisation, the integrator, and often the identity and secrets management layers in between. Token exposure can enable lateral movement, data access, and persistence long after the original integration was approved. NHIMG’s research on the 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild, showing how often operational handoffs fail to contain secrets.

Security teams should not wait for a post-incident blame exercise to define ownership. The operator is accountable for partner governance, access boundaries, and revocation readiness. The integrator is accountable for secure implementation, safe handling, and prompt disclosure of mistakes. That split only works if contracts, reviews, and technical controls are explicit before tokens are issued. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that shared environments still require explicit accountability, not assumed trust. In practice, many security teams discover token exposure only after external misuse has already started.

How It Works in Practice

Accountability should be assigned across three layers: business ownership, technical control ownership, and incident response ownership. The service operator usually owns the risk decision, because it chose the third party, approved the integration, and allowed the token to exist in production. The integrator owns implementation quality, including how tokens are stored, transmitted, logged, rotated, and revoked. If either party controls a step poorly, the exposure is usually shared in effect even if the legal liability differs.

Practically, the operator should require written rules for token scope, TTL, storage, approval, logging, and revocation. The integrator should be limited to the minimum token scope needed for the task and should never retain long-lived secrets outside approved vaults. This is where NHIMG’s The State of Secrets Sprawl 2026 is especially relevant: detection alone is not enough when 64% of valid leaked secrets remain exploitable and 28% of incidents originate outside code repositories. A token exposed in a ticketing system or chat channel still becomes an active control failure.

• Define who approves the integration before any token is issued.
• Make the operator responsible for partner due diligence and access review.
• Make the integrator responsible for secure handling and immediate disclosure.
• Require revocation playbooks that can be executed without waiting for the vendor.
• Log every token issuance, use, rotation, and revocation event.

For implementation detail, pair these controls with the Salesloft OAuth token breach lesson that one exposed token can become a broad downstream access path, and use NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor access control, audit, and incident response requirements. These controls tend to break down when the integrator is embedded in CI/CD or support workflows because tokens then move through multiple systems faster than humans can review them.

Common Variations and Edge Cases

Tighter token governance often increases integration overhead, requiring organisations to balance developer speed against revocation certainty. That tradeoff becomes sharper when the third party is a managed service provider, a SaaS connector, or a low-code platform that obscures where tokens are stored and who can access them.

There is no universal standard for contract wording yet, but current guidance suggests the operator should still retain primary accountability for risk acceptance, while the integrator remains accountable for any implementation defect that caused exposure. If the integrator subcontracts work, accountability can become multi-tiered, but that does not remove the operator’s duty to validate access paths. The 52 NHI Breaches Analysis shows that token and secret exposure often cascades from one weak control into several business systems.

Edge cases usually involve shared admin consoles, shared service accounts, or tokens reused across multiple applications. In those environments, even a clean handoff between operator and integrator may fail if the same credential unlocks too much. The safest approach is to treat exposed tokens as a revocation event, not just a notification event, and to document who can revoke immediately, who must approve restoration, and who must notify affected users. This guidance breaks down when organisations allow shared credentials across unrelated services because attribution and containment become impossible to separate cleanly.

Related resources from NHI Mgmt Group

• Who is accountable when a user grants a risky third-party app access?
• Who is accountable when banks onboard modern digital asset services through third-party integrations?
• What breaks when organisations manage machine and third-party access through manual processes?
• Who is accountable when banks rely on third-party compliance and fraud tooling?