Multi-factor authentication codes are one-time or time-limited numbers used to prove a user has a second authentication factor. They are usually entered after a password, and can be generated by an authenticator app, sent by SMS, or produced by a hardware token, but they are weaker than phishing-resistant factors such as passkeys or FIDO2 tokens.
What MFA codes are used for
MFA codes are a second-step proof, not a complete authentication method on their own. They reduce the value of a stolen password by requiring the user to enter a fresh one-time or time-limited code before access is granted.
They are commonly generated by authenticator apps, sent by SMS, or issued by a hardware token. The security difference matters because code delivery method changes the attack surface, especially when adversaries can intercept messages, phish users in real time, or coerce code entry through social engineering.
How MFA codes work in practice
Most MFA code flows pair a primary login factor, usually a password, with a short-lived code that proves the user still has access to a registered device or channel. The code is typically validated server-side and expires quickly to limit replay.
That design is stronger than password-only sign-in, but it still depends on the protection of the second factor channel. If the code reaches an attacker, or the user is tricked into revealing it during a live phishing session, the control can be bypassed even though it was technically present.
For that reason, modern identity programs increasingly prefer phishing-resistant methods, such as passkeys or FIDO2 security keys, over code-based MFA when the use case allows it. See the NIST SP 800-63 Digital Identity Guidelines for the assurance model behind stronger authenticators.
Common MFA code formats and their trade-offs
Authenticator app codes are usually the best-known code-based option because they do not rely on a carrier network, but they can still be phished or approved in real time. SMS codes are more convenient for users, yet they inherit telecom risk such as SIM swap, message interception, and number recycling.
Hardware token codes are usually more resilient than software-delivered codes because they are generated from a dedicated device, but they still remain code-based rather than phishing-resistant. In other words, the factor can be strong while the overall sign-in experience remains vulnerable to relay attacks and user deception.
The practical takeaway is that “MFA” is not a single security posture. MFA Guide is useful for comparing SMS, authenticator apps, and phishing-resistant options in the context of real-world attack paths.
Why MFA codes matter to account security
Codes are often the difference between a stolen password being useless and an account being taken over. They reduce opportunistic compromise, but they do not eliminate credential theft, session theft, help-desk abuse, or adversary-in-the-middle phishing.
That is why organisations should treat code-based MFA as a step up from passwords, not as the final target state for high-risk accounts. Where the business impact of compromise is high, the more important question is whether the code can be intercepted, relayed, or socially engineered out of the user.
Real incidents show the consequence clearly. Microsoft Midnight Blizzard breach demonstrates how a legacy account without MFA becomes a direct entry point, while CitrixBleed exploitation 2023 shows how session theft can bypass code-based checks entirely after authentication.
Risk and Threat Considerations
MFA codes reduce exposure, but they also create a predictable target for phishing, relay attacks, MFA fatigue, SIM swap abuse, and session hijacking. The risk is highest when organisations assume “MFA enabled” means “phishing-resistant,” or when older code flows remain available for privileged or remote access.
Failure mechanism: Attackers steal, relay, or coerce the one-time code, then pair it with a valid password or stolen session to obtain access. In some environments, the code is only one step in a longer compromise chain that ends in token theft, privilege escalation, or lateral movement.
Impact: A successful bypass can expose email, admin consoles, VPN access, cloud control planes, and downstream secrets or sessions. Once an attacker has a live authenticated session, they often no longer need the original code to persist.
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, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authenticator assurance and phishing-resistant authentication for MFA flows. |
| Recommendation — Use NIST 800-63 to prefer phishing-resistant authenticators over code-based second factors. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authentication of workforce users using multi-factor methods. |
| IA-5 — Authenticator Management | Addresses lifecycle protection for authenticators, including one-time codes and tokens. | |
| Recommendation — Apply IA-2 to require strong multi-factor authentication for organizational access. Use IA-5 to manage issuance, rotation, protection, and revocation of authenticators. | ||
| OWASP ASVS | V6 — Authentication | Specifies application authentication requirements, including multi-factor and recovery flows. |
| V7 — Session Management | Session theft can bypass MFA codes after sign-in, so session controls remain material. | |
| Recommendation — Verify MFA implementation against ASVS V6 and harden recovery paths. Apply ASVS V7 to limit session replay and protect authenticated access after MFA. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports limiting and reviewing access paths that depend on MFA-protected sign-in. |
| Recommendation — Use CIS-6 to restrict access paths to accounts that rely on MFA for authentication. | ||
| MITRE ATT&CK | T1110 — Brute Force | Credential attacks often precede MFA challenge abuse and code-based sign-in attempts. |
| Recommendation — Map repeated sign-in attempts to T1110 and alert on abuse patterns around MFA prompts. | ||
Practitioner Guidance
Why practitioners should care: Code-based MFA is still useful, but it should be evaluated by delivery channel and attack resistance, not by the presence of a second step alone. For high-value users and sensitive systems, prefer phishing-resistant authentication where possible and treat SMS and push-style workflows as lower assurance.
What to watch for: Repeated MFA prompts, unexplained code requests, help-desk reset pressure, legacy accounts that still accept weaker factors, and login methods that can be replayed or relayed. Those signals often indicate that the control is present but not actually resilient.
Practitioner takeaway: The right question is not whether MFA exists, but whether the specific code flow can survive modern phishing and session-theft techniques.
Related resources from NHI Mgmt Group
- What breaks when multi-factor authentication still relies on SMS codes or push approvals?
- How should security teams choose between 2-factor authentication, multi-factor authentication, and adaptive MFA for remote and hybrid access?
- What is the difference between phishing-resistant MFA and conventional multi-factor authentication in cloud security?
- What is the difference between multi-factor authentication and phishing-resistant MFA in a DORA context?