MFA 'enabled' isn't the same as MFA that actually stops anything

Background

"Do you have MFA enabled?" is one of the first questions on every security questionnaire, every cyber insurance form, every DSPT self-assessment - and "yes" is the answer almost everyone gives, because almost everyone does have something turned on. What the question doesn't ask, and what actually matters, is which MFA. SMS codes, push notifications, and a hardware passkey all satisfy "MFA enabled." They do not satisfy "stops the attack that's actually happening in 2026," which is overwhelmingly phishing a code or a push approval out of someone, not guessing a password.

Setup

The methods, ranked against a real phishing attempt

• SMS codes - phishable with a fake login page that just asks for the code, and vulnerable to SIM-swap on top. Better than nothing. Should not be the only option for anyone with elevated access.
• Push notifications ("approve this sign-in") - defeated by MFA fatigue: an attacker with a stolen password sends five approval requests at midnight, and eventually someone taps approve to make the noise stop. Number-matching (typing a code shown on the login screen into the app) closes most of this gap and should be the minimum for anyone still on push.
• Authenticator app codes (TOTP) - not phishable via SIM-swap, still phishable via a real-time fake login page that relays the code through before it expires. Solid for most users.
• Phishing-resistant options - WebAuthn/passkeys, FIDO2 security keys - cryptographically tied to the actual domain being logged into, so a convincing fake site simply can't complete the handshake. This is the bar for admin and platform-operator accounts, not an optional upgrade - NCSC's current guidance treats it as the standard for anyone with privileged access, not a nice-to-have for the security-conscious.

What Conditional Access should actually enforce

Practically, in a Microsoft 365 tenant, Conditional Access policies can require a specific authentication strength, not just "MFA satisfied":

• A separate, stricter policy for admin and platform-operator roles, requiring a phishing-resistant method specifically - not the same policy that lets a standard user in on an SMS code.
• Check whether the policy actually distinguishes SMS from a passkey, or whether it treats every method as equally acceptable because that was easier to configure at the time. Authentication strength policies exist precisely so "MFA satisfied" can mean different things for different roles.
• A named review date, not a set-and-forget policy. Conditional Access configurations drift as roles change and new starters get added to groups they shouldn't inherit access from - review who's actually covered by the strict policy against who actually holds privileged access, on a schedule.

The helpdesk reset problem

The helpdesk is the weakest link in most MFA setups, not the cryptography. "I've lost my phone, can you reset my MFA" is exactly what an attacker who's done their homework says next. A workable process, concretely:

1. A second verification channel that isn't the phone call itself - a callback to a number already on file, not one the caller provides on the spot, or verification through a manager who already knows the person.
2. A documented script the helpdesk actually follows, not discretionary judgement under pressure from someone claiming urgency. Social engineering specifically targets the moment a helpful person decides to make an exception.
3. Every reset logged and reviewed, not just actioned and forgotten - a spike in reset requests, or a reset immediately followed by unusual sign-in activity, is exactly the pattern a real attack looks like after the fact.

A phishing-resistant key means nothing if someone can talk it away over the phone - the identity-check process matters more than which method was picked.

Break-glass accounts done properly

Every tenant needs at least one account that can get in if Conditional Access misconfigures itself and locks everyone out. Doing this properly means:

• A genuinely strong, long, randomly generated credential, stored in a physical safe or a dedicated secrets vault - not memorised, not written on a sticky note, not the same password pattern used anywhere else.
• Excluded from the Conditional Access policies it exists to recover from, by design, but monitored more closely for that exact reason - any sign-in on a break-glass account should trigger an immediate alert, not blend in with normal activity.
• Tested periodically, not just created once and left alone. An account nobody's actually signed into in two years might have a stale credential, an expired exclusion, or simply have been forgotten about entirely by whoever set it up.