Who is accountable when a stolen token is reused for business email compromise?

Why This Matters for Security Teams

When a stolen token is reused for business email compromise, the incident is not just “an email problem” or “an identity problem.” It is a trust-chain failure across identity providers, email controls, SaaS sessions, and any downstream integrations that accepted the token as proof of legitimacy. NHI Management Group treats this as an NHI governance issue because the token often outlives the original authentication event and can be replayed without a fresh human challenge.

The practical risk is that ownership becomes fragmented: identity teams may revoke the source account, email teams may quarantine messages, and SaaS owners may not know which session, consent grant, or API token actually enabled the abuse. Research on real incidents shows how quickly attackers weaponise exposed access, as seen in the Salesloft OAuth token breach and the broader patterns captured in The 52 NHI breaches Report. Industry guidance also emphasizes that compromise paths increasingly cross human and machine boundaries, including AI-assisted abuse patterns described by Anthropic.

In practice, many security teams encounter token reuse only after mailbox rules, consent grants, or delegated sessions have already been used to pivot deeper into the business.

How It Works in Practice

Accountability should be assigned by control plane, not by assumption. The identity team typically owns authentication policy, token issuance, and revocation mechanics. The email security team usually owns mailbox protection, suspicious forwarding rules, and message trace investigation. The SaaS or application owner owns session scope, consent grants, and downstream access review. If the token was issued through an external IdP, then the IdP and the target SaaS both have a role in invalidation because neither layer can fully see the other’s state.

Practitioners should define who can do what when a token is reused:

• Revoke the token or refresh token at the source authority immediately.
• Invalidate all active sessions tied to the compromised subject or workload.
• Review mailbox delegation, forwarding, and OAuth consent grants for abuse.
• Check whether the token enabled API access, not just interactive email access.
• Preserve logs so the investigation can distinguish theft, replay, and privilege escalation.

This is why token reuse is best treated as a lifecycle failure, not a one-off compromise. Guidance from the Guide to the Secret Sprawl Challenge is relevant here because fragmented control over secrets, tokens, and sessions makes revocation slow and inconsistent. Current best practice is to pair central policy with service-specific enforcement, using the identity provider for primary revocation and the SaaS platform for session termination. That approach aligns with NIST SP 800-207 Zero Trust Architecture, which assumes every request must be evaluated explicitly rather than trusting an existing session indefinitely.

These controls tend to break down in federated SaaS environments where the email platform, IdP, and business application each cache trust independently and cannot invalidate one another in real time.

Where Accountability Breaks Down in Real Incidents

Tighter ownership usually improves containment, but it also increases coordination overhead, especially when multiple platforms can issue or accept the same token. The hard part is deciding whether the accountable party is the system that issued the token, the team that failed to monitor reuse, or the business owner who granted excessive consent in the first place. There is no universal standard for this yet, so organisations should document a primary owner and named backup for every token class.

Edge cases matter. A stolen oauth token used for mailbox access may be owned by the identity team, but if the same token also authorises CRM actions, the SaaS owner must share accountability for revocation and audit. If the token was harvested from an endpoint, endpoint security may own initial detection, but not the business impact. If the compromise involved a service account or automation identity, then the problem shifts from user compromise to NHI governance, where short-lived credentials and explicit scope limits matter more than password reset workflows.

That is why NHI Management Group recommends mapping each token class to a revocation path, a telemetry owner, and a business responder before an incident occurs. The operational lesson is reinforced by Cisco Active Directory credentials breach and similar cases where credential exposure only became material after attackers reused valid access across systems. Current guidance suggests the fastest path is pre-declared ownership plus automated session invalidation, because manual handoffs are too slow once email compromise is underway.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted cloud identity is used for business email compromise?
• Who is accountable when compromised cloud identity is used for business email compromise?
• What should teams do when email is being used to bootstrap access into business systems?
• What breaks when email requests can trigger business action directly?