Blocking IMAP, POP and basic SMTP: closing the MFA gap

You have rolled out MFA on every account, and yet one door stays open. Legacy authentication protocols — IMAP, POP, basic SMTP, and older Exchange ActiveSync clients — cannot handle a second factor. An attacker holding a stolen password can connect straight through, without ever triggering your MFA. It is one of the most common blind spots in Microsoft 365 environments, and one of the easiest to close once you have measured what still uses it.

Why these protocols are dangerous

Basic authentication dates from a time when a password was enough. It provides no mechanism for a second factor, which makes it a permanent blind spot, even on an otherwise well-protected tenant.

• Basic authentication sends a plain username/password pair, with no second factor.
• It is heavily targeted by password spraying attacks.
• An account compromised via IMAP or POP often goes unnoticed, with no MFA alert.
• These protocols are rarely needed on a modern estate running recent Outlook clients.

Password spraying, a quiet threat

Unlike a brute-force attack that hammers a single account, password spraying tries one very common password (like a season name followed by the year) against hundreds of accounts at once. This approach slips under lockout thresholds and stays quiet. Against a basic-authentication entry point it does not even need to bypass MFA: the protocol never asks for it. That is exactly what blocking neutralises.

Find out what is still in use

Before blocking, measure. Microsoft Entra sign-in logs let you filter connections by client protocol and isolate legacy authentication. That reveals the few accounts or applications (multifunction printers, mail-sending scripts, older automation) that still depend on it, and stops you from cutting off a critical service by surprise.

1. 1Open the sign-in logs and filter on 'Client legacy authentication'.
2. 2List the service accounts and devices using basic SMTP to send mail.
3. 3Plan a modern alternative (OAuth-authenticated SMTP, Graph API, or a dedicated relay).
4. 4Document every remaining exception with a justification and a review date.

The dependencies people often forget

Surprises rarely come from user workstations, almost always from devices and automation. A multifunction printer that emails scanned documents, an old line-of-business app that ships reports overnight, a sensor or a UPS that alerts by email: all of these may still rely on basic SMTP. Identifying them before the block avoids the classic Monday-morning call reporting that 'the scans stopped arriving'.

Block it cleanly

The recommended approach is to create a Conditional Access policy that blocks legacy authentication for all users, temporarily excluding the few documented exceptions. In addition, basic SMTP authentication can be disabled at the Exchange Online level. Run it in report-only mode where possible, watch the connections affected, then enforce the block once dependencies are handled. This phased method lets you catch a forgotten dependency before it turns into an outage, and gives your team time to migrate any remaining service to a modern, authenticated channel. Blocking at two levels — Conditional Access and Exchange Online — also closes the gap even if one control is later loosened by mistake.

Handle exceptions without making them permanent

An acceptable exception is a temporary one, tracked and dated. The trap is to create an exclusion group 'for now' and forget it: after a few months, that group becomes the exact gap you meant to close. Give each exception an owner, a justification and a review date, and migrate the device to a modern method as soon as possible to empty that group.

Verify after blocking

Blocking is not the end: you need to confirm the gap is closed and stays closed. After enforcement, check the sign-in logs again to make sure no legacy authentication still succeeds, and keep an eye on any tickets from affected users.

• Confirm there are no successful legacy sign-ins in the logs.
• Periodically review exceptions and remove those no longer needed.
• Alert on any new basic authentication attempt.
• Record the enforcement date as evidence for your audits.

Common mistakes to avoid

• Blocking without measuring first: you cut off a critical service and disable the policy in a panic.
• Creating a permanent exclusion group instead of dated, tracked exceptions.
• Forgetting to disable basic SMTP on the Exchange Online side, assuming Conditional Access is enough.
• Keeping no dated proof of enforcement, and being caught empty-handed on audit day.

A thirty-day switchover plan

Rather than cutting everything off in one move, it is wiser to spread the block over roughly a month. This pace leaves time to handle each dependency without haste, to communicate with the teams involved, and to react calmly if a source of legacy authentication had slipped past the initial inventory.

1. 1Week 1: turn the policy on in report-only mode and collect the real legacy connections.
2. 2Week 2: contact the owners of the service accounts and devices you identified.
3. 3Week 3: migrate each dependency to a modern method and document the residual exception.
4. 4Week 4: switch the policy to active blocking and watch the logs closely.

Take a forty-seat small business. Analysis reveals three sources of legacy authentication: two multifunction printers and a billing application that sends reminders overnight. The printers are reconfigured with a dedicated send connector, and the application is updated to a version compatible with modern authentication. After three weeks, no basic connection appears in the logs anymore, and blocking is enabled without a single user ticket the following Monday.

How AuPoint helps

AuPoint offers this legacy-authentication blocking policy in a few clicks, with a preview of the accounts affected to avoid any surprise outage. You see who would be affected before enforcing, which makes the decision calm rather than risky. The platform then keeps a record of the enforcement and links it to the frameworks.

Frequently asked questions

Will blocking stop Outlook from working?

No. Recent Outlook clients use modern authentication (OAuth), which is not affected by the block. Only clients and devices genuinely on basic authentication are impacted, which is why listing them in advance matters. In most modern estates, the number of genuinely affected users is very small, and it is almost always devices and scripts rather than people that need attention.

How do we email from a printer after the block?

Several options exist: a dedicated send connector in Exchange Online, an internal SMTP relay, or sending via a modern authenticated method depending on the device's capabilities. The key is to prepare this alternative before cutting basic SMTP.

Should we block everything at once?

No, proceed in stages: report-only mode, connection analysis, handling dependencies, then enforcement. This phased approach lets you catch a forgotten dependency before it turns into an outage.

How long should sign-in logs be kept?

Keep them at least over a period covering your audits, often several months. A long enough window lets you demonstrate, after the fact, that no legacy authentication succeeded once blocking was enforced.

Does the block also apply to guest accounts?

Yes, the Conditional Access policy can cover all users, including guests. Check, however, that your legitimate partners use modern clients before extending the constraint to that scope, so you do not break an ongoing collaboration.

By closing this classic gap, you finally align technical reality with your MFA policy. With AuPoint, you enforce the legacy-authentication block with an impact preview, then generate a dated, exportable compliance report with a coverage score per framework (ISO 27001, NIS2, GDPR). You hold tangible proof that this door is properly shut in your environment, and you can show, at any time, exactly when it was closed and which scope it covers.