How should security teams detect token theft if MFA was already completed?

When MFA has already happened, the question is whether a token is being replayed, not whether the user originally authenticated. That shifts detection toward session and API behaviour: where the token appears to come from, how it is used, and whether the activity matches the account’s normal access pattern.

Unusual IP addresses and geolocations are useful because a stolen token often shows up from an unfamiliar network or a place the user could not plausibly reach in the time window. User-Agent changes, device drift, and impossible travel add context, but they matter most when they are paired with actions that look automated, bursty, or inconsistent with the user’s usual workflow.

Look beyond the login event and examine what the token can do once accepted. Bulk downloads, large query volumes, repeated access to rarely used applications, new scopes, and access to data or admin functions outside the account’s normal pattern are stronger indicators than another successful sign-in. If the token is valid, the abuse often shows up in post-authentication actions, not in authentication logs.

Why token theft is different from MFA bypass

A completed MFA challenge proves the user satisfied one step in the chain, but bearer tokens can outlive that moment and be replayed elsewhere. That means attackers may never need to repeat the MFA step if they can steal an access token, refresh token, session cookie, or similarly reusable credential and present it from a different host or automation path.

Detection therefore needs to correlate authentication, session, and application telemetry. The useful signals are the ones that show mismatch: a token issued to one context but used from another, or a token that suddenly starts touching resources the account rarely touches. For deeper reading on why MFA alone is not the whole story, see the MFA Guide and the NIST SP 800-63 Digital Identity Guidelines.

What telemetry gives the clearest signal

The strongest hunting pattern is to combine identity context with resource usage. A single unusual IP may be noisy; an unusual IP plus a new country, a different User-Agent, and access to high-value data is much more convincing. The same applies to scope use: a token that suddenly reads large datasets, calls uncommon APIs, or accesses administrative paths deserves immediate review.

Application owners should also look for token activity that breaks the account’s normal cadence, such as high-rate requests, short bursts of enumeration, or access to multiple systems in rapid succession. Where OAuth is involved, audience-restricted and sender-constrained token designs reduce replay value, and the current best-current-practice guidance for OAuth token security is worth aligning to. The relevant standard discussion is in RFC 9700: Best Current Practice for OAuth 2.0 Security.

How to separate normal session use from compromise

The practical test is whether the token behaves like a real user session or like an exfiltration tool. Normal use tends to be consistent in geography, device characteristics, access cadence, and application choice. Compromised token use often shows one or more discontinuities: a sudden network change, a different browser or client stack, access to a rarely used app, or data access that spikes far beyond baseline.

That is why token theft investigations should start with the first anomalous use, then work forward through the session timeline. You are trying to answer three questions: where did the token come from, what did it do, and how far did the abuse spread before detection. If the account has a long-lived session or a refresh token in circulation, the review should extend to every place that token could have been replayed.

Risk and Threat Considerations

Bearer tokens are attractive because whoever holds them can often act as the user without repeating MFA, which makes replay, lateral movement, and data theft easier after the initial compromise. The risk is highest where tokens are long-lived, broadly scoped, or accepted across multiple apps and devices.

Failure mechanism: An attacker steals a valid token, reuses it from a different context, and avoids the original MFA challenge because the application trusts the token rather than the login event that created it.

Impact: Security teams may miss the compromise if they only monitor successful logins, allowing unauthorized access, bulk data extraction, and privilege misuse to continue until the token expires or is revoked.

Practitioner Guidance

What to verify: Confirm whether the suspicious token was used from a new IP, a new geolocation, a new User-Agent, or a new client type, and compare that usage with the account’s normal session pattern. If the same token is seen touching unusual scopes, high-volume exports, or uncommon applications, treat it as likely compromise rather than benign travel.

Decision rule: If MFA succeeded but the post-authentication behaviour is abnormal, investigate the token itself first, then decide whether to revoke sessions, rotate related secrets, and force reauthentication. Do not wait for proof of password compromise before acting, because the password may be irrelevant once the bearer token is stolen.

Practitioner takeaway: The most reliable signal is not that the user signed in, but that the token behaved like a legitimate session in the right place, on the right device, and with the right level of access.

Related resources from NHI Mgmt Group

• Detect
• How should security teams detect session token replay when MFA and conditional access never trigger?
• How do security teams detect whether a package based credential theft campaign has already spread inside their environment?
• How should security teams detect identity attacks after login when MFA and phishing controls are already in place?