Because authentication success is not the same as session trust. If an attacker captures a valid code, token, or refreshed browser session, they can operate as the user until those artifacts are revoked or bound to stronger context. That is why identity teams must govern session lifetime and token reuse, not just passwords.
Why captured MFA codes and session tokens are enough to impersonate a user
A valid MFA code proves a step in the login flow, not an ongoing right to act as that user. A stolen session token is even stronger for an attacker because it can represent an already-authenticated browser or app state. Once either artifact is replayed, the attacker inherits the session until expiry, revocation, or a stronger binding check stops reuse.
Phishing kits, adversary-in-the-middle proxies, infostealers and help-desk social engineering all target the same weakness: they do not need to defeat the account owner again if they can steal the artifact that the service already trusts. That is why session hijacking and token replay are often more operationally important than the original password attack.
Why session lifetime and token binding matter more than one-time code entry
Many authentication systems treat MFA as a point-in-time control and then issue a longer-lived session cookie, refresh token, or bearer token. If that token is reusable from another device or network, possession is enough. A stolen browser session can survive password changes, and a stolen refresh token can mint fresh access tokens until the refresh path is revoked or invalidated.
Controls that reduce this risk include short session lifetimes for sensitive workflows, reauthentication for high-risk actions, token rotation, and binding tokens to the client, device, or TLS context where the architecture allows it. NIST SP 800-63 Digital Identity Guidelines is useful here because it distinguishes authenticator proof from session assurance and pushes stronger options for phishing-resistant sign-in.
When a product uses OAuth or OIDC, the practical question is not only whether login succeeded, but whether the resulting token can be replayed out of context. Standards such as sender-constrained tokens and audience restriction exist precisely because bearer tokens are otherwise transferable by design.
What makes stolen MFA and session material especially dangerous in real incidents
The risk becomes material when the stolen artifact is accepted as proof of identity across sensitive applications, admin consoles, or remote access gateways. At that point, the attacker does not need to know the password, defeat MFA again, or wait for another prompt. They simply use the captured trust artifact to move laterally, exfiltrate data, reset other credentials, or plant persistence.
That pattern is visible in real-world account takeover and session theft cases. For example, CitrixBleed exploitation 2023 showed how leaked session cookies can bypass passwords and MFA entirely, while Twilio 0ktapus breach 2022 illustrates how one-time code capture can be converted into account takeover when the attacker controls the login flow.
Stolen session material is also operationally dangerous because it can outlive the original event that exposed it. If the session is not centrally revoked, if refresh tokens are not rotated, or if high-value apps do not re-check context, the attacker keeps working long after the victim believes the login has been fixed.
Risk and Threat Considerations
Stolen MFA codes and session tokens matter because they turn an authentication event into reusable access. The attacker’s goal is not to beat MFA repeatedly, it is to capture the artifact the platform already trusts and reuse it before the session is invalidated.
Failure mechanism: Bearer-style codes, cookies, and tokens are replayable if the service does not bind them to device, channel, or fresh user verification. A compromised session can therefore survive password resets and continue to mint access until revocation or expiry.
Impact: The attacker can act as the user, escalate into privileged workflows, pivot into adjacent systems, and create persistence that is harder to detect than a password reset event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Authentication strength and session assurance both matter to stolen MFA and token replay. |
| Recommendation — Use phishing-resistant authenticators and stronger session assurance for high-risk access. | ||
| OWASP ASVS | V7 — Session Management | The issue is reusable sessions and token replay after login succeeds. |
| V10 — OAuth and OIDC | OAuth/OIDC tokens can be replayed unless sender binding and audience checks are strong. | |
| Recommendation — Enforce secure session handling, rotation, and invalidation for sensitive access. Bind tokens to the intended client and reduce bearer-token replay risk. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Stolen MFA codes and refresh tokens implicate authenticator and token lifecycle control. |
| IA-2 — Identification and Authentication (Organizational Users) | User authentication is only part of the trust chain; session trust follows it. | |
| Recommendation — Rotate, revoke, and manage authenticators and tokens across their lifecycle. Require stronger reauthentication for sensitive actions and privileged sessions. | ||
Practitioner Guidance
What to verify: Confirm whether your strongest sessions are actually revalidated for privileged actions, not just at initial login. If a stolen refresh token or browser cookie can still reach admin functions, treat that as a design weakness rather than an isolated incident.
Decision rule: If the compromise involved a reusable session artifact, rotate or revoke sessions first, then assess downstream credentials, API tokens, and delegated access that may have been issued from that session. If the user had privileged access, assume the blast radius extends beyond the visible account login.
Practitioner takeaway: The right control objective is not “did MFA happen?”, it is “can a stolen authentication artifact still be replayed with meaningful authority?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org