An MFA replay attack is an attack that reuses a previously captured authentication factor or session artefact to gain unauthorised access. It usually targets time-based codes, push approvals, or session tokens when the system accepts the same value more than once or the attacker can replay it within a valid window.
How MFA Replay Attacks Work
An MFA replay attack succeeds when an attacker captures a one-time code, push approval, or session artefact and uses it again before the system invalidates it. The weakness is not the existence of MFA itself, but whether the protected flow accepts reused values or weakly binds the factor to the live session.
Replay often happens after phishing, adversary-in-the-middle interception, malware, or token theft. In practice, the attacker is trying to turn a legitimate second factor into reusable access, which means the control failure sits in the authentication flow, token handling, or session validation rather than in password strength alone.
Why Replay Is Dangerous
Replay attacks are dangerous because they bypass the user’s active participation after the first capture. If a code, approval, or token can be reused within a valid window, the attacker may gain the same access the user intended to grant, even when the organisation believes MFA was successful. The distinction matters because many teams treat MFA as a binary control, while replay shows that the strength of the implementation is what determines real protection.
Phishing-resistant methods reduce this risk by binding the authentication ceremony to the origin, device, or challenge context so the captured value is less useful elsewhere. Guidance on phishing-resistant sign-in, passkeys, and stronger authenticator assurance is covered in NIST SP 800-63 Digital Identity Guidelines, which helps explain why replay resistance is a separate property from simple second-factor presence.
Common Replay Pathways
Different MFA mechanisms fail in different ways. TOTP and SMS codes can be phished and used immediately. Push-based approvals can be abused through fatigue or social engineering if the user approves a prompt they do not recognise. Session cookies, bearer tokens, or other session artefacts are even more sensitive, because once they are replayed successfully they can sometimes skip the authentication step entirely until the session expires or is revoked.
Attackers often pair replay with credential theft, help desk manipulation, or session hijacking. The practical question is whether the system treats the factor as a one-time assertion or as a reusable secret. If the latter is true, the attacker may not need to defeat MFA again after the first capture.
Examples of real-world abuse patterns are well illustrated by Twilio 0ktapus breach 2022, CitrixBleed exploitation 2023, and the broader lessons in MFA Guide.
Exposure Checks and Detection Signals
Organisations check exposure by inventorying where MFA is used, which factors are enabled, and which sessions or tokens can be replayed across devices, browsers, or integrations. They also review whether internet-facing login flows, remote access portals, or legacy authentication paths still accept reusable codes, weak session cookies, or long-lived approvals.
Detection usually focuses on impossible travel, repeated use of the same artefact, unusual session reuse, fresh logins immediately after MFA prompts, and sign-ins from new locations or devices following a legitimate challenge. A replay event often leaves a pattern of valid authentication followed by abnormal access behaviour, so post-incident review should include session revocation, token invalidation, and examination of whether other accounts used the same compromised path.
For known attack tradecraft and investigation context, CISA cyber threat advisories and MITRE ATT&CK Enterprise Matrix are useful references for mapping credential access, session theft, and follow-on lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 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 | Defines authenticators, assurance, and phishing-resistant sign-in relevant to replay-resistant MFA. |
| Recommendation — Use phishing-resistant authenticators and binding methods that prevent captured MFA artefacts from being replayed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Replay of MFA artefacts is an authentication failure that lets attackers reuse valid login material. |
| Recommendation — Harden authentication flows so captured factors and tokens cannot be reused as valid authentication proof. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers strong user authentication controls for preventing reused login artefacts. |
| IA-5 — Authenticator Management | Addresses lifecycle and handling of authenticators, including reuse and invalidation risks. | |
| AU-2 — Event Logging | Logging supports detection of repeated or anomalous authentication attempts and replay patterns. | |
| Recommendation — Enforce strong user authentication and reject reused authentication artefacts wherever possible. Manage authenticators so one-time codes, tokens, and related material are invalidated after use. Log authentication events needed to spot repeated artefact use and suspicious session reuse. | ||
Practitioner Guidance
Why practitioners should care: mfa replay attacks show that “MFA enabled” is not the same as “MFA resistant to interception.” Teams should verify that the factor is single-use, bound to the right session, and paired with controls that invalidate reused artefacts quickly.
What to watch for: Be especially alert to flows that rely on reusable OTPs, weak push approvals, or bearer-style session material without sender-constraining. Those designs tend to fail under phishing and token theft even when the user believes they completed a normal MFA prompt.
Practitioner takeaway: Treat replay resistance as a design requirement, not a nice-to-have, because the strongest MFA deployment is still brittle if a captured artefact can be used again.