Phishing-resistant MFA is now the baseline for human identity

At a glance

What this is: This is an analysis of why OTP, SMS, and push-based MFA no longer provide sufficient protection and why phishing-resistant MFA changes the authentication model.

Why it matters: It matters because IAM teams must harden human authentication paths without creating new approval fatigue, especially for privileged users and regulated environments.

👉 Read eMudhra's analysis of why phishing-resistant MFA is replacing OTP and SMS

Context

Phishing-resistant MFA is the response to a simple problem: authentication methods that rely on shared secrets or human prompt approval are being defeated by modern phishing and telecom abuse. OTP and SMS-based MFA can be intercepted, replayed, or redirected, which means the trust model is already broken before the login completes.

For IAM programmes, this is not just an authentication upgrade. It is a shift from code-based verification to device-bound cryptographic trust, with direct implications for privileged access, user experience, and compliance where stronger authentication is expected.

Key questions

Q: How should security teams phase out OTP and SMS MFA?

A: Start with privileged accounts, remote administrators, and applications that expose regulated or sensitive data. Replace OTP and SMS with device-bound methods such as FIDO2 or passkeys, keep only time-limited exceptions, and track fallback usage as a risk metric. The goal is to remove replayable secrets from the highest-value access paths first.

Q: Why do push-based MFA prompts still create account takeover risk?

A: Push prompts can be abused through MFA fatigue, where repeated requests pressure users into approving a login they did not initiate. The problem is not only user error but a design that places trust in approval behaviour under attack. Contextual prompts help, but cryptographic binding is the stronger control.

Q: What do organisations get wrong about phishing-resistant MFA?

A: Many teams treat it as a technical add-on rather than a change in authentication trust. Phishing-resistant MFA works because the credential is bound to the device and domain, not because users are trained to spot phishing better. That means policy, rollout, and recovery processes must change as well.

Q: Who should be accountable for MFA modernisation in identity programmes?

A: Accountability should sit with IAM, security architecture, and application owners together. IAM owns the authentication standard, security architecture defines the risk threshold, and application owners ensure their systems can support device-bound methods. If responsibility is fragmented, old MFA methods stay in place longer than they should.

Technical breakdown

Why OTP and SMS MFA fail against modern phishing

OTP and SMS authentication depend on secrets that are only secure if they remain private and timely. Real-time phishing proxies can capture credentials and codes as users enter them, while SIM swap attacks redirect SMS messages to attacker-controlled devices. The weakness is structural: the second factor is still a shared secret or a message that can be intercepted outside the authentic session. That makes traditional MFA vulnerable even when users believe they are following the correct login process.

Practical implication: retire SMS and OTP for high-risk access paths and treat them as transitional controls, not end-state identity assurance.

How FIDO2 and WebAuthn change authentication trust

FIDO2 and WebAuthn use public-key cryptography to bind a credential to the authentic device and the intended service. The private key stays on the device and cannot be replayed on a fake domain, which removes the attacker’s ability to steal and reuse a shared code. User presence or verification is also tied to the device itself, so approval happens in the right context rather than in a separate message channel. This is why phishing-resistant MFA is materially different from conventional MFA, not just stronger.

Practical implication: prioritise FIDO2-backed authentication for accounts that can meaningfully change business risk, especially admins and remote users.

Why push MFA creates fatigue risk rather than real assurance

Push-based MFA improves usability but can be undermined by repeated prompts that wear down the user. Attackers exploit the psychology of approval by sending many requests until someone accepts one they should have rejected. Number-matching and context-aware prompts help by adding friction and context, but they still depend on user judgment. That means they reduce some abuse patterns without eliminating the underlying approval-channel weakness.

Practical implication: use number-matching and contextual prompts as interim hardening, but do not treat them as a substitute for phishing-resistant MFA.

Threat narrative

Attacker objective: The attacker’s objective is to obtain authenticated access that bypasses normal user suspicion and supports account takeover or privileged misuse.

1. Entry occurs through real-time phishing proxies, SMS interception, or push-bombing that reaches the user during authentication.
2. Credential access follows when the attacker captures OTPs, approvals, or redirected messages and reuses them immediately.
3. Impact occurs when the attacker gains authenticated access to the user or administrator account and can operate inside trusted systems.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant MFA is now the minimum viable control for human identity assurance. OTP and SMS were built for a login world where the channel could be trusted long enough for a code to arrive and be used. That assumption no longer holds when attackers intercept the session in real time or redirect the delivery path. The implication is that identity programmes need to stop treating code-based MFA as a durable trust layer and reclassify it as an interim control only.

Approval fatigue is a governance failure, not just a user experience issue. Push bombing works because the control transfers security judgment to the user under repeated pressure. That means the authentication design itself is exposing the organisation to predictable human error. Teams should treat push fatigue as evidence that authentication assurance is too dependent on behavioural compliance.

Cryptographic binding changes the assurance model more than any policy reminder can. FIDO2 and passkeys reduce dependence on shared secrets, network delivery, and user interpretation of prompts. That makes them especially relevant for privileged users, remote work, and regulated environments where authentication strength matters as much as access scope. IAM teams should view this as a control-plane change, not a feature upgrade.

Number-matching and contextual prompts are useful only as bridge controls. They improve signal quality, but they still leave organisations inside the same approval-channel paradigm that attackers are already exploiting. This is where many programmes stall: they improve the existing model instead of replacing it. Practitioners should use these controls to reduce exposure while accelerating migration to device-bound authentication.

Passkeys and FIDO2 reinforce Zero Trust Architecture by removing replayable secrets from the login path. That aligns human authentication more closely with continuous, cryptographically anchored verification. For identity architects, the real question is not whether the technology is elegant, but whether the access path can still be phished. If the answer is yes, the control is not finished.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader view of identity risk across machine and human access, see The 52 NHI breaches Report for patterns that show how weak trust assumptions compound into compromise.

What this signals

Phishing-resistant MFA should now be treated as a baseline authentication control, not an advanced option. As attackers get better at real-time interception and approval abuse, the remaining risk shifts toward recovery, enrollment, and exception handling. Teams that keep OTP and SMS in the core path will inherit the weakest trust channel in the stack.

Device-bound authentication changes the work for IAM teams as much as it changes the user experience. Rollout is not only about enabling passkeys, it is about aligning recovery, privileged access, and assurance levels so the same weak factor does not reappear during account reset or emergency access. For broader programme context, the 52 NHI Breaches Analysis is useful for understanding how credential weaknesses become operational compromise across identity types.

For practitioners

• Prioritise privileged accounts for phishing-resistant MFA Move administrators, help desk staff, and other high-impact users to FIDO2 or passkeys first. These accounts carry disproportionate blast radius, so early adoption reduces the highest-value attack paths before broad workforce rollout.
• Retire SMS MFA on high-risk access paths Replace SMS and OTP where account takeover would materially affect production systems, regulated data, or privileged administration. Keep a documented exception process only where no stronger method is technically available.
• Use number-matching as a temporary hardening layer Deploy number-matching and contextual prompts while migration work is underway, but set a firm retirement date. These controls reduce push fatigue risk without solving the underlying approval-channel weakness.
• Map authentication strength to access criticality Align authentication requirements to the sensitivity of the application, data, and privilege level. High-risk apps should require device-bound verification, while lower-risk workflows can use less intrusive controls.
• Track adoption by device-bound enrollment Measure how many users, especially privileged users, are enrolled in device-bound authentication versus fallback methods. Adoption metrics should be part of access reviews and identity risk reporting.

Key takeaways

• OTP, SMS, and push-based MFA no longer provide enough assurance against modern phishing and approval abuse.
• FIDO2 and passkeys replace replayable secrets with device-bound cryptographic trust, which is why they change the security model rather than just the login experience.
• IAM teams should phase out weak MFA on privileged paths first and treat transitional controls as temporary, not permanent.

Key terms

• Phishing-resistant MFA: Multi-factor authentication that cannot be easily replayed, intercepted, or approved on behalf of the user. It relies on cryptographic binding and device-held credentials so the factor proves presence at the legitimate service, not just knowledge of a code or acceptance of a prompt.
• FIDO2: A standards-based authentication framework that uses public-key cryptography to create strong, phishing-resistant sign-in methods. It replaces shared secrets with device-bound credentials and supports authentication that is tied to the real service domain, reducing the value of stolen passwords or OTPs.
• Passkey: A device-bound credential used for passwordless sign-in through FIDO2 and WebAuthn. The private key stays on the user’s device and is unlocked by biometrics or a PIN, which makes it harder to phish, replay, or export than traditional secrets-based authentication.
• MFA fatigue: An attack pattern where repeated authentication prompts wear down a user until they approve a malicious request. It exploits human behaviour rather than cryptography, which is why push-based MFA can be undermined even when the login flow appears operationally correct.

What's in the full article

eMudhra's full article covers the operational detail this post intentionally leaves for the source:

• How FIDO2 and passkey authentication differ from OTP in day-to-day deployment decisions
• Why privileged users should be migrated before general users in a phased authentication rollout
• What number-matching and context-aware prompts can and cannot do during the transition period
• How SecurePass positions phishing-resistant MFA for regulated enterprise environments

👉 The full eMudhra article covers FIDO2, passkeys, and transitional controls in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 lifecycle governance, it is worth exploring.