Multi-factor authentication: the control that matters most, done properly

Why MFA works, and what it does not solve

Passwords fail for structural reasons: people reuse them, breaches leak them, and attackers automate the guessing. MFA breaks that model by requiring a second factor the attacker does not have. Against the dominant threat — automated attacks using credentials from unrelated breaches — it is close to decisive.

What MFA does not do is protect a session that has already been established. If an attacker steals a valid session token, they are inside without ever presenting a factor. This is why incident response after a compromise must include revoking sessions, not just resetting the password and re-registering MFA. It is also why Conditional Access and sign-in risk policies add value on top of MFA rather than duplicating it.

The methods, ranked honestly

SMS codes are the weakest common method. A SIM swap — persuading a mobile network to move a number to an attacker-controlled SIM — defeats them entirely, and this is a documented, practised attack against people who hold valuable accounts. Nevertheless, SMS MFA is dramatically better than no MFA, and if the choice is SMS or an exemption, choose SMS.

Authenticator app codes (TOTP) are better: the secret lives on the device and is not transmitted. Push notifications are more convenient again, but introduced their own weakness — MFA fatigue, where an attacker who already has the password triggers approval prompts repeatedly at antisocial hours until someone taps Approve to stop the noise. Number matching, now the default for Microsoft Authenticator, largely closes this: the user must type a number displayed on the sign-in screen, which they cannot do unless they are the one signing in.

Phishing-resistant methods are a different category. Passkeys and FIDO2 hardware keys use public-key cryptography bound to the legitimate domain, so a proxy phishing site cannot relay the authentication — the credential simply refuses to work on the wrong origin. For administrators, finance staff and anyone who can move money, this is where you should be.

• SMS — weakest, but still far better than nothing
• TOTP authenticator codes — solid, no network dependency
• Push with number matching — convenient, resistant to MFA fatigue
• Passkeys / FIDO2 keys — phishing-resistant, correct choice for privileged accounts
• Certificate-based authentication — strongest, generally overkill below enterprise scale

Adversary-in-the-middle, and why MFA alone is no longer sufficient for privileged accounts

The attack that has changed the calculus is the adversary-in-the-middle phishing kit. The victim clicks a link and reaches a proxy that renders the genuine Microsoft sign-in page. They enter their password, they approve the MFA prompt legitimately, and the proxy captures the resulting session cookie. The attacker replays that cookie and is inside, having never needed the password or the second factor again.

Nothing about SMS or app-based MFA prevents this, because the user genuinely authenticated — just on the wrong site. Only domain-bound credentials stop it, which is the practical argument for passkeys on any account that matters. Conditional Access with device compliance requirements also raises the bar considerably, because the stolen cookie is presented from an unmanaged device.

Rolling it out without a week of chaos

MFA rollouts fail on logistics, not on technology. The predictable problems are shared accounts nobody owns, service accounts embedded in scripts, staff without smartphones, and the people who are on leave during the enrolment window.

Run it in a deliberate order. Enrol IT and administrators first so they experience it before supporting it. Communicate a week ahead with a one-page explanation of what will happen and why, in language that does not assume technical knowledge. Give a two-week enrolment window and then enforce. Require every user to register two methods, which prevents the single most common lockout — a replaced phone with no backup method.

Have a documented, verified process for resetting MFA when someone is locked out, including identity verification that does not depend on the account they cannot access. An MFA reset request is a favourite attacker pretext, and a weak reset process undoes the entire control.

Offer people an alternative to their personal phone

A recurring and legitimate objection is staff not wanting a work authenticator on a personal device. This is worth taking seriously rather than overriding, because a forced rollout produces workarounds.

The usable alternatives are a hardware security key (a few pounds per user, no phone involved, and phishing-resistant into the bargain), Windows Hello for Business on a managed laptop, or a low-cost dedicated device for the handful of people who need it. Offering a hardware key to objectors frequently resolves the issue immediately and improves your security posture at the same time.