Who is accountable when a stolen token is used to access corporate systems?

Why This Matters for Security Teams

When a stolen token is used, the real failure is rarely the theft itself. It is the fact that the token remained valid, usable, and insufficiently bound to context after compromise. That makes accountability shared, but not diffuse: identity governance must limit lifetime and scope, application owners must design permissions so a token cannot do more than intended, and security operations must detect abnormal use fast enough to contain it. The control problem is visible in breach patterns such as the Salesloft OAuth token breach, where stolen credentials were used as a bridge into trusted systems.

Current guidance also treats token abuse as an identity and session integrity issue, not just an incident-response event. NIST control families and the OWASP Non-Human Identity Top 10 both point toward reducing standing access, shrinking blast radius, and revoking credentials immediately when abuse is suspected. In practice, many security teams discover weak ownership only after a token has already been replayed across multiple services.

How It Works in Practice

Accountability follows the control plane that allowed the token to exist, the service that accepted it, and the monitoring function that failed to flag misuse. Identity teams typically own issuance, rotation, revocation, and offboarding hygiene. Application owners own authorization design, including scope selection, consent boundaries, and whether the token can be reused beyond its original purpose. Security operations owns detection, correlation, and containment when token use diverges from normal patterns.

Practically, that means tracing three questions at once: who issued the token, what access was granted, and what telemetry existed when it was used. If the token is a non-human identity credential, the issue is often worse because the token may be embedded in automation, CI/CD, or an API workflow. NHIMG research on 52 NHI Breaches Analysis and the Ultimate Guide to NHIs shows how exposed or overused machine identities can persist long after the original owner thinks the credential is harmless.

• Identity teams should enforce short token lifetimes, automated revocation, and offboarding checks.
• Application teams should minimize scope and avoid broad delegated permissions.
• Security teams should alert on anomalous geography, impossible travel, unusual API paths, and rapid privilege chaining.
• Incident responders should revoke first, then validate whether the token was replicated into other systems.

Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls support this split-responsibility model through access control, audit, and incident response expectations. These controls tend to break down when tokens are shared across teams, copied into scripts, or tied to automation that no one owns end to end.

Common Variations and Edge Cases

Tighter token governance often increases operational overhead, requiring organisations to balance fast automation against stronger containment. That tradeoff becomes sharper when the stolen token belongs to a service account, a third-party integration, or an AI agent that uses multiple tools on behalf of a workflow.

There is no universal standard for token accountability in every architecture, but current guidance suggests the owning team is the one that can change the token’s scope, lifetime, or revocation path. If the token is embedded in a vendor integration, accountability may be shared with procurement or platform engineering, but the internal system owner still carries the duty to assess risk. If the token is used in an autonomous workflow, the relevant question becomes whether the system had real-time policy checks and rapid revocation, not just a one-time approval.

Attack patterns documented in incidents such as the Microsoft SAS Key Breach show why long-lived tokens are especially dangerous when copied into tools, tickets, or repositories. The more places a token can appear, the harder it is to assign one clean owner after compromise. In those cases, accountability is still shared, but the security team should treat duplicated credentials as an architectural failure rather than a one-off mistake.

Related resources from NHI Mgmt Group

• Who is accountable when stolen software supply chain credentials are used to publish malicious code?
• Who is accountable when a phished identity is used to access downstream systems?
• Who is accountable when a leaked secret is used to access business systems?
• Who is accountable when stolen identity-provider access is used to reach downstream apps?