The Factor Is Rarely the Thing That Fails
Multi-factor authentication stops the attacks it was designed for: password spray, credential stuffing, the reused password from a breach dump. What it does not stop, and was never designed to stop, is an attacker who steals the proof that MFA already happened. Most successful account takeovers against MFA-enabled tenants never crack a factor. They capture the session token issued after the user authenticated legitimately, or they route through a flow where MFA is never invoked at all, or they attack the human recovery path that sits behind the factor.
That reframes the whole problem. If the attacker's target is the authenticated session rather than the login ceremony, a stronger one-time code changes nothing. The fixes that hold are the ones that change the property being attacked: credentials that cannot be relayed through the wrong origin, and conditional access policies that bind sessions to managed devices and shut the side doors where MFA never fires.
The Session Token Is the Real Prize
Adversary-in-the-middle phishing kits are the dominant bypass because they do not fight MFA; they let it succeed. The kit sits as a reverse proxy between the victim and the real identity provider. The victim clicks a link, lands on a domain the attacker controls, and sees the genuine sign-in page proxied byte for byte. They enter their real password, approve their real MFA prompt, and the identity provider issues a real session cookie. The proxy keeps a copy. From that moment the attacker holds an authenticated session, and every log line says MFA succeeded.
Evilginx made the technique public years ago, and the phishing-as-a-service market industrialised it. Commodity kits handle certificate provisioning, domain rotation and cookie capture out of the box, which is why the operators running them do not need to be sophisticated. The same outcome arrives by a second road: infostealer malware on an unmanaged laptop exports browser cookies wholesale, and a session cookie lifted from a compromised device replays cleanly from attacker infrastructure unless something binds it to the machine it was minted on.
The detection problem follows directly. If your alerting keys on failed MFA challenges, an AiTM compromise is invisible, because the challenge passed. What gives it away is what happens next: a sign-in from fresh infrastructure reusing an existing session, a new inbox rule that hides replies, a consent grant to an unfamiliar application. Session anomalies, not authentication failures, are the tell.
Weak Factors Fail in Predictable Ways
Push notifications fail through the user's thumb. Prompt bombing works by exhaustion: fire approvals at a phone until one lands at two in the morning, or pair a single prompt with a call from 'IT support' asking the user to approve it. Number matching, which Microsoft now enforces by default in Authenticator, kills blind approval because the user must type a code shown on the sign-in screen. It does nothing against a proxied flow, because in an AiTM attack the user genuinely is signing in; the numbers match because the session is real.
SMS codes fail in two directions. SIM swap attacks port the victim's number onto attacker hardware; in Australia the ACMA's pre-porting identity verification standard has made straight ports harder since 2020, but that control lives with the telco, not with you. The second direction needs no port at all: any code a user can read, a user can type into a proxy page, and a six-digit code relays through an AiTM kit in seconds, well inside its validity window.
The third predictable failure is the recovery path. A factor is only as strong as its reset process. An attacker who calls the service desk, passes a soft identity check and talks their way into an MFA reset gets to enrol their own device on the account; from then on they are the second factor. Registration and recovery flows are part of the factor and deserve the same rigour: call-back verification to a number on file, no resets from a single inbound call, and alerts on new method registration for privileged accounts.
Phishing Resistance Is a Property, Not a Product
A factor is phishing-resistant when the credential cannot be presented to the wrong origin, no matter what the user believes at the time. That is a protocol property, not a marketing label. WebAuthn and FIDO2 achieve it with origin binding: the private key never leaves the authenticator, and the signed assertion is scoped to the web origin the browser actually connected to. A proxy running on a lookalike domain receives an assertion for the wrong relying party, and the real service rejects it. There is no code to read out over a phone, nothing to type into the wrong page, and no approval to socially engineer.
In practice that means hardware security keys, passkeys, Windows Hello for Business, or certificate-based authentication in Entra ID. The passkey nuance worth understanding is synced versus device-bound. Synced passkeys inherit the recovery model of the platform account they sync through, which is fine for most staff and wrong for the people who can move money or grant admin consent. For privileged roles, device-bound credentials on hardware keys keep the trust anchor physical. The ACSC's Essential Eight maturity model pushes the same direction: as maturity levels rise, the multi-factor authentication strategy expects phishing-resistant implementations, not just any second factor.
Conditional Access Closes the Doors the Factor Cannot
The factor only matters in flows where it fires. Legacy authentication protocols, IMAP, POP and basic SMTP auth among them, complete with a username and password and never invoke MFA. Microsoft has switched off basic authentication for most Exchange Online protocols, but tenants keep exceptions alive for old scanners and line-of-business apps, and every exception is a door where MFA does not exist. Block legacy authentication with a conditional access policy and give any surviving exception an owner and an expiry date.
Device signals are what beat token theft. A policy requiring a compliant, managed device for access to mail and files means a session cookie exfiltrated to attacker infrastructure fails at the next policy evaluation, because the device claim does not travel with the cookie. Entra's authentication strength policies let you demand phishing-resistant credentials specifically for privileged roles and sensitive apps rather than boiling the ocean on day one. Continuous access evaluation shortens the life of a stolen token by revoking sessions in near real time when a user is disabled or a password changes. Token protection, which binds tokens cryptographically to the device, is still expanding across workloads; treat it as a reinforcing layer rather than the fix.
Sign-in risk policies and session monitoring carry the rest: alert on anomalous token reuse, impossible travel, new inbox rules and fresh application consents. This is the exact control set we validate in Azure security reviews, because the gap between 'MFA enabled' and 'MFA effective' almost always lives in conditional access, not in the authenticator app.
Where to Start on Monday
None of this requires new products for a Microsoft-stack organisation; it requires sequencing. The order below weighs effort against how attackers actually operate.
- Block legacy authentication tenant-wide, then inventory exceptions and give each an owner and an expiry.
- Enforce number matching and additional context on every push approval.
- Move privileged roles, finance staff and executives to FIDO2 keys or device-bound passkeys this quarter.
- Require compliant devices for mail, files and admin portals.
- Harden the service desk reset path: call-back verification, no MFA resets from a single inbound call, alerts on new method registration.
- Rehearse token-theft response: revoke refresh tokens and sessions explicitly, because a password reset alone does not end a stolen session.
MFA Is Necessary, Just Not the Whole Job
MFA still belongs in every tenant; it remains the control that ends password spray outright. The point is to be clear about which control does which job. The factor establishes who started a session. Phishing-resistant credentials stop that ceremony being relayed through an attacker's proxy. Conditional access decides what a session is worth after it exists, and on what hardware. Attackers moved to the seams between those layers years ago. A defence that stops them has to live in the seams too.