AD1.2 MFA: What It Actually Protects Against

The attacks MFA stops cold

Password spraying, credential stuffing, basic phishing, brute force, and keylogger-captured passwords all share one characteristic: the attacker ends up with a valid password but nothing else. MFA requires a second factor — something the user has (their phone, a security key) — that the attacker doesn’t possess. The authentication fails because the attacker can enter the password but can’t complete the MFA challenge.

This covers the overwhelming majority of credential attacks in the wild. Microsoft’s data shows that 99.2% of compromised accounts did not have MFA enabled. When you look at the attacks that succeed against M365 tenants, the pattern is consistent: the attacker had a password (from spraying, stuffing, or phishing) and the account had no MFA requirement. MFA would have stopped every one of these.

The practical implication is stark. If your tenant has accounts without MFA enforcement, those accounts are 99.9% more likely to be compromised than accounts with MFA. Not “slightly more at risk.” Not “somewhat more vulnerable.” Nearly a thousand times more likely. This is why MFA for all users is not a recommendation — it’s a requirement.

The attacks that bypass MFA — and what to do about each

Understanding what MFA doesn’t stop is equally important, because it tells you which additional controls to deploy and prevents the false confidence that comes from treating MFA as complete protection.

Adversary-in-the-middle (AiTM) proxy phishing is the most common MFA bypass in 2025-2026. The attacker sets up a reverse proxy between the user and Microsoft’s real login page. The user authenticates normally — entering their password and completing MFA — but the proxy captures the session token that Microsoft issues after successful authentication. The attacker then replays that token from their own device, bypassing MFA entirely because the token already has MFA satisfaction baked in.

The defense against AiTM is conditional access with device compliance. A conditional access policy that requires a managed/compliant device checks the device identity, not just the user identity. The attacker’s device isn’t enrolled in your Intune tenant, so the conditional access policy blocks the session even though the credentials and MFA were valid. You’ll build this policy in AD1.4.

For organisations with E5 licensing or an Entra ID P2 add-on, phishing-resistant MFA methods (FIDO2 security keys, Windows Hello for Business, certificate-based authentication) provide additional protection. These methods are cryptographically bound to the legitimate login page — a FIDO2 key won’t respond to a proxy page because the domain doesn’t match. For E3 environments, the device compliance conditional access policy is the practical defense.

Token theft occurs when an attacker steals a session token or Primary Refresh Token (PRT) from an already-authenticated device — through malware, browser exploitation, or physical access. The stolen token lets the attacker authenticate as the user without needing the password or MFA. The defense is conditional access with continuous access evaluation (CAE), which re-validates tokens against policy changes in near-real-time, and sign-in risk policies that detect token replay from new locations.

SIM swapping targets phone-based MFA methods (SMS codes, voice calls). The attacker convinces the mobile carrier to transfer the victim’s phone number to a new SIM card, then receives the MFA codes. The defense is using app-based MFA (Microsoft Authenticator) or hardware tokens (FIDO2) instead of SMS/voice. Microsoft Authenticator push notifications with number matching are not vulnerable to SIM swapping because the notification goes to the Authenticator app on the registered device, not to the phone number.

MFA fatigue exploits push-based MFA by triggering repeated push notifications until the user approves one. The defense is number matching — enabled by default since May 2023 — which requires the user to type a number displayed on the sign-in screen into the Authenticator app. Blindly tapping “Approve” doesn’t work because the user must enter the correct number.

Choosing the right MFA method

Not all MFA methods provide equal protection. Here’s the hierarchy from strongest to most vulnerable, along with the practical considerations for each.

FIDO2 security keys (strongest) are phishing-resistant — they cryptographically verify the domain and won’t respond to proxy pages. They require no phone, no battery, no network connection. The downside is cost ($20-50 per key) and physical distribution. Best for: administrator accounts, high-value targets, shared workstations without phone access.

Windows Hello for Business (strong) uses biometrics (fingerprint, face) or PIN tied to the TPM chip. It’s phishing-resistant and seamless for the user. The downside is it only works on Windows devices with compatible hardware. Best for: organisations with standardised Windows hardware.

Microsoft Authenticator with number matching (good) uses push notifications where the user must type a number displayed on the sign-in screen. Not phishing-resistant (an AiTM proxy passes the number through), but resistant to MFA fatigue and SIM swapping. This is the practical default for most organisations — free, easy to deploy, and effective against 99%+ of attacks. Best for: all users as the baseline method.

Authenticator app TOTP (good) generates a 6-digit time-based code. Requires the user to open the app and type the code. Slightly more friction than push, but works offline and doesn’t require push notification infrastructure. Best for: users with limited connectivity.

SMS/Voice (weakest MFA method) sends a code via text message or phone call. Vulnerable to SIM swapping and SS7 interception. Still vastly better than no MFA, but should be used as a fallback, not the primary method. Best for: users who absolutely cannot use any other method.

For NE’s deployment, the recommendation is: Microsoft Authenticator with number matching as the default for all users, FIDO2 security keys for the Global Administrator accounts and break-glass accounts, and SMS as a fallback method only for users who can’t install the Authenticator app.

What AiTM looks like in your sign-in logs

When you investigate a potential AiTM attack, here are the specific fields to check in the Entra sign-in log.

Look for a successful sign-in where the “MFA requirement” shows “Satisfied by claim” rather than “Satisfied by MFA on this sign-in.” “Satisfied by claim” means the session token already had MFA baked in — which is normal for returning sessions but suspicious for a first sign-in from a new IP address. An initial sign-in from an unknown IP with “MFA satisfied by claim” is the signature of a replayed AiTM token.

Check the “Device info” tab. If the sign-in shows a device that isn’t enrolled in Intune and the user has a corporate device, the sign-in likely came from the attacker’s machine. Legitimate users signing in from their corporate laptop show a device ID that matches Intune enrollment. Attackers replaying tokens show a device ID that doesn’t exist in your tenant.

Check the “Location” and “IP address” fields. AiTM attacks often originate from VPN exit nodes or cloud hosting providers. IP addresses from AWS, Azure, DigitalOcean, or known VPN services on a first sign-in for a user who normally signs in from your office network warrant investigation.

These are the checks you’ll perform in the 15-minute emergency response procedure (AD1.9). Understanding them now means you’ll recognise the pattern when you see it in production.