MFA

Multi-factor authentication (MFA) requires users to prove their identity with at least two factors: something they know (password), something they have (a phone, token, or FIDO2 key), or something they are (biometric). In Microsoft 365, MFA is enforced through Microsoft Entra ID, with the Microsoft Authenticator app as the recommended verifier. Supported methods include push notifications, one-time passcodes, FIDO2 security keys, Windows Hello for Business, and (now discouraged) SMS or voice calls. MFA blocks the vast majority of credential-based attacks and is the single most important security control to enable for every user, including admins.

Not all methods are equal

MFA methods sit on a spectrum of phishing resistance. SMS and voice call MFA is the weakest surviving option — vulnerable to SIM-swap attacks and, more commonly today, to real-time phishing (an attacker's fake login page relays the one-time code to the real Microsoft login page within seconds of the victim typing it in). Push notification with number matching (Microsoft Authenticator's default mode since 2023) is meaningfully stronger — the user must read a number shown on the real sign-in screen and type it into the app, which defeats simple "tap approve" push-bombing but is still vulnerable to a sophisticated real-time phishing proxy that relays the number correctly. FIDO2 security keys, passkeys, and Windows Hello for Business are phishing-resistant: the cryptographic challenge-response is bound to the legitimate site's origin, so a look-alike phishing domain simply cannot complete the handshake, regardless of how convincing the fake page looks.

Worked example

A finance team is repeatedly targeted by adversary-in-the-middle phishing kits that proxy the real Microsoft sign-in page and capture whatever the user enters, including push-approval taps and typed one-time codes. Moving the team from "any MFA method" to a Conditional Access policy that specifically requires phishing-resistant authentication strength (FIDO2 keys or Windows Hello for Business only, not push or SMS) closes that specific attack path — the phishing proxy can present a fake page, but it cannot forward a FIDO2 challenge-response because the cryptographic signature is bound to the real Entra ID origin the key was registered against, not to whatever domain is currently in the address bar.

Registration and enforcement

Users register MFA methods through combined registration (a single flow that sets up both MFA and self-service password reset methods together, avoiding a duplicate second registration experience). Enforcement is layered: security defaults gives every new tenant baseline MFA enforcement for free; Conditional Access (Entra ID P1+) lets a tenant require specific methods, exempt specific scenarios, and step up requirements based on risk; authentication strengths (a Conditional Access control) let a policy demand a specific tier of method rather than just "any MFA."

Common pitfalls

The most common gap is leaving break-glass emergency-access accounts and service accounts that can't do interactive MFA unaccounted for when tightening a Conditional Access MFA policy — a policy requiring MFA for every user, with no exclusions, can lock an organisation out of its own emergency-access account at exactly the moment it's needed. The second common gap is treating "MFA enabled" as a finish line rather than a starting point — an estate still allowing SMS or unrestricted push approval remains exposed to the same phishing techniques that motivated enabling MFA in the first place.