MFA is not a checkbox: what phishing-resistant authentication actually requires

Multi-factor authentication earns its reputation. The evidence that it prevents the overwhelming majority of credential-based attacks is about as strong as evidence gets in this field, and if an organization has one control and no more, this should be it.

That is precisely why it deserves more scrutiny than it usually gets. A control that carries this much weight should not be deployed in whatever form the vendor defaulted to, and "we have MFA" should not end the conversation. Some implementations stop essentially every attack an organization of your size will face. Others stop opportunistic credential stuffing and nothing more determined than that.

Both get described the same way in a security questionnaire.

The factors are not equivalent

Ranked from weakest to strongest, in terms of what defeats them.

SMS codes. Defeated by SIM swapping, by SS7 interception, and — most commonly — by simple relay phishing, where the victim types the code into a convincing fake site and the attacker forwards it to the real one within the validity window. NIST has discouraged SMS as an out-of-band authenticator for years. It is still meaningfully better than a password alone.

Time-based one-time codes from an authenticator app. Immune to SIM swapping, still fully defeated by real-time relay phishing. The user cannot tell that the site asking for their code is a proxy.

Push notifications with number matching. The number-matching addition — where the user must type a number shown on the login screen — closes the MFA fatigue attack, in which an attacker simply sends approval prompts until someone taps accept to make it stop. Number matching is a genuine improvement and should be considered the minimum acceptable form of push. It still does not stop a relay proxy.

Hardware security keys and passkeys using FIDO2 or WebAuthn. These are categorically different, and the difference is not incremental. The authenticator cryptographically binds the response to the origin of the site requesting it. A phishing proxy at a lookalike domain presents a different origin, so the key produces a response that is useless. The user cannot be tricked into overriding this, because the check is not presented to the user at all.

The gaps that make MFA decorative

Deploying strong factors is necessary and not sufficient. The failures we find in assessments are almost never about the factor; they are about the paths that go around it.

Legacy authentication protocols. Anything that cannot present an MFA challenge — older mail protocols, basic authentication endpoints, legacy client access — is a bypass by design. If these remain enabled, an attacker with a valid password does not need to defeat your MFA, only to avoid it. Disabling legacy authentication is frequently the single highest-value change available in a Microsoft 365 tenant.

Service accounts and API keys. Non-interactive identities cannot do MFA, which is often used as a reason to exempt them and then forget them. They frequently hold broader rights than any human account. They need compensating controls: strict scoping, credential rotation, conditional access by source, and monitoring for use outside expected patterns.

The help desk. If your password reset process is "call, state your name and date of birth, receive a new password", then your MFA can be reset by anyone who has read the target's public professional profile. Social engineering of help desks is one of the most reliably effective techniques in use, and it has featured in several of the highest-profile intrusions of recent years. Identity verification for privileged resets should be materially stronger than for routine ones.

Enrolment. The moment a user first registers a factor is the moment an attacker wants to intercept. If enrolment can be completed from anywhere with only a password, an attacker who has the password enrols their own device and now has legitimate MFA on the account. Enrolment should require an existing trusted context or an in-person or verified out-of-band step.

Session tokens. Once authentication completes, the session token is the credential. Token theft via infostealer malware bypasses MFA entirely, because the authentication already happened. Shorter session lifetimes for sensitive applications, token binding where available, and monitoring for impossible-travel or anomalous device signals all address this.

A deployment order that works

Perfect is genuinely the enemy of good here, and an organization that waits until it can do FIDO2 everywhere often does nothing for eighteen months. This is the sequence we recommend.

First, cover everyone with something. Any MFA on every account beats excellent MFA on the security team. Push with number matching is a reasonable default for a general population.

Second, close the bypasses. Disable legacy authentication. Inventory service accounts and scope them down. Fix the help desk reset process. This step is unglamorous, involves no new licensing, and typically removes more risk than the initial rollout did.

Third, put hardware keys on the accounts that matter. Domain and tenant administrators, finance staff who can move money, anyone who can alter authentication policy itself. This is a small population and the cost is trivial relative to what those accounts control.

Fourth, extend passkeys to the general population as devices and applications support them. Modern platform authenticators mean this is increasingly possible without buying hardware for everyone.

What to tell your board

If you need one sentence: MFA is the highest-return security control available, most organizations have deployed a version of it that a determined attacker can bypass, and the fix is mostly configuration rather than expenditure.

The follow-up question a good board will ask is how you would know. The answer is that MFA enrolment changes, authentication policy changes, and legacy authentication attempts should all generate alerts that a human sees. If none of those are monitored today, the control is deployed but not defended — and the first indication that someone walked around it will be the consequence, not the alert.