Not all MFA stops a phish

If you do only one thing this month, turn on multifactor authentication. We will say that more than once.

But MFA is not one thing, and the version most organizations switch on is weaker than people assume.

The ladder

From least to most protective:

  • Texted codes. Better than nothing. Vulnerable to SIM swapping and to anyone who can read a lock screen.
  • App-generated codes. The six digits from an authenticator app. A real improvement.
  • Push approvals. The “Approve this sign-in?” prompt on your phone.
  • Phish-resistant: passkeys and hardware security keys.

The first three share one weakness. In each, something human can be talked into handing over.

How codes get beaten now

Attacker-in-the-middle kits are the common method, and they are sold ready-made. The attacker puts a page in front of the real login — visually identical, with an address that is slightly wrong. You type your password; the kit passes it to the real site. The real site asks for your code; the fake page asks you for it; you type it in; the kit relays it within seconds.

You did everything right. You had MFA switched on. You entered a valid code. It simply went to the wrong place.

Push approvals fail differently. An attacker who already has your password triggers approval prompts over and over, often in the middle of the night, until someone taps Approve to stop it.

What phish-resistant actually means

A passkey or a hardware key is bound to the real website’s address. A passkey created for yourbank.org will not offer itself to yourbank-login.com — not because the person is being careful, but because the browser refuses to match it.

And there is nothing to type. The secret never leaves your device, so a fake page can’t capture it or relay it.

Passkeys in plain terms: your phone or laptop holds a private key, and the website holds the matching public one. You unlock it with a fingerprint, your face, or a device PIN. Nothing secret crosses the internet, and the same unlock that works on the real site quietly fails on the fake one.

The order to do this in

  1. Email first. It is the password-reset path for everything else, so protecting it protects all the rest.
  2. Then banking, the donor database, the payment processor, and the social accounts.
  3. Choose app codes over texted codes wherever both are offered.
  4. Add passkeys where the service supports them — start with the executive director, whoever handles finance, and whoever administers your email.
  5. Hardware keys for administrator accounts, if you have them.

Don’t lock yourself out

Before you switch any of this on, deal with recovery. Print the recovery codes and lock them somewhere physical. Make sure more than one person is an administrator on your email system. The most common MFA disaster at a small organization is not a breach — it is the only administrator leaving with the only phone.

This week

Turn on MFA for your email if it isn’t already. Then check whether your most important accounts support passkeys, and start with the handful of people whose accounts would hurt the most.

That closes Section 1 — the front door. Next: recognizing the trap and the social engineering aimed squarely at organizations built on trust.