Why Blocking Legacy Authentication Is Still the Highest-Value Conditional Access Policy You Haven't Enforced

The problem with legacy protocols

IMAP, POP3, SMTP Auth, and Exchange ActiveSync using basic credentials have one thing in common: none of them support multi-factor authentication. Full stop. It does not matter how strong your MFA posture is elsewhere in your tenant. Any account that signs in via a legacy protocol bypasses it entirely.

This is not a theoretical risk. Credential stuffing attacks routinely target legacy authentication endpoints precisely because they know MFA will not fire. Microsoft's own data has consistently shown that blocking legacy authentication prevents the vast majority of identity-based attacks. And yet, when we audit a new tenant, we still find this policy missing or sitting in report-only mode where someone parked it six months ago and never came back to it.

Step 1: Check your exposure first

Before you block anything, you need to know whether legacy protocols are actually in use. Some tenants have none. Others have a finance system, a scanner, or a third-party app quietly authenticating via SMTP in the background. Blocking without checking first causes outages.

Go to entra.microsoft.com, navigate to Identity > Monitoring and health > Sign-in logs, and filter by Client app. Look specifically for: Exchange ActiveSync, Exchange Online PowerShell (basic auth), IMAP, MAPI over HTTP, POP3, SMTP Auth, and Other clients. Set the date range to 30 days.

Export that list. Any hit worth investigating has a username, a timestamp, and a client app. That tells you exactly which users or services are using legacy protocols and what those clients are.

Step 2: Create the policy in report-only mode

Go to entra.microsoft.com and navigate to Protection > Conditional Access > Policies. Select New policy and name it something clear: "Block legacy authentication."

Under Assignments, Users: set to All users. Add an exclusion for your break-glass emergency access accounts — this is not optional.

Under Target resources: All resources.

Under Conditions > Client apps: set Configure to Yes. Tick Exchange ActiveSync clients and Other clients only. Do not tick Browser or Mobile apps and desktop clients.

Under Access controls > Grant: select Block access.

Set the policy state to Report-only. Save it.

Step 3: Read the sign-in logs before you enforce

With the policy in report-only, every legacy authentication attempt is logged with a result of "Report-only: Failure." Go to Sign-in logs and filter by Conditional Access > Report-only: Failure, and look for the policy you just created.

If you see nothing after 48 hours, your tenant has no legacy authentication in active use and you can move straight to enforcement.

If you do see hits, work through each one:

For users: usually means an older email client configured with basic auth credentials. The fix is to reconfigure the client to use modern authentication (OAuth). Outlook 2013 and earlier need to be updated. Most issues here are old mobile email profiles that need to be removed and re-added.

For service accounts: these are the trickier ones. Scanner-to-email setups, monitoring tools, and line-of-business applications frequently use SMTP Auth with a shared mailbox and a stored password. Each one needs to be migrated to a supported flow: either OAuth client credentials for app-to-app, or an Azure Communication Services relay for devices that cannot support OAuth.

Give yourself two to four weeks in report-only if your estate is complex. One week is usually sufficient for a clean SME tenant.

Step 4: Flip it on

Once you are satisfied with what you see in the logs, go back to the policy, change the state from Report-only to On, and save.

At this point, any sign-in attempt using a legacy protocol will be blocked outright. The user or service will receive an error. Modern authentication clients are unaffected.

Set a reminder to check sign-in logs again 24 and 72 hours after enforcement. There is almost always one device or service that was not caught in the audit period.

One final thing: if you have multiple Conditional Access policies, check that none of them explicitly grant access to legacy client apps higher up the evaluation order. A conflicting policy can silently override your block.

Wrapping Up

Blocking legacy authentication is the single highest-value Conditional Access policy most tenants are not fully enforcing. It is low disruption when you do the preparation properly, and it closes an attack surface that MFA simply cannot cover by itself.

If you want a full Conditional Access review as part of a broader security posture assessment, that is something we do regularly as part of our Security and Compliance work. Details and fixed-price options at cloudbliss.co.uk.