A control is failing when the attacker can capture a valid token in transit and reuse it before the legitimate user notices. Warning signs include unexpected lockouts, proxy-style logins, or successful sign-ins that follow a phishing event. Those patterns show the factor was accepted, but the session itself was not trustworthy.
How to tell the control failed even though the MFA code was correct
The key signal is that the second factor was accepted, but the resulting session was not trustworthy. That usually means the attacker intercepted or replayed the authentication flow, or the code was used inside a fraudulent login context that the user could not distinguish from the real one. The failure is in the control path, not the code itself.
Look for login events that appear valid on their face but do not fit the user’s normal pattern: unexpected prompts for reauthentication, sign-ins from unusual networks or devices, tokens created after a phishing event, or access that appears to “work” and then immediately drives suspicious post-authentication activity. Those are often stronger indicators than raw MFA success or failure counts.
There is a practical difference between a correct code and a trustworthy authentication outcome. If the control is only checking that a one-time value was entered, it can still fail against adversary-in-the-middle phishing, token theft, session hijacking, or MFA fatigue abuse. A valid code can coexist with a compromised session if the attacker captures the session artifact or proxies the exchange. For a deeper pattern view, compare the failure mode with MFA Guide, which explains common bypass paths and why phishing-resistant methods matter. When the issue is session theft rather than code theft, the login result may look successful while the trust boundary has already been lost, as in CitrixBleed exploitation 2023.
What operational signals usually accompany a broken MFA flow?
The most useful clues are correlation-based. One signal alone is often noisy, but a cluster of weak indicators is meaningful: a valid MFA challenge followed by odd geography, device drift, proxy characteristics, impossible travel, unfamiliar browser state, or a login that is quickly followed by mailbox rules, token grants, data access, or privilege changes. If the user reports entering a code but still “lost control” of the session, that strongly suggests the authentication factor was not the real point of compromise.
Unexpected lockouts can also matter, but they are not the same as compromise. They may indicate push fatigue, repeated relay attempts, or the attacker forcing retries until a token or session is captured. Successful sign-in events that occur right after a phishing event are especially important because they suggest the attacker finished the flow before the user realised it was fraudulent. In practice, that pattern is often more actionable than a simple failed-login alert.
At the infrastructure level, patterns that involve reverse proxies, unusual user-agent strings, or repeated sign-in completion from a new endpoint can expose an adversary-in-the-middle path. That is why phishing-resistant authentication guidance such as NIST SP 800-63 Digital Identity Guidelines is relevant here, especially where authenticator assurance and phishing resistance are part of the control objective. Where the control is tied to session integrity rather than only factor entry, comparison with OpenID Connect Core 1.0 can help practitioners distinguish a valid assertion from a trustworthy session.
Why the root cause is often session theft, relay, or factor fatigue
When users enter valid MFA codes and the attacker still succeeds, the attack is often exploiting the authentication journey rather than breaking the code. Relay attacks proxy the login in real time, so the legitimate user unknowingly authorises the attacker’s session. Token theft attacks capture the artifact after authentication and reuse it later. Fatigue attacks wear down the user until they approve a prompt that was not initiated by them. Each of these can produce a “successful” MFA event in logs while the environment is already compromised.
That is why the decisive question is not “was MFA entered correctly?” but “did the control bind the user, device, and session strongly enough to resist interception and replay?” A control that cannot answer that question cleanly is vulnerable even if it appears to work during routine logins. In operational terms, the control has become a gate, not a proof of trustworthy access.
Risk and Threat Considerations
When MFA appears to succeed but the session is attacker-controlled, organisations can miss the real compromise until the attacker has already accessed mail, applications, or downstream admin tools. The main risk is false confidence: teams may treat successful MFA as a sign of safety when the actual weakness is token replay, relay, or session hijack.
Failure mechanism: The attacker captures the authentication exchange or session artifact, then reuses it before the user or monitoring stack recognises the anomaly. The control validates the factor, but not the integrity of the session that follows.
Impact: Access can be taken over even though the user entered a valid code, which can lead to mailbox abuse, lateral movement, privilege escalation, and delayed incident detection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and authenticator assurance directly address valid-code but untrusted-session failures. |
| Recommendation — Use phishing-resistant authenticators and bind sign-in assurance to session trust. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Valid MFA with compromised sessions is an authentication-control failure for workforce access. |
| IA-5 — Authenticator Management | Relay, theft, and replay failures often hinge on weak authenticator lifecycle and reuse handling. | |
| Recommendation — Strengthen user authentication and verify the post-login session is trustworthy. Rotate, bound, and monitor authenticators and tokens to reduce replay risk. | ||
| OWASP ASVS | V6 — Authentication | Authentication failures despite valid codes fall under authentication assurance and anti-bypass requirements. |
| V7 — Session Management | The issue often becomes session theft or replay after MFA succeeds, making session controls material. | |
| Recommendation — Verify the authentication flow resists phishing, replay, and prompt abuse. Bind sessions tightly and detect reuse, hijacking, or unusual session creation. | ||
| MITRE ATT&CK | T1110 — Brute Force | MFA fatigue and repeated prompt abuse fit attacker credential-access pressure against sign-in flows. |
| Recommendation — Map repeated challenge abuse to attacker pressure in your detections. | ||
Practitioner Guidance
What to verify: Do not stop at MFA success. Check whether the sign-in came from a trusted device, whether the session token was newly issued, and whether the post-authentication activity matches the user’s normal pattern. If the sign-in is valid but the follow-on behaviour is abnormal, treat the session as suspect.
What to prioritise: Focus first on the authentication methods that resist relay and token capture, then on telemetry that can distinguish factor acceptance from session trust. If your only evidence is “the code was correct,” you do not yet know whether the control held.
Practitioner takeaway: A correct MFA code proves only that a factor was presented, not that the resulting session is trustworthy; the control is failing when the attacker can turn that valid step into durable access.
Related resources from NHI Mgmt Group
- What are the signs that SSH password authentication is failing as a security control?
- What are the signs that VDI authentication is failing as a control?
- What are the signs that SMS MFA is failing as a security control?
- Why do legacy mobile MFA methods still leave organisations exposed even when users have two-factor authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
