Phishing-resistant MFA: The Gap Behind 'MFA Is On'

You enabled MFA. An employee approved a sign-in. Someone else still got into the account. How?

That is a frightening helpdesk ticket, but it does not mean multifactor authentication is pointless. It means the type of MFA, the sign-in journey, and the session that follows all matter.

For an everyday IT engineer, the useful question is simple: are we checking the person only, or also the website they are signing into?

The fake reception desk problem

Imagine a visitor arriving at a fake reception desk. The receptionist quietly passes the visitor's details to the real office, relays its questions, and receives the entry pass. The visitor sees familiar questions and assumes everything is normal.

A fake sign-in intermediary can create a similar problem. Some attacks relay a real sign-in and obtain the resulting session cookie: the browser's temporary proof that authentication already happened. Microsoft has documented this adversary-in-the-middle phishing pattern.

Picture the risky path: Employee → fake sign-in intermediary → real service. The employee completes a phishable challenge; the intermediary may capture the session. This is a conceptual diagram, not a claim that every suspicious page behaves this way.

Keep MFA. Upgrade the question

MFA still adds valuable protection. CISA recommends using it and explains why organizations should move toward phishing-resistant authentication.

An SMS code, a copied one-time code, an approval notification, and a FIDO2 passkey are not interchangeable. Number matching can improve push approval, but it does not make that method phishing-resistant.

Do not respond to this risk by turning MFA off. Ask which methods people can actually use, including recovery and fallback routes. A strong default with an easy weaker alternative deserves a closer look.

Why a passkey changes the picture

A passkey uses cryptographic credentials rather than asking you to type a reusable secret into a page. Supported passkeys can live on devices or FIDO2 security keys; the appropriate choice depends on your organization's requirements.

The important idea is origin binding. A credential created for the real service is not simply handed to a lookalike website. The browser and authentication system check the website context. Microsoft's passkey explanation describes this origin-bound design and the role of a device PIN or biometric unlock.

Think of it as an entry badge that checks the building, too. That addresses a particular phishing weakness; it is not a promise that an account can never be compromised. A compromised device, unsafe recovery process, or stolen session needs separate attention.

Your next team meeting: five useful questions

• Which administrators still rely on SMS, codes, or ordinary push approvals?
• Can those accounts use an approved passkey or FIDO2 security key?
• Do policies require the stronger method, or merely allow it?
• How do we verify someone before replacing a lost device or registering a new method?
• Who owns sign-in alerts and the response to suspected session theft?

Start with a small, authorized pilot. Include someone who travels, someone using a shared workstation, and a helpdesk colleague. Test normal sign-in, a lost device, and recovery before broad rollout.

The sentence worth sharing

“MFA enabled” is a starting point. “Which method, which fallback, and which recovery process?” is the better review.

If someone already approved a suspicious sign-in, report it through your incident process promptly. Give the responder the time and the service involved. Do not assume changing a password alone resolves an active session incident.

You do not need to become a cryptographer to improve this. Make the sign-in method visible, make recovery deliberate, and give your team a clear next step.