What is phishing-resistant MFA?

Key takeaways

• Phishing-resistant MFA cryptographically binds the authentication to the legitimate relying party. A phishing page cannot complete the authentication even if the user tries.
• FIDO2 and passkeys are the two primary phishing-resistant options. Both are widely supported across major identity providers in 2026.
• Most mid-market manufacturers still run push-based MFA, which is bypassable through phishing-page proxying, MFA fatigue attacks, and adversary-in-the-middle tooling.
• The migration from push to phishing-resistant MFA typically runs six to twelve months and is the highest-leverage identity-side security investment for mid-market manufacturers.
• Cyber insurance underwriters increasingly require or strongly prefer phishing-resistant MFA; the migration produces material premium impact.

What makes an MFA factor "phishing-resistant"?

The defining property is cryptographic origin binding. The authentication exchange between the user's device and the identity provider includes a check that the requesting site (the relying party) matches the site the credential was registered against. If a phishing page proxies the authentication to the legitimate identity provider, the cryptographic binding fails; the authentication does not complete.

Specifically:

• The authenticator (security key, smartphone with passkey) signs an authentication assertion that includes the relying party identifier.
• The browser passes the relying party identifier from the current site, not from anything the attacker can manipulate.
• If the user is on a phishing page (say, login.microsoft-secure.com instead of login.microsoftonline.com), the relying party identifier does not match the one the credential was registered against, and the authenticator refuses to sign.

This is fundamentally different from how push-based, SMS-based, and TOTP-based MFA work. Those factors verify possession (the user has the device) but do not bind the authentication to a specific origin. A phishing page can capture the OTP or push the user to approve, and the attacker can replay the captured factor at the legitimate site.

Phishing resistance is a property of the protocol, not the device. A FIDO2 hardware key is phishing-resistant because of how WebAuthn works, not because it is a physical token. A passkey synced across devices is equally phishing-resistant because it uses the same WebAuthn protocol.

The hierarchy: SMS, TOTP, push, number matching, FIDO2/passkeys

MFA factors are not equally secure. The hierarchy, from weakest to strongest:

1. SMS. Codes sent to a phone number. Vulnerable to SIM swap attacks, SS7 protocol exploitation, and phishing (the user enters the code into a phishing page). Better than no MFA, but considered insufficient by current standards. NIST SP 800-63B has deprecated SMS as restricted; many compliance frameworks require stronger.

2. TOTP (Time-based One-Time Passwords). Codes generated by an authenticator app (Microsoft Authenticator, Google Authenticator, Authy) rotating every 30 seconds. Not vulnerable to SIM swap or SS7. Still vulnerable to phishing: the user types the current code into a phishing page; the attacker replays it within the 30-second window.

3. Push notifications. A prompt on the user's authenticator app asking them to approve or deny. Better user experience than TOTP. Vulnerable to MFA fatigue and to phishing-page proxying. The user thinks they are approving the login they initiated; they are actually approving the attacker's login from a different IP.

4. Push with number matching. The login screen displays a number; the user enters that number in the authenticator app to approve. Defeats unsophisticated MFA fatigue (the user cannot just tap "approve" without context). Still vulnerable to adversary-in-the-middle phishing pages that proxy the entire authentication flow and display the matching number to the user.

5. FIDO2 hardware keys. Phishing-resistant. Cryptographic origin binding. The hardware key itself does not authenticate to a phishing page. See What is FIDO2?.

6. Passkeys. Phishing-resistant. Same WebAuthn protocol as FIDO2 hardware keys, but the credential is stored on the user's device (phone, laptop) and (optionally) synced across the user's devices. Better user experience than hardware keys; same security properties. See What is a passkey?.

For most mid-market manufacturers in 2026, the migration target is passkeys for general workforce with hardware FIDO2 keys for high-risk roles (executives, finance, IT, admin) and for shop-floor environments where personal smartphones are not appropriate.

Why mid-market manufacturers are still on push-based MFA

Push-based MFA is operationally familiar, broadly compatible, and "good enough" to satisfy basic insurance and compliance questions. Five reasons mid-market manufacturers have not migrated:

1. Existing deployment. Microsoft Authenticator, Duo, or Okta Verify is already deployed; the team is familiar with it; users have it installed; help desk knows the recovery procedures. Migration disrupts a working system.
2. Compatibility concerns. Some applications, vendor portals, or legacy systems do not natively support FIDO2. The migration requires either dual-factor support, vendor coordination, or workarounds.
3. Help-desk capacity. A FIDO2 rollout produces a wave of help-desk tickets (lost keys, recovery scenarios, application-specific issues). Mid-market IT teams do not have the spare capacity without planning.
4. No driving incident. Without a documented MFA bypass incident in their own history, the urgency for migration competes against other priorities. Other manufacturers' incidents do not produce the same urgency as one's own.
5. Underestimating push vulnerability. Push-based MFA is materially weaker than commonly understood. Many IT leads believe push is "phishing-resistant enough" until they see a working adversary-in-the-middle demonstration.

The fix is not to argue urgency through abstract security improvement; the fix is to demonstrate the bypass against the organization's actual environment during adversarial simulation and to plan the migration with realistic timelines and help-desk capacity.

Examples of MFA bypass attacks

Real-world incidents that demonstrate the weakness of weak MFA.

• Uber (September 2022). Attacker obtained credentials for an Uber contractor and bombed push prompts. Paired with social engineering via WhatsApp ("this is Uber IT, please approve"). Contractor approved. Attacker reached internal Slack, AWS, and admin tooling. See What is an MFA fatigue attack?.
• Cisco (May 2022). Employee's Google credentials compromised through phishing. Push fatigue followed by vishing call from "Cisco IT" produced approval. Attacker reached VPN; data exfiltration followed.
• Microsoft (Lapsus$, 2022). Multiple high-profile compromises across the industry through MFA fatigue paired with social engineering. Demonstrated the pattern works against well-defended organizations.
• Reddit (February 2023). Sophisticated phishing campaign targeted Reddit employees with a fake intranet site that proxied authentication. Employees who entered credentials and approved push prompts gave the attacker valid session tokens.
• Twilio (August 2022). Smishing campaign captured employee credentials; the attacker's adversary-in-the-middle tooling proxied the legitimate authentication including the MFA factor; employees did not see the attack.
• Multiple mid-market manufacturer events (continuing). Vendor-impersonation pretext call to help desk results in MFA reset; attacker authenticates with new MFA enrolled to their device. Vishing-paired MFA bypass is the most common pattern at mid-market scale.

The pattern: in every case, the MFA factor in use was push-based or TOTP. In no documented case has a FIDO2 or passkey credential been defeated through phishing.

How to migrate a mid-market environment to phishing-resistant MFA without breaking workflows

The migration runs through five phases. Total elapsed time for a 200-person manufacturer: typically six to twelve months.

Phase 1: Plan and inventory (weeks 1-4). Catalog the applications and vendor relationships that authenticate through the identity provider. Identify which support FIDO2/WebAuthn natively, which support it through SAML federation, which do not support it at all. Plan the target end state: passkeys for general workforce, hardware keys for high-risk roles, exceptions documented.

Phase 2: Pilot with IT and executives (weeks 5-8). Roll out FIDO2 to IT staff and the executive team. Surface compatibility issues, recovery edge cases, and help-desk procedures. Adjust the plan based on findings.

Phase 3: High-risk roles (weeks 9-16). Finance, AP, HR, and any role with access to the ERP, CUI, or financial systems. Cohort-by-cohort rollout with named help-desk coverage. Each cohort completes before the next starts.

Phase 4: General workforce (weeks 17-32). Cohort-by-cohort migration. Continued help-desk coverage. Communications about expectations and timelines.

Phase 5: Disable weak factors (weeks 33-48). Once everyone is on phishing-resistant MFA, disable push-based and SMS-based MFA tenant-wide. The migration is not complete until the weak factors are no longer available; as long as they exist, attackers route to them.

Throughout the migration, adaptive simulation tests credential-harvest and MFA-bypass patterns against the changing posture. The simulation surfaces gaps in the migration before attackers do.

Best practices for staged MFA rollout

1. Plan the destination before starting the journey. "Passkeys for everyone, hardware keys for high-risk roles, no push MFA tenant-wide" is the kind of clear destination that keeps individual decisions inside a coherent path.
2. Roll out by cohort, not by application. Cohort-by-cohort produces predictable help-desk load; application-by-application produces wide thin coverage with no clear progress.
3. Reserve help-desk capacity per cohort. Each cohort's transition requires extra help-desk capacity for two to three weeks. Plan for it explicitly.
4. Pre-stage hardware keys before the cohort window. Keys arrive at the cohort before the migration date. Recovery keys provisioned. Documentation prepared.
5. Validate vendor compatibility ahead of time. Each vendor relationship that authenticates through the identity provider gets tested with FIDO2 before the cohort migration. Issues surface in planning, not during rollout.
6. Disable weak factors once everyone is moved. Until the weak factor is removed, the attacker can route to it. The disable step is the migration's completion, not an optional cleanup.
7. Communicate transparently. The workforce knows the migration is happening, why it matters, what the timeline is. Surprises produce resistance.
8. Integrate with broader identity work. PAM, least privilege, and conditional access policy all interact with the MFA migration. Treat them as a single program where possible.

Phishing-resistant MFA FAQs

Is number matching considered phishing-resistant?

No, although it is materially better than plain push. Number matching raises the bar for MFA fatigue attacks but does not prevent phishing: a credential-harvest page that proxies to the legitimate identity provider can display the same matching number to the user. Number matching is a useful interim control on the migration path; FIDO2 or passkeys are the destination.

Do passkeys count as MFA?

Yes. A passkey combines possession (the device that holds the key) and (typically) biometric or PIN verification on the device. Most identity providers accept passkeys as satisfying multi-factor authentication requirements, including those in NIST SP 800-63B. See What is a passkey?.

What is the cost of moving to FIDO2 hardware keys?

Hardware keys cost $25 to $75 per key in volume; most users need two (a primary and a backup). For a 200-person organization, hardware costs are $10k to $25k. The larger cost is rollout: help desk capacity during transition, user training, recovery procedures for lost devices, and integration with applications that do not support FIDO2 natively.

How does phishing-resistant MFA affect remote vendors?

Vendors with remote access into the environment need to support phishing-resistant MFA on their accounts. Many vendor accounts run on push-based or TOTP MFA today. Migrating vendor authentication is a coordination effort with each vendor: some can adopt passkeys easily, some require hardware keys, some have stale tooling that requires upgrade. The work is real and worth planning. See What is third-party risk for manufacturers?.

How ARG tests MFA strength during simulation

ARG tests MFA resilience as part of continuous adversarial simulation. The testing covers both the technical strength of the MFA factor and the procedural workflows that depend on it.

The simulation is operated by James Wall on infrastructure ARG controls. Where the engagement scope authorizes credential-acquisition simulation, ARG runs:

• Adversary-in-the-middle phishing. Lures that proxy the authentication flow through an attacker-controlled site. The simulation confirms whether push, TOTP, or number-matching MFA is defeated by the proxy; passkeys and FIDO2 keys are not.
• Push bombing simulation. Repeated push prompts to a defined target account (with prior authorization). Measures whether the user approves under pressure and whether the defending stack alerts on the pattern.
• Help-desk vishing for MFA reset. Pretexted calls to the help desk requesting MFA reset on a targeted account. Measures whether the help-desk verification workflow holds against social engineering. See What is vishing?.
• Consent phishing flow. OAuth consent grants that bypass MFA entirely. Measures whether MFA migration has been paired with OAuth governance. See What is consent phishing (OAuth phishing)?.

Findings consolidate into the monthly operational packet alongside the rest of the engagement. The remediation backlog includes specific MFA-related items: factor migration progress per cohort, workflow tightening at the help desk, OAuth policy adjustments. The output supports insurance underwriting evidence (carriers increasingly ask about phishing-resistant MFA coverage) and CMMC / NIST SP 800-171 compliance evidence (control 3.5.3 requires MFA with strengthening expectations as standards evolve).

For founding clients, MFA migration is one of the operational improvements the engagement supports through technical testing, workflow validation, and continuous re-testing as the migration progresses.

Apply as a founding client or see how the engagement works for the full delivery cycle.