Multi-Factor Authentication (MFA) works by requiring two or more different authentication factors, such as something you know, have, or are, before granting access. After the primary secret, the user must prove a second factor through an app, device, or biometric. Security teams should prefer phishing-resistant factors where possible and protect enrolment, recovery, and step-up prompts from abuse.
How MFA actually changes the sign-in process
MFA works by adding a second proof step after the primary credential is accepted. In practice, that means access is no longer decided by a password alone, but by a combination of independent factors that are harder to steal or guess together. The strength of MFA depends on how independent those factors really are, and on whether the second factor can resist phishing, relay, or push fatigue.
That is why modern MFA is shifting away from shared secrets and toward stronger possession-based factors, such as passkeys or security keys. A factor that is easy to intercept or reuse may still improve security, but it does not provide the same resistance against an active attacker who already has a password.
Why some MFA methods are much weaker than others
Not every second factor gives the same protection. SMS codes, one-time passwords, and push prompts can still be defeated through phishing, social engineering, or real-time interception. The practical question is not just whether MFA is enabled, but whether the chosen method blocks the attack paths most likely to target your users.
MFA Guide covers the common attack patterns that weaken traditional MFA, including fatigue attacks, relay attacks, and token theft. It is useful when you need to compare methods rather than treat all MFA as equivalent.
Passwordless and Passkeys Guide is the right companion when the goal is phishing-resistant authentication, because it explains why passkeys and FIDO2-style authentication reduce the value of stolen passwords and intercepted one-time codes.
Enrollment and recovery matter just as much as the sign-in challenge itself. If attackers can add their own device, reset the account through weak help desk procedures, or exploit recovery shortcuts, they can bypass a strong MFA stack without defeating the factor at login.
Where MFA fails in real environments
MFA often fails when organisations protect the front door but leave the side doors open. Legacy accounts, service portals, weak recovery flows, and session theft can all bypass the intended protection. Once an attacker has a valid session token, the original MFA challenge may no longer matter.
Microsoft Midnight Blizzard breach shows how an account without MFA can become the entry point for a serious compromise, especially when legacy or non-production access is not governed as carefully as primary workforce access.
CitrixBleed exploitation 2023 is a clear example of why session protection matters alongside MFA, since stolen session cookies can let attackers bypass the sign-in step entirely.
Dropbox Sign breach 2024 also shows that MFA alone does not eliminate exposure if backend service credentials, tokens, or administrative access are compromised elsewhere in the environment.
Risk and Threat Considerations
MFA reduces account takeover risk, but it is not a guarantee if the factor can be relayed, fatigued, or bypassed through recovery and session theft. The main security failure is assuming that “MFA enabled” means “phishing-resistant” or “compromise resistant” when the chosen method may still be vulnerable to active attackers.
Failure mechanism: Attackers commonly defeat weak MFA by stealing the primary password first, then using phishing kits, push bombing, help desk abuse, SIM swap, or stolen session tokens to satisfy or bypass the second factor.
Impact: The result can be account takeover, privileged access abuse, lateral movement, token replay, and persistence even after the user changes their password.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 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 | NIST SP 800-63 Digital Identity Guidelines — Digital Identity Guidelines | Covers authenticator assurance and phishing-resistant authentication methods. |
| Recommendation — Use AAL and phishing-resistant authenticator guidance to choose stronger MFA methods. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MFA is an organizational user authentication control. |
| IA-5 — Authenticator Management | MFA depends on secure issuance, rotation, and protection of authenticators. | |
| Recommendation — Implement IA-2 to require multifactor authentication for organizational users. Apply IA-5 to manage authenticators across enrollment, use, recovery, and revocation. | ||
| OWASP ASVS | V6 — Authentication | MFA is a core application authentication requirement. |
| Recommendation — Verify MFA strength, enrollment, and recovery under V6 authentication requirements. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Non-human accounts can also rely on MFA-adjacent authentication paths and stronger factors matter. |
| Recommendation — Review non-human authentication flows for weak second factors and relayable secrets. | ||
Practitioner Guidance
What to verify: Confirm which MFA methods are actually in use for high-value accounts, because the risk profile changes materially between SMS, OTP, push approval, and phishing-resistant factors. Also verify that recovery, enrollment, and step-up prompts have stronger controls than ordinary self-service reset paths.
Decision rule: If an account can reach production systems, admin consoles, finance, source code, or identity infrastructure, prefer phishing-resistant MFA and treat weaker methods as temporary exceptions rather than baseline control.
What practitioners underestimate: The second factor is only one part of the trust chain. If attackers can hijack the session, abuse recovery, or enroll a new factor, the MFA control may look effective on paper while still failing under real attack pressure.
Practitioner takeaway: Strong MFA is less about the label and more about whether the second step is resistant to real-world phishing, relay, and recovery abuse.
Related resources from NHI Mgmt Group
- 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?
- Should organisations extend multi-factor authentication to personal devices used for work?
- What is the difference between multi-factor authentication and phishing-resistant MFA in a DORA context?
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org