MFA is on, but the old protocols that ignore it never got turned off

You turned on multi-factor authentication (MFA) across the company months ago. Everyone grumbled, everyone set up the authenticator app, and now every sign-in asks for the second factor. As far as the dashboard is concerned, you’re covered — the little green tick says MFA is enforced.

Then a login you didn’t make succeeds, from an address you don’t recognise, with the correct password and no second-factor prompt anywhere in sight. Nothing was bypassed by cleverness. The attacker simply knocked on a different door — an old sign-in protocol that predates MFA and has no way to ask for it. Your MFA was real. It just wasn’t standing in front of every entrance.

Why it stays invisible

MFA is enforced at the point where the modern sign-in flow can insert the prompt. Older protocols — the ones mail clients used before modern authentication, things like POP, IMAP and SMTP AUTH — were designed in an era of username-and-password and nothing else. They have no field for a second factor, so when a request comes in over one of those channels, the system can’t challenge it. It checks the password, the password is right, and it lets the request through. The MFA policy isn’t ignored so much as never consulted.

This stays invisible because everything you look at works correctly. Your own staff sign in through the modern flow and get prompted every time, so the protection looks total. The legacy path only lights up when someone goes looking for it — and attackers do, constantly, because it’s the reliable way around MFA. A password-spray (trying one common password against thousands of accounts) aimed at a legacy endpoint doesn’t trip the defences you built, because those defences live on a road the attacker never drives down. The failure is a gap you can’t see from where you’re standing.

Find it yourself

You can check whether legacy authentication is both possible and actually being used in about ten minutes. This is Microsoft 365 / Entra ID territory, since that’s where most small businesses meet this.

1. Sign in to the Entra admin centre (formerly Azure AD) as an administrator.
2. Go to Entra ID → Monitoring & health → Sign-in logs (Microsoft moves this view about, so if the label has changed, the search box at the top of the admin centre will find “Sign-in logs”).
3. Add a filter on Client app, and tick the legacy authentication clients (the grouping that includes “Other clients,” IMAP, POP, SMTP, and older Exchange protocols).
4. Set the date range as far back as your tenant keeps its logs — even a free Entra licence keeps seven days of sign-in history, and paid ones thirty — and look at what comes back, checking the non-interactive sign-ins tab as well, since app and mail-client logins often land there. Successful legacy sign-ins are the ones that matter — each is a login that never faced your MFA. Note the accounts involved.

A caveat worth stating plainly: Microsoft permanently switched off basic authentication for most Exchange Online protocols — POP, IMAP, Exchange ActiveSync and the rest — back in 2022–23, and those doors can’t be reopened. The one exception is SMTP AUTH, which can still be enabled, and often is — kept alive for a printer, a scanner, or an app that sends mail. Microsoft plans to turn it off by default at the end of 2026, with full retirement to follow, but as things stand it’s a door that can be open. Treat “we’re on modern Microsoft 365, so this can’t apply to us” as a thing to confirm in the logs, not to assume.

No admin access? Ask whoever administers your email to run the check above, or to confirm two things in writing: that a Conditional Access policy blocking legacy authentication is in place, and that no per-mailbox exceptions have been left on. If they can’t confirm both, assume the gap is open.

The fix

The fix is to shut the road rather than keep guarding the modern one twice as hard.

Block legacy authentication outright. In Entra, a Conditional Access policy that blocks legacy authentication closes these protocols for everyone in one move: create a new policy covering all users, set Conditions → Client apps to Exchange ActiveSync clients and Other clients, and set the grant to Block access — Microsoft ships this as a ready-made policy template, and you can run it in report-only mode first to see what it would catch. Conditional Access needs an Entra ID P1 licence; if you’re on Security Defaults instead — the free tier’s protection — blocking legacy auth is part of what that setting already does, so confirm it’s actually on.

Deal with the one thing still using it. If your log check turned up a legitimate device or app on SMTP AUTH — a multifunction printer, say — move it to a supported method before you flip the switch, so blocking legacy auth doesn’t stop the invoices going out. This is the step that makes the change safe to do, rather than a change you keep postponing because you’re afraid of what it’ll break.

Reset the accounts that were exposed. Any account you saw succeeding over legacy auth should have its password changed, since a password that’s been usable without MFA is exactly the kind that turns up in a spray list.

Confirm it stayed shut. Re-run the sign-in log filter a week later. Successful legacy sign-ins should have dropped to nothing. A quick look each quarter keeps a new exception from quietly reopening the door.

Once legacy auth is blocked, the MFA you already rolled out finally covers every entrance instead of most of them — which is what you thought you’d bought the first time.

Knowing whether MFA truly covers every sign-in path — not just the ones your staff use — is the sort of thing that’s easy to assume and hard to keep an eye on. AuthScope checks identity settings across Microsoft 365 and Google Workspace and flags gaps like legacy auth left enabled, so “MFA is on” means what you think it means. But the log check above costs nothing but ten minutes — so do that first, today, whether or not you ever automate it.