How should security teams detect token theft without relying on failed login alerts?

How to Spot Token Theft When Login Failures Never Appear

Security teams should treat token theft as a post-authentication abuse problem, not a failed-authentication problem. Once a bearer token is stolen, the attacker often reuses valid credentials and never triggers bad-password or MFA-failure alerts. The useful signal is behavioural drift after issuance: where the token appears, how it is used, and whether the session profile matches the expected user or workload.

Behavioural Signals That Reveal Stolen Tokens

The most reliable detections correlate a token’s normal baseline with its actual session behaviour. Location shifts, ASN changes, User-Agent changes, impossible travel, new device fingerprints, and unusual access volume are all useful because they describe how the token is being used, not whether the login succeeded. For practical session analytics, Token and Session Security Guide is the clearest internal reference for tying those signals to replay, revocation, and binding controls.

Teams should also watch for access patterns that fit token replay rather than human activity, such as a session suddenly reading far more records than the user typically touches, authenticating from multiple geographies in a short window, or accessing services that are adjacent but not part of the usual work pattern. In SaaS and API environments, those anomalies often show up before any obvious account takeover symptom.

For a concrete abuse pattern, stolen OAuth tokens were used to access downstream data in the Salesloft OAuth token breach, which is a good example of why token provenance and session context matter more than login outcomes. The same logic appears in the Gainsight Salesforce breach 2025, where long-lived OAuth tokens remained useful long after issuance.

What Detection Needs to Correlate for High Confidence

A strong detection program correlates identity telemetry, network telemetry, and application activity. Identity signals tell you who the token should belong to; network signals tell you where it is being used from; application signals tell you whether the access pattern matches legitimate work. When those three disagree, especially during otherwise successful authentication, the token may be compromised.

One useful pattern is to score a session against both historic user behaviour and peer-group behaviour. For example, a finance analyst who suddenly pulls developer-level API data, or a CI/CD token that starts reading unrelated cloud resources, is a better alert than a raw login anomaly. This is also why CircleCI breach 2023 is so instructive: the session itself was valid, but the post-authentication activity was not.

Detection becomes much stronger when tokens are bound or constrained so replay is harder. Current guidance from RFC 9700: Best Current Practice for OAuth 2.0 Security and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) supports sender-constrained designs, which reduce the chance that a stolen bearer token can be used from a different client without additional proof.

Risk and Threat Considerations

Token theft is dangerous precisely because it converts theft into apparently legitimate use. Attackers prefer it because it bypasses password resets, MFA prompts, and most failed-login thresholds, which means defenders often see the compromise only after data access, lateral movement, or privilege misuse has already begun.

Failure mechanism: A bearer token or session cookie is replayed from a different host, network, or application context, so authentication succeeds while the session behaviour diverges from the normal baseline.

Impact: The attacker can quietly access SaaS data, APIs, cloud resources, or CI/CD systems, and the organisation may not recognise the compromise until exfiltration, destructive actions, or token revocation.

Practitioner Guidance

What to prioritise: Start with sessions and tokens that can reach high-value data or administrative functions. A low-quality anomaly on a harmless session is less urgent than a mild anomaly on a token that can read production data, cloud controls, or developer secrets.

What to verify: Confirm that your detections compare the current session against a baseline built from the same identity, client type, geography, ASN, and access scope. If the alert only checks login success, it is too shallow to catch token theft.

Common mistake: Treating MFA as sufficient evidence that the session is trusted. MFA may have been satisfied before the token was stolen, and stolen sessions often look fully authenticated.

Practitioner takeaway: The best token-theft detections are behavioural and session-aware, not authentication-failure driven, because compromise usually appears as misuse of a valid token rather than a bad login.

Related resources from NHI Mgmt Group

• How should security teams detect session token theft without relying on noisy IP or geolocation checks?
• How should security teams detect token theft if MFA was already completed?
• How should security teams detect AI-written malware without relying on signatures?
• How should security teams detect malicious configuration drift without drowning in alerts?