Why do phishing-resistant MFA methods not stop token theft?

Why phishing-resistant MFA still fails against token theft

Phishing-resistant MFA blocks the classic “trick the user into typing a code” path, but it does not change what happens after authentication succeeds. If an attacker steals a valid session cookie, refresh token, or bearer token, the application may accept that artefact as proof of identity until it expires or is revoked. The weakness is therefore in token handling, not in the MFA ceremony itself.

That distinction matters because many organisations overestimate the protection they get from stronger sign-in. A passkey or security key can stop a fake login page from harvesting a reusable password, but it cannot retroactively protect a session that has already been established and then copied from the browser, endpoint, proxy, log store, or compromised app component.

What a stolen token actually gives an attacker

A stolen token is often more valuable than a stolen password because it can represent an already authenticated session, delegated access, or a refresh path that can mint new access tokens. In practice, the attacker is not trying to log in again, they are trying to inherit the trust the system has already granted.

That is why token theft bypasses the user interaction that phishing-resistant MFA is designed to harden. If the system does not bind the token to the original device, client, or proof-of-possession requirement, the bearer can usually replay it from elsewhere. This is also why session token theft remains a distinct control problem even in environments that have fully moved away from SMS codes and one-time passwords.

Workforce Identity Security Guide covers the practical control stack around phishing-resistant MFA, session theft, and recovery paths, which is where this problem becomes operational rather than theoretical.

How attackers keep using valid tokens after the login moment

Token theft usually becomes useful when a valid session is exported from an endpoint, intercepted in transit, copied from browser storage, or recovered from logs or misconfigured services. The attacker then works within the token’s remaining lifetime, which can be long enough to access email, cloud consoles, internal apps, or downstream APIs without ever facing MFA again.

This is also why conditional access and reauthentication policies matter. Some environments only check MFA at sign-in, then trust the session for hours or days. If the platform does not re-evaluate risk on token use, geolocation change, device change, privilege escalation, or sensitive action, the stolen token can keep working even after the original user notices something is wrong.

RFC 9700: Best Current Practice for OAuth 2.0 Security is useful here because it addresses token theft directly and reinforces sender-constrained and audience-aware token handling.

What defenders should change after phishing-resistant MFA is already in place

The next control objective is not “more MFA”, it is reducing the usefulness of stolen tokens. That means shorter token lifetimes where feasible, tighter refresh-token handling, stronger session binding, better revocation paths, and protections that make token replay materially harder. Where the platform supports it, proof-of-possession or sender-constrained tokens are more resilient than pure bearer semantics.

Defenders should also treat endpoints and browser sessions as part of the identity attack surface. If an endpoint is compromised, the attacker may not need to defeat MFA at all. Session theft from a trusted device can be enough, so telemetry, device trust, and session invalidation controls matter as much as the sign-in factor itself.

NIST SP 800-63 Digital Identity Guidelines provides the identity assurance context for phishing-resistant authenticators, while RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) shows how sender-constrained tokens reduce replay value if a token is stolen.

Risk and Threat Considerations

Token theft shifts the attack from authentication bypass to session abuse, which is often quieter and harder to spot. A stolen bearer token can look indistinguishable from a legitimate session until the defender notices unusual access patterns, privilege use, or token reuse from an unexpected context.

Failure mechanism: The platform trusts the token as sufficient proof of identity after the login event, so the attacker inherits the session without having to satisfy MFA again. If the token is not device-bound, sender-constrained, or rapidly revocable, replay remains practical.

Impact: Attackers can access mail, SaaS apps, cloud consoles, or APIs, then move laterally, exfiltrate data, or escalate privileges before the session expires or is revoked.

Practitioner Guidance

What to verify: Check whether your authentication stack distinguishes between initial sign-in assurance and ongoing session assurance. If the answer is “no”, assume phishing-resistant MFA has improved one part of the chain but left the replay problem intact.

Decision rule: If a token can be used from a different device, browser, or network without additional proof, treat it as replayable. Prioritise token binding, revocation, and session controls before assuming the MFA method itself is the issue.

What practitioners underestimate: The real gap is often not the factor, but the lifetime and portability of the session that follows it. Strong authentication can still coexist with weak post-authentication trust.

Practitioner takeaway: Phishing-resistant MFA stops many credential-phishing paths, but it does not make stolen sessions safe, so the control objective must extend from sign-in hardening to token replay resistance and fast session invalidation.

Related resources from NHI Mgmt Group

• Guide: Social Engineering Guide
• Phishing-Resistant MFA
• Why do phishing-resistant MFA methods matter if attackers can still get in?
• Who is accountable when phishing-resistant MFA is bypassed through fallback methods?
• Why do phishing-resistant MFA methods reduce account takeover risk more than codes or SMS?