MFA & Phishing Resistance

Multi-factor authentication is the single highest-leverage control the helpdesk owns — and also the one most often shipped as a compliance checkbox instead of a real defence. This level treats factors as a spectrum, not a binary "MFA on/off", and asks you to pick the right mix for each user archetype.

Factor families

Every factor fits into one of three categories. A real MFA deployment mixes categories, not just factors.

• Knowledge — something you know: passwords, recovery codes, security questions. Trivially phishable, trivially reusable, trivially breach-exposed.
• Possession — something you have: an authenticator app generating TOTP codes, a push-approval device, a hardware FIDO2 key, a passkey bound to a platform keychain.
• Inherence — something you are: Touch ID / Face ID / Windows Hello. Usually the unlock for a possession factor rather than a factor on its own wire, because biometric templates don't travel over the internet.

The product terms you'll hear — Duo, Okta Verify, Microsoft Authenticator, Google Authenticator, 1Password, YubiKey, Titan Key — are implementations of one of those possession shapes. The category matters more than the vendor.

The phishing-resistance gradient

Factors resist phishing to wildly different degrees. The ordering isn't intuitive if you've only heard "MFA good, no-MFA bad":

Factor	Phishing resistance	Why
SMS code	Weak	Can be relayed by any MITM page; SIM-swap defeats it outright.
TOTP (authenticator app)	Medium	Realtime proxy phish (evilginx, modlishka) captures the 6 digits as the user types them.
Push approval	Medium	"Push-fatigue" attacks: hammer the user until they accept. Number-matching helps.
Hardware OTP (YubiKey OTP)	Medium	Long secret, but still a shared string the user can be tricked into typing into the wrong page.
FIDO2 / passkey	Strong	The authenticator is bound to the RP's origin and refuses to sign for anything else.

That last row is the whole point of this level. WebAuthn's origin binding is what makes FIDO2 and passkeys unphishable: when the browser asks the authenticator for an assertion, it scopes the request to the current page's origin. An attacker's good-bank.evil.example is a different origin, so even a perfectly crafted lookalike page gets a refusal from the user's security key — no user decision to bypass, no code path to exploit.

The SIM-swap tax

SIM-swapping is the threat most often underrated in MFA reviews: an attacker social-engineers the carrier into transferring the victim's number to the attacker's SIM, then receives every SMS code and every voice call. For high-value accounts it's a $150-and-half-an-hour attack. Krebs on Security has catalogued dozens of case studies — executives, crypto holders, journalists — where SMS was the sole second factor and the attacker didn't even need to phish.

Rule: if SMS is your only second factor, you don't have MFA, you have account recovery for the attacker.

Enrolment and recovery

A perfect FIDO2 deployment falls apart at enrolment and recovery — the two moments where users need out-of-band channels.

• Enrolment: the first time a user registers a FIDO2 key, they're doing it over the first-factor password. That first-factor password is phishable. Best practice: enrol in-person at onboarding, or use a time-limited enrolment link delivered over a channel the attacker can't compromise (admin-console-scoped email, IT in-person handoff).
• Recovery: when a user loses their only FIDO2 key, the recovery flow is by definition weaker than the primary factor. Popular mistakes: "recover via SMS", "recover via security questions", "recover via a recovery code the user stored in their notes app". Better patterns: require a second registered FIDO2 key from day one; or gate recovery behind helpdesk verification with proof-of-life.

The "backup factor downgrades the primary" gotcha

If your phishing-resistant primary has a weak fallback, your effective posture is that of the weakest enabled factor. An attacker who can't phish your FIDO2 key just triggers the "I lost my key" flow and receives the SMS. This is why Okta, Microsoft and Google have all moved toward admin-controlled recovery paths rather than user-initiated SMS recovery.

Shared push notifications on a cellular carrier are a related gotcha: a carrier-level attacker can intercept push approvals the same way they intercept SMS. This is why Microsoft's "number matching" and Duo's "Verified Push" require the user to type a code shown on screen into the phone — closing the gap an intercepted push notification could exploit.

Break-glass accounts

Every MFA deployment needs a break-glass path: an admin account usable when the primary IdP is down. Requirements:

• Stored in a physical safe (Yubikey + paper credentials).
• Usage alerts out to multiple channels.
• Different IdP from the primary (Okta-admin break-glass accounts should NOT depend on Okta being online).
• Periodically tested — an untested recovery path is an unverified assumption.

Playground

Pick an archetype, toggle factor checkboxes, and watch the per-threat scores update live. The archetype panel lists the threats that archetype must survive — an executive at a bank must resist SIM-swap in a way that a field technician in an offline depot doesn't. Try adding SMS as a "backup" to a FIDO2 primary and watch the phishing score drop.

Visualizer

The threat grid plots every factor × every threat. Rows are factors, columns are threats, cells are resistance on a red → yellow → green gradient. The column for "phishing" is the teaching moment: SMS and TOTP sit in the low-to-medium band; FIDO2 and passkey saturate green. The column for "SIM swap" is the second teaching moment — anything that routes through your phone number is weak.