Good enough MFA leaves identity teams exposed to phishing

At a glance

What this is: This is Axiad's analysis of why basic MFA still fails against phishing and why phishing-resistant authentication remains underdeployed.

Why it matters: For IAM teams, the issue is not whether MFA is enabled but whether the chosen factor actually changes the attacker’s path to account takeover.

By the numbers:

• 93% of organisations are still using passwords at work or for business, according to an Axiad survey of more than 200 IT professionals.
• more than 200 IT professionals

Context

Basic MFA often creates a false sense of closure: the control is present, but the authentication boundary remains vulnerable to phishing, SIM swapping, and man-in-the-middle interception. For identity programmes, the real question is whether MFA resists adversary-in-the-middle tactics or merely adds another prompt to approve.

The article is about human authentication, not NHI governance. Its practical relevance is that IAM teams frequently satisfy policy requirements with weak second factors, then discover that the attack surface changed very little. That gap between control presence and control effectiveness is the central problem here.

Key questions

Q: What is the difference between strong MFA and phishing-resistant MFA?

A: Strong MFA means more than one factor is used, while phishing-resistant MFA means the factor cannot be easily captured and replayed by an attacker. A code sent by text may count as MFA, but it is not resistant enough for high-risk accounts because the secret can be stolen outside the application itself. Resistance is the higher standard.

Q: Why do organisations still get compromised even after deploying MFA?

A: Because MFA is not a single control, it is a control design. If the factor relies on push approval, secret sharing, or user attention under pressure, an attacker can still manipulate the process after stealing credentials. Organisations remain exposed when MFA is treated as a checkbox instead of a trust model with risk-based enforcement.

Q: How should IAM teams decide when phishing-resistant authentication is needed?

A: Use phishing-resistant methods wherever account compromise would create material business or operational impact, especially for remote access, privileged users, and high-value applications. If a login path can unlock lateral movement, administrative action, or sensitive data, it deserves stronger authentication than phishable MFA.

Q: Should organisations replace SMS and OTP MFA first, or focus on privileged access first?

A: Focus on privileged access first. The highest-value accounts are where phishing-resistant methods deliver the greatest risk reduction, while low-risk populations can be transitioned later without leaving the organisation’s most sensitive systems exposed. Sequencing by blast radius is usually more defensible than a broad, equal-speed migration.

Technical breakdown

Why SMS, OTP, and push MFA remain phishable

SMS codes, one-time passwords, and push approvals are all possession factors, but they still depend on shared secrets or user interaction that an attacker can intercept or coerce. In a phishing or man-in-the-middle flow, the adversary relays the login session, captures the code, or tricks the user into approving access. The factor exists, but the authentication ceremony does not prove the user is talking to the real service. That is why these methods reduce risk compared with passwords alone but do not eliminate credential replay, session hijack, or proxy-based account takeover.

Practical implication: Treat these methods as transitional controls, not as the end state for high-risk access.

How phishing-resistant MFA changes the trust model

Phishing-resistant authentication uses cryptographic binding so the authenticator verifies the relying party and the credential cannot be replayed through a fake login page. FIDO2/WebAuthn and PKI shift the problem from shared knowledge or transferable codes to proof anchored in device-bound or certificate-based trust. That materially narrows the attacker’s options because the credential is not a generic token that can be phished and reused elsewhere. For IAM, this is less about stronger MFA branding and more about changing which part of the stack is trusted during authentication.

Practical implication: Prioritise authentication methods that bind the user, device, and service together cryptographically.

Why implementation friction keeps strong MFA from scaling

The article points to complexity, cost, and integration effort as the main blockers to broader adoption. Those blockers are operational, not theoretical: teams must account for device enrollment, certificate or key lifecycle, help desk changes, and application compatibility. That is why many organisations default to what is already available in their stack, even when it offers weaker resistance to phishing. The result is an authentication programme that looks mature on paper but still leaves the most common entry path open.

Practical implication: Plan migration around application compatibility and enrolment operations, not just policy approval.

Threat narrative

Attacker objective: The objective is to bypass basic MFA and obtain authenticated access to protected accounts and internal systems.

1. Entry occurs when the attacker delivers a phishing page, MITM kit, or relay flow that sits between the user and the legitimate service.
2. Credential_harvested happens when SMS codes, OTPs, or push approvals are captured, relayed, or manipulated into a successful login event.
3. Impact follows as the attacker gains access to protected resources that the organisation believed were secured by MFA, including internal tools and sensitive accounts.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compliance-grade MFA is not the same as phishing-resistant identity security: The article shows how teams can satisfy an MFA mandate while leaving the attacker’s path largely unchanged. The control exists, but the trust model still allows relay attacks, SIM swap abuse, and approval fatigue. For IAM leaders, that means security posture is being measured by deployment presence instead of attacker resistance.

Good enough MFA is a governance failure, not just a technical shortcut: Organisations often choose the easiest factor available because it fits the current stack and the current budget. That creates a structural mismatch between policy intent and real adversary conditions, especially when phishing remains the primary initial access path. The practitioner conclusion is that authentication assurance must be judged by compromise resistance, not adoption rate.

Phishing-resistant MFA changes the identity assurance boundary: FIDO2/WebAuthn and PKI shift authentication away from transferable secrets and toward cryptographic proof. That matters because it limits replay and relaying in ways that basic MFA never can. The implication for identity programmes is that factor selection is a security architecture decision, not a user-experience preference.

Shared-secret dependency: Basic MFA methods still rely on codes or approvals that can be forwarded, intercepted, or coerced. That assumption was designed for a world where the authenticator path was trustworthy enough to complete the ceremony. That assumption fails when adversaries can sit in the middle of the login flow, so teams must rethink whether the factor actually binds the user to the real service.

Phishing resistance should be treated as a baseline for high-value access: If privileged users, administrators, or sensitive internal applications still accept weak MFA, the identity programme remains open to the most common compromise pattern. This does not mean every account needs the same factor set, but it does mean assurance should track risk tier. Practitioners should move policy from generic MFA coverage to phishing-resistant coverage for critical access.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Good enough MFA is a control-quality problem, not a coverage problem: Many organisations already have MFA, but the attack surface remains open if the chosen factor can be relayed or socially engineered. Identity teams should separate deployment metrics from resistance metrics and treat that distinction as a programme-level risk indicator.

Phishing resistance is increasingly the dividing line between box-ticking and assurance: When login controls still depend on transferable secrets, the authentication boundary is too weak for high-value accounts. The practical consequence is that authentication roadmaps need to move from “MFA everywhere” to “phishing-resistant MFA where compromise matters most.”

For practitioners

• Prioritise phishing-resistant MFA for privileged accounts Move administrators, help-desk operators, and access to sensitive internal tools onto FIDO2/WebAuthn or certificate-based authentication first, because those accounts carry the highest blast radius if phished.
• Inventory where basic MFA still creates exposure Map SMS, OTP, and push approval use across applications, then flag the systems where relay attacks or push fatigue would produce the most damaging compromise.
• Separate compliance coverage from assurance coverage Track not only whether MFA is enabled, but whether the deployed factor resists phishing, man-in-the-middle interception, and code replay in the current access path.
• Plan rollout around enrolment and recovery operations Account for device registration, certificate lifecycle, support workflows, and application compatibility before broadening phishing-resistant authentication beyond pilot groups.

Key takeaways

• Basic MFA can satisfy policy requirements while still leaving organisations exposed to phishing and relay attacks.
• The article’s evidence shows that weak second factors change the user journey more than they change attacker capability.
• IAM teams should prioritise phishing-resistant authentication for privileged access and treat deployment convenience as a secondary concern.

Key terms

• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Man-in-the-Middle Attack: A man-in-the-middle attack is an interception technique where an attacker positions themselves between two parties that believe they are communicating directly. The attacker can read, alter, or replay traffic, which makes the attack especially dangerous when credentials, sessions, or certificates are involved.
• Phishable factor: Any authentication method that can be stolen, relayed, coerced, or replayed through user deception or session interception. SMS codes, OTPs, and push approvals can all be phishable when the method does not cryptographically bind the user to the real service.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.