MFA is not the finish line

Start with what is actually true

MFA works. Turning it on eliminates the entire category of attack that depends purely on a stolen or reused password, and that category is enormous. If you have users without MFA today, stop reading and go and fix that — it is the highest-return hour you will spend this quarter.

The problem is what happens next. MFA gets deployed, a box gets ticked on an insurance questionnaire, and the control is treated as finished. Meanwhile the attacks moved on. The question in 2026 is not whether you have MFA. It is which method, applied to which accounts, enforced by which policy.

Three bypasses that work today

1. Adversary-in-the-middle phishing

The most consequential of the three, and the one most organisations have not accounted for. The user receives a convincing link and lands on a proxy that sits between them and the real Microsoft sign-in page. Everything they see is genuine, because it is genuine — relayed in real time.

The user enters their password. The proxy passes it on. Microsoft issues an MFA challenge. The user approves it, correctly, on their own device. Authentication succeeds — and the proxy captures the resulting session cookie.

With that cookie the attacker is signed in as the user, with MFA already satisfied. Changing the password does not evict them. The session must be explicitly revoked. Kits that do this are sold as a service and require no particular skill to operate.

2. Push fatigue

The attacker has a valid password from a breach dump or an earlier phish, and triggers authentication attempts repeatedly. The user's phone buzzes at 11pm, then again, then again. Eventually somebody approves one to make it stop — or approves it half-asleep, assuming it is a stuck session on their own device.

This is entirely solved by number matching, which requires the user to type a number displayed on the sign-in screen. If your Microsoft Authenticator deployment predates number matching being enforced by default, confirm it is actually on.

3. SMS interception and SIM swap

SMS as a second factor is vulnerable to SIM swapping — an attacker persuading a carrier to port a number to a device they control — and to interception. It remains far better than nothing, and it is the weakest method still in common use. Australian carriers have tightened porting controls, which has reduced the frequency without eliminating it.

What to change, in order

1. Turn off SMS and voice for anyone who can be moved. Move users to an authenticator application with number matching at minimum. Keep SMS only as a registration fallback, not a sign-in method.
2. Deploy phishing-resistant MFA for privileged accounts. FIDO2 security keys, Windows Hello for Business or certificate-based authentication. These are the only methods that defeat adversary-in-the-middle, because the credential is cryptographically bound to the legitimate domain and simply will not respond to a proxy. Start with global administrators and anyone who can authorise a payment.
3. Add device compliance to conditional access. A stolen session cookie replayed from an unmanaged machine in another country fails a policy that requires a compliant, enrolled device. This is the single most effective mitigation available to most organisations, and it uses licensing you probably already own.
4. Shorten session lifetimes for high-risk access and enforce sign-in frequency for administrative roles, so a captured token has a shorter useful life.
5. Alert on token anomalies. Impossible travel, unfamiliar sign-in properties, new device registration and anomalous token issuance are all detectable — provided somebody is watching the queue.
6. Practise session revocation. When an account is compromised, revoking sessions is a separate step from resetting the password. Make sure your team knows the step exists and has done it once before they need to do it in an incident.

The gaps nobody counts

When we assess MFA coverage, the number reported by the organisation and the number we measure almost always differ. The difference is nearly always in the same five places.

• Service accounts. Excluded from MFA because a script broke once. Often highly privileged, often with a password that has not changed in years.
• Shared mailboxes with sign-in enabled. Frequently accounts@ or info@, frequently the account with the most valuable inbound mail.
• Legacy authentication protocols still permitted for one application that was decommissioned some time ago. Legacy protocols do not support MFA at all, so any account reachable through them is effectively unprotected.
• Break-glass accounts. These legitimately need an exclusion — but they need long random credentials, strict monitoring on every use, and an annual test that they still work.
• Guest and external identities. Contractors, auditors and partner organisations, often granted access once and reviewed never.

None of these are exotic. They are the ordinary residue of an environment that has been running for years and changed hands between administrators. Finding them is a configuration review, not a penetration test.

A useful test: ask whoever manages your identity platform how many accounts are currently excluded from your MFA conditional access policy, and why each one is on the list. If the answer is not immediate, that list is the next thing to look at.