Is legacy email authentication (IMAP, POP, basic authentication) disabled?
Legacy protocols authenticate with a password alone and never evaluate a Conditional Access policy. One enabled path can undo the entire MFA answer.
What the carrier is actually asking
The carrier is asking whether older mail protocols that cannot present a second factor are still permitted: IMAP, POP, SMTP authentication, and the basic authentication used by older clients. These paths predate modern policy and are invisible to it.
Why it is underwritten
Password spraying against legacy endpoints was the dominant account compromise technique for years, precisely because the second factor never entered the picture. Carriers ask because it is the most common way an organisation that has correctly deployed multi-factor still suffers a mailbox compromise.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is fully measurable in the tenant, and the sign-in log settles it more convincingly than any policy screenshot.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Conditional Access policy blocking legacy authentication clients | A policy in enabled state blocking other clients, applied to all users |
| Entra ID | Sign-in logs filtered to legacy client applications | No successful legacy sign-ins in the reporting period. This is the evidence that settles the question |
| Microsoft 365 | Exchange Online authentication policies and per-mailbox protocol settings | IMAP, POP, and SMTP authentication disabled at the organisation level, with exceptions enumerated |
| Microsoft 365 | SharePoint and OneDrive legacy authentication setting | Blocked, since the same class of bypass exists outside mail |
| Microsoft 365 | SMTP authentication for devices and applications | Multifunction devices and applications that send mail moved to modern authentication or to a restricted connector |
The exception that survives is almost always a device that sends scanned documents by mail, or an application that sends notifications. Both can be moved to a restricted connector or an authenticated relay. Leaving SMTP authentication enabled tenant-wide for one device leaves it enabled for every account.
What a defensible yes requires
- Legacy authentication is blocked by policy, not merely deprecated by the vendor.
- Sign-in logs confirm no successful legacy authentication in a recent window.
- Per-protocol settings are disabled at the organisation level rather than per mailbox.
- Devices and applications that need to send mail use a restricted, scoped path.
- Any remaining exception is named, scoped to specific accounts, and reviewed.
How this answer goes wrong
Microsoft's own deprecation is assumed to have handled it, and one protocol remains enabled for a legacy application. Or a Conditional Access policy blocks legacy clients with an exclusion group created for a migration two years ago that still contains fifteen accounts. Both produce a confident yes and a live bypass.
Frequently asked
Has Microsoft not disabled this already?
Basic authentication has been retired for most protocols, and SMTP authentication remains and can be re-enabled per tenant and per mailbox. Verify in your own tenant rather than assuming.
How do we prove it?
Filter the sign-in log by legacy client applications over the last month. An empty result is the strongest evidence available for this question.
What if an application still needs SMTP?
Use a scoped connector with restricted source addresses and a dedicated account, or move it to a modern authentication path. Keep the exception narrow and documented.
Does this affect the MFA answer?
Directly. A live legacy path means the MFA answer is qualified whether or not you qualified it, which is why the two questions are read together.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture