Why traditional MFA still fails against phishing attacks

At a glance

What this is: This article argues that traditional MFA is still bypassable because phishing, credential stuffing, push bombing, and man-in-the-middle attacks can defeat common factor types.

Why it matters: It matters because IAM teams need to separate factor presence from phishing resistance and decide where PKI and FIDO materially improve authentication assurance.

By the numbers:

• PKI-based authentication typically accounts for 40% of use cases across non-browser and enterprise login scenarios.
• FIDO-based authentication accounts for approximately 60% of use cases, covering browser-based authentication and Windows workstations.

Context

Traditional MFA reduces password-only risk, but it does not automatically resist modern phishing paths. The key governance question is whether the factor can still be intercepted, relayed, or coerced at authentication time.

For IAM programmes, the issue is not simply having MFA in place. It is whether the organisation is using phishing-resistant authentication for identities that face browser-based, remote access, and high-value workflow exposure.

This article is typical of the current market problem: many teams have MFA coverage, but not necessarily MFA that holds up under adversary-in-the-middle and prompt fatigue techniques.

Key questions

Q: Why do traditional MFA methods fail against phishing attacks?

A: Traditional MFA fails because many methods still depend on a code, prompt, or approval that an attacker can intercept, relay, or coerce in real time. Once the factor is replayable, the second step no longer proves the original user is present. That turns MFA into a weaker speed bump instead of a durable identity control.

Q: When should organisations replace legacy MFA with phishing-resistant MFA?

A: They should do it first for privileged accounts, remote access, and any workflow that attackers can target with phishing or adversary-in-the-middle attacks. If the access path protects sensitive systems and the current factor can be replayed or approved out of band, the upgrade should move from backlog to priority.

Q: How can security teams tell whether adaptive MFA is working properly?

A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion. If adaptive MFA is triggering everywhere, it is behaving like blunt MFA. If it rarely triggers on risky actions, the policy is too weak to matter.

Q: What is the difference between certificate-based authentication and FIDO in practice?

A: Certificate-based authentication is strongest where device-bound trust and managed issuance are needed, while FIDO is often better where supported applications and user experience matter most. Many enterprises need both. The decision is less about which method is better overall and more about which one fits the access path, platform, and assurance requirement.

Technical breakdown

Why traditional MFA can still be phished

Traditional MFA adds a second check, but many implementations still depend on secrets or approvals that an attacker can intercept in real time. SMS codes, OTPs, and push approvals can be relayed, socially engineered, or exhausted through prompt bombing. That is why the existence of MFA is not the same as resistance to phishing. The core weakness is that the authentication ceremony can still be replayed, proxied, or coerced without the attacker ever needing to break the underlying password directly.

Practical implication: evaluate MFA by attack resistance, not by factor count.

How PKI and FIDO change authentication assurance

Phishing-resistant authentication uses public key cryptography so the authenticator proves possession without revealing a reusable secret to the attacker. In PKI, certificates bind identity to devices or users for non-browser and enterprise scenarios. In FIDO, the authenticator signs the challenge for the specific origin, which makes credential replay and fake login pages far harder to exploit. These methods do not eliminate all identity risk, but they materially narrow the ways an attacker can steal and reuse authentication evidence.

Practical implication: map use cases to the authenticator class that actually resists relay and replay.

Why browser and non-browser use cases need different controls

Browser logins, workstations, remote desktop, and federation workflows do not all fail in the same way, so one authentication pattern will not cover every access path equally well. The article’s distinction between FIDO and PKI is important because it reflects where each control is strongest. Browser-based SSO benefits from FIDO-style flows, while workstation and service-oriented access often needs certificate-backed identity. The technical problem is coverage alignment, not just deployment volume.

Practical implication: segment authentication standards by access path instead of forcing one method everywhere.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

Factor count is not the control objective: Traditional MFA programmes often measure adoption instead of resistance. That creates a false sense of assurance when the deployed factor can still be phished, relayed, or approved under pressure. The practitioner takeaway is that authentication governance has to test adversary resistance, not checkbox coverage.

Phishing-resistant MFA is an assurance model, not a brand category: The article correctly separates generic MFA from FIDO and PKI because the security value comes from the trust property, not the marketing label. Organisations that treat all MFA as interchangeable will keep exposing browser logins and remote access to adversary-in-the-middle attacks. Identity teams need method-specific governance, not one undifferentiated MFA policy.

Authentication architecture should follow the use case, not the deployment preference: Browser SSO, workstation access, and non-browser enterprise workflows have different assurance needs. PKI and FIDO are complementary because they solve different identity paths, which means programme design should be access-path aware. The practitioner conclusion is to align the factor to the workflow, then verify that the resulting trust model actually blocks replay and relay.

Phishing-resistant MFA is now a board-relevant control boundary: Guidance from CISA, NIST, and the White House has turned this from a technical preference into a governance expectation. That does not mean every access path needs the same method, but it does mean programmes must be able to explain where non-resistant MFA still exists and why. The decision point is no longer whether MFA exists, but where it remains phishable.

Identity attack surface shrinks only when authentication is origin-bound: This article sharpens a useful concept for the field, phishing-resistant authentication boundary. Where authentication is tied to a real cryptographic proof rather than a transferable secret or approval prompt, the attacker’s reuse options collapse. Practitioners should treat that boundary as a design requirement for high-value identities.

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

Phishing-resistant authentication should now be treated as a programme boundary, not a niche hardening option. Teams that continue to count MFA coverage without testing relay resistance will keep overestimating their actual identity assurance.

Phishing-resistant authentication boundary: This is the line between authentication methods an attacker can reuse and methods that remain tied to the real origin and authenticator. Practitioners should define that boundary explicitly for privileged access, remote access, and other high-value workflows.

Identity programmes that still mix phishable MFA with stronger methods need a clean inventory of where each one applies. That inventory becomes the basis for sequencing migration, policy exceptions, and assurance reporting.

For practitioners

• Inventory phishing-exposed authentication paths Map which user groups, applications, and remote access flows still rely on SMS, OTP, push approvals, or other phishable MFA methods. Prioritise internet-facing and privileged access paths first.
• Separate browser and non-browser control standards Use FIDO-style controls where origin-bound browser authentication is feasible, and certificate-backed authentication where workstation, RDP, VDI, or other non-browser access needs stronger device or user proof.
• Eliminate approval-only push dependence Treat push fatigue and prompt bombing as governance failures, not user mistakes. Require methods that do not depend on blind approvals for identities that can reach sensitive systems.
• Align federation and provisioning with stronger auth Review SAML, OIDC, SCIM, and RADIUS flows together so that stronger authentication does not stop at the login page. Identity assurance should remain consistent across federation and provisioning boundaries.

Key takeaways

• Traditional MFA can still be bypassed when the attacker can intercept, replay, or fatigue the authentication step.
• Phishing-resistant methods such as FIDO and PKI change the trust model by making the login harder to reuse outside the intended context.
• IAM teams should map access paths by risk and move high-value workflows to authentication that resists relay and origin spoofing.

Key terms

• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Push Bombing: Push bombing is an MFA bypass technique that overwhelms a user with repeated authentication prompts until one approval is granted. The attack depends on fatigue, distraction, or confusion, not on breaking the underlying cryptography. It is effective because many organisations still treat user approval as a trustworthy security signal.
• Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
• Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.

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 building or maturing an IAM programme, it is worth exploring.