The Problem With Legacy Authentication
Legacy authentication refers to older protocols — POP, IMAP, SMTP AUTH, MAPI, ActiveSync with basic credentials, and clients like Outlook 2010/2013 — that were designed before modern authentication existed. They do not support multi-factor authentication. Full stop.
This matters because an attacker doing a credential stuffing or password spray attack doesn’t care that you enabled MFA. If your tenant still accepts legacy auth, they skip modern auth entirely and go straight to IMAP or SMTP AUTH with a stolen password. Microsoft’s own telemetry from 2024 shows that more than 99% of password spray attacks against M365 tenants target legacy authentication endpoints specifically.
New tenants created after 2022 have legacy auth disabled by default via Security Defaults. The problem is the long tail of tenants that predate that — especially anything migrated from on-premises Exchange or old Office 365 plans. Those tenants almost always have legacy auth still running, and frequently nobody has audited it.
This post covers how to block legacy authentication in Microsoft Entra ID using a Conditional Access policy. You’ll run a pre-flight report first, create a break-glass account, stage the policy in report-only mode, then flip it live. The environment is M365 Business Premium or higher (Entra ID P1 license required for Conditional Access). All steps were verified in the Entra admin center as of Q1 2026 — the portal paths have moved several times in 2024-2025, so verify navigation in your own tenant before scripting anything.
Prerequisites
Before you touch anything:
- Entra ID P1 license or higher — P1 is included in M365 Business Premium, E3, and E5. If you’re on Business Basic or Standard, scroll to the Security Defaults section below.
- Global Administrator or Conditional Access Administrator role in Entra ID.
- Sign-in logs access — available by default for the last 30 days on P1 tenants.
- At least one hour of buffer before any production change window. You do not want to rush this.
Step 0: Generate a Legacy Authentication Usage Report
Do not skip this step. If you block legacy auth without knowing what’s using it, you will break something in production and be scrambling.
Navigate to: Identity → Monitoring → Sign-in logs
Filter by Client app and select every entry under the “Other clients” category. These map to legacy auth protocol sessions. Alternatively, use the built-in workbook:
Identity → Workbooks → Sign-ins using Legacy Authentication
Export the results to CSV. Go through every entry. You are looking for:
- Real user accounts — these need to be migrated to modern auth clients (Outlook Mobile, modern Outlook desktop)
- Service accounts — printers, scanners, monitoring tools (PRTG, SolarWinds), line-of-business apps using EWS or IMAP
- Shared mailboxes being polled by scripts
This CSV is your migration scope. Every item on it needs to be resolved — either migrated to modern auth or explicitly excluded from the policy with documented justification — before you go live.
Real example: A 50-user tenant active since 2018 with no legacy auth controls showed 47 distinct accounts with legacy auth hits in the last 30 days. Breakdown: 41 were phones using IMAP (migrated to Outlook Mobile), 4 were a monitoring system (moved to Graph API), 2 were an office printer using SMTP AUTH (moved to an M365 SMTP relay, which is a separate configuration that doesn’t count as legacy auth).
Step 1: Create a Break-Glass Emergency Access Account
If you already have a dedicated emergency access account excluded from all CA policies, skip this step. If you don’t, create one now — before you touch Conditional Access.
Navigate to: Identity → Users → New user → Create new user
- Username:
emergency-access@<yourdomain> - Password: Generate 32+ characters. Store it in an offline password manager (KeePass) or a physical safe. Not in the same password manager you use daily.
- Role: Global Administrator
Once the account exists, exclude it from every Conditional Access policy you create from this point forward. This account is your recovery path if a misconfigured policy locks out all administrators. Treat it accordingly.
Step 2: Create the Conditional Access Policy
Navigate to: Identity → Protection → Conditional Access → Policies → New policy
Name the policy: BLOCK - Legacy Authentication - All Users
Naming conventions matter for auditability. The BLOCK - prefix makes the intent obvious in the policy list.
Users:
- Include: All users
- Exclude: Your emergency-access account. Also exclude any service principals you confirmed in Step 0 that genuinely cannot be migrated away from legacy auth yet.
Target resources: All cloud apps
Conditions → Client apps:
- Set the toggle to Yes (configure)
- Check: Exchange ActiveSync clients
- Check: Other clients
- Uncheck: Browser, Mobile apps and desktop clients — these are modern auth and you do not want to touch them here.
Access controls → Grant:
- Select Block access
Do not enable the policy yet.
Step 3: Run in Report-Only Mode First
Before going live, set Enable policy → Report-only and save.
Leave it running for 24 to 48 hours. Then go back to:
Identity → Monitoring → Sign-in logs
Filter by: Conditional Access status → Report-only: Failure
This view shows exactly which sign-ins would have been blocked if the policy were enforced. Compare this list against your Step 0 CSV. If anything appears here that isn’t already on your migration scope list — investigate it before proceeding. Unknown legacy auth sessions at this stage mean you have something you missed.
Once the report-only failure list matches your migration scope and everything on that scope has been resolved or explicitly excluded, you’re ready to flip live.
Step 4: Enable the Policy
Navigate back to the policy and set Enable policy → On. Save.
Propagation typically completes within a few minutes.
Validate immediately after enabling:
If you have access to an Outlook 2010/2013 client or any SMTP client configured with username and password basic auth, attempt a connection to your mailbox. It should fail with an error similar to:
AADSTS50053: The account is locked.
AADSTS53003: Access has been blocked by Conditional Access policies.
Modern Outlook, Outlook Mobile, Teams, and browser-based access should continue working without interruption.
Validating After 24 Hours
After the policy has been live for 24 hours:
Identity → Monitoring → Sign-in logs
Filter by Conditional Access status → Failure and look for the block reason referencing your policy name.
You should see a steady stream of blocked legacy auth attempts from external IPs — this is normal and expected. Attackers probing legacy endpoints don’t stop just because those endpoints now return an error; they just stop succeeding.
If you see a service that you know needs legacy auth appearing in the failure list, you have two options:
- Preferred: Migrate it to modern auth (Graph API for mailbox access, OAuth for SMTP)
- Last resort: Add it to the policy exclusion list with documented justification and an owner assigned to migrate it
Rollback Procedure
If something breaks that you can’t immediately fix:
Identity → Protection → Conditional Access → Policies → [your policy] → Enable policy → Off → Save
Legacy auth is permitted again within 1-2 minutes. This is why you set the policy to Off rather than deleting it — toggling off is instant. Recreating the policy from scratch takes time you may not have during an incident.
What About Tenants Without Entra ID P1?
If your tenant is on M365 Business Basic or Business Standard, Conditional Access is not available. Use Security Defaults instead:
Identity → Properties → Manage Security defaults → Enable Security defaults → Yes
Security Defaults blocks legacy authentication at the tenant level. The trade-off is that it is all-or-nothing — no exclusions, no service account carve-outs. If a printer or monitoring tool uses legacy auth, it breaks and you can’t exclude it without disabling Security Defaults entirely.
For shops under 25 users with no legacy service dependencies, Security Defaults is the right call — it’s free, takes 30 seconds, and covers the major attack surface. For 25+ users with real legacy service dependencies, the correct answer is to upgrade to Business Premium for the P1 license and implement the CA policy approach described above.
One important note: You cannot have both Security Defaults and Conditional Access policies active simultaneously. Enabling Security Defaults disables Conditional Access. If you’re graduating from Security Defaults to CA policies, you disable Security Defaults first, then build your CA policy set.
What This Policy Does Not Do
Be clear on scope:
- Does not enforce MFA — that requires a separate CA policy targeting modern auth sign-ins
- Does not block phishing — phishing-resistant auth (FIDO2, passkeys) is a separate workstream
- Does not surface compromised accounts — use Identity Protection risk reports for that
- Does not replace a full CA policy framework — this single policy handles one specific attack vector
Troubleshooting
Printer or scanner stops sending email after policy goes live
Cause: The device is using SMTP AUTH with basic credentials, which is now blocked by the policy.
Fix: Reconfigure the device to use the Microsoft 365 direct send or SMTP relay endpoint, which doesn’t require authentication from the device and bypasses the CA policy entirely. The specific configuration depends on your printer model — refer to Microsoft’s “How to set up a multifunction device or application to send email using Microsoft 365” documentation. Verify the relay endpoint in your environment.
Monitoring tool (PRTG, SolarWinds, etc.) mailbox sensor stops working
Cause: These tools often default to IMAP or POP for mailbox monitoring, both of which are legacy auth protocols.
Fix: Check whether the tool supports Microsoft Graph API or OAuth 2.0 for mailbox access. PRTG, for example, supports Microsoft 365 sensors via Graph API as of recent versions — verify against your installed version’s documentation. If the tool has no modern auth option, the sensor needs to be replaced with a different monitoring method.
Users on Mac Mail.app lose mailbox access
Cause: Mail.app on older macOS versions defaults to legacy auth when configured using the generic “Other” mail account type.
Fix: The user removes the account from Mail.app and re-adds it using the Microsoft Exchange account type (not “Other”). This forces Mail.app to negotiate OAuth/modern auth. If the Mac is old enough that Exchange account type doesn’t support OAuth, the user needs Outlook for Mac or Outlook Mobile.
Old Outlook versions (2013 and earlier) stop authenticating
Cause: Outlook 2013 and earlier do not support modern authentication. This is expected behavior, not a misconfiguration.
Fix: Upgrade to Outlook 2016 or later (with modern auth registry keys enabled if needed — verify in your environment), or migrate users to Microsoft 365 Apps. There is no exclusion or workaround that keeps these clients functional while blocking legacy auth; the protocol support simply isn’t there.
Line-of-business application using Exchange Web Services (EWS) with basic auth breaks
Cause: EWS basic auth was retired by Microsoft in October 2022, but applications that were already connected sometimes continued working until a policy explicitly blocks it. This policy surfaces those holdouts.
Fix: The application needs to be updated to use EWS with OAuth 2.0, or migrated to the Microsoft Graph API (preferred, since EWS is in maintenance mode). Escalate to the application vendor if this is third-party software.
The policy appears to apply to your break-glass account
Cause: You forgot to add the break-glass account to the exclusion list when creating the policy.
Fix: Edit the policy, go to Users → Exclude, add the break-glass account. Save. Going forward, verify exclusions on every CA policy before enabling.
FAQ
What is legacy authentication in Entra ID?
Legacy authentication refers to a set of protocols and clients that use basic authentication (username and password sent directly) and do not support modern authentication protocols like OAuth 2.0. The primary examples are POP3, IMAP, SMTP AUTH, MAPI over HTTP with basic credentials, Exchange ActiveSync with basic auth, and older versions of the Office client suite (Outlook 2013 and earlier). The defining characteristic is that these protocols have no mechanism to support multi-factor authentication — the authentication handshake is purely credential-based, which means MFA policies are effectively invisible to them.
What happens when I block legacy authentication in Entra ID?
Any sign-in attempt that uses a legacy auth protocol against a cloud app covered by the policy returns an access blocked error. Modern auth clients — current versions of Outlook, Outlook Mobile, Teams, browser-based access — are unaffected because they use OAuth 2.0 and are not matched by the policy conditions. Attackers attempting credential stuffing via IMAP or SMTP AUTH will receive an error rather than a token. Legitimate users on legacy clients will lose access until they migrate to a modern auth client.
Does Conditional Access require Entra ID P1 to block legacy auth?
Yes. Conditional Access is a feature of Entra ID P1 and above. P1 is included in M365 Business Premium, E3, and E5 licenses. If your tenant is on M365 Business Basic or Business Standard (which include only Entra ID Free), Conditional Access policies are not available. The alternative is Security Defaults, which also blocks legacy auth but offers no exclusion capability.
How do I find which users are using legacy authentication in Entra ID?
Navigate to Identity → Monitoring → Sign-in logs in the Entra admin center. Filter by Client app and select the entries categorized as “Other clients” — these represent legacy auth sessions. The faster path is the built-in workbook at Identity → Workbooks → Sign-ins using Legacy Authentication, which aggregates this data into a readable report. Export to CSV before making any changes. Review the list carefully; service accounts and application service principals appear here alongside user accounts.
Can I block legacy auth without Conditional Access in Entra ID?
Yes, using Security Defaults. Navigate to Identity → Properties → Manage Security defaults and enable the feature. Security Defaults blocks legacy authentication tenant-wide as one of several baseline controls it applies. The limitation is that Security Defaults is binary — it applies to all users with no exceptions. If any service account or application in your tenant requires legacy auth, enabling Security Defaults will break it with no recourse other than disabling Security Defaults entirely. For tenants with no legacy service dependencies and under the Business Premium license threshold, Security Defaults is a practical and free solution.
What is the difference between Security Defaults and Conditional Access for blocking legacy auth?
Both block legacy authentication, but they differ in control granularity. Security Defaults is a Microsoft-managed baseline that applies a fixed set of policies including legacy auth blocking and MFA requirements. It requires no configuration, no additional license, and offers no customization — no exclusions, no exceptions, no staged rollout. Conditional Access is a policy engine you configure yourself. It allows you to exclude specific accounts or service principals, run in report-only mode before enforcement, scope policies to specific apps, and combine conditions in ways Security Defaults cannot. The practical decision rule: Security Defaults for small tenants with clean environments and Basic/Standard licenses; Conditional Access for anything with service dependencies, hybrid configurations, or a Business Premium or higher license.
Why is my printer SMTP failing after blocking legacy authentication?
Most multifunction printers configured for “Scan to Email” or “Send to Email” use SMTP AUTH with a username and password, which is a legacy auth protocol. Once the Conditional Access policy is enforced, those SMTP AUTH connections are blocked. The device doesn’t support OAuth, so it can’t adapt automatically. The fix is to reconfigure the printer to use the Microsoft 365 SMTP relay or direct send endpoint, both of which allow mail relay without requiring the device to authenticate via a user credential. The specific configuration steps vary by printer model and M365 tenant configuration — verify the correct relay settings in your environment.
How do I exclude a service account from a Conditional Access policy in Entra ID?
When creating or editing the policy, navigate to the Users assignment section. Under Exclude, you can add individual users, groups, or service principals. For service accounts, add the specific user account or, if you have multiple service accounts, create a dedicated security group (e.g., CA-Exclusion-LegacyAuth-ServiceAccounts), add the accounts to that group, and exclude the group from the policy. Using a group makes ongoing management easier — adding a new service account to the exclusion is a group membership change, not a policy edit. Every excluded account should have a documented reason and an owner responsible for migrating it to modern auth. Treat exclusions as temporary exceptions, not permanent carve-outs.
Conclusion
Blocking legacy authentication is one of the highest-leverage security actions you can take on an M365 tenant. The attack surface is real, well-documented, and actively exploited. The fix is a single Conditional Access policy that takes under an hour to deploy correctly when you follow the pre-flight report process.
The steps in order: run the usage report, create a break-glass account, build the policy with the right client app conditions, run report-only for 24-48 hours, resolve everything on your migration scope list, then flip to enforced. Rollback is a toggle if something goes sideways.
If you’re on Business Basic or Standard without P1, enable Security Defaults today — it’s better than nothing and takes 30 seconds.
The next logical step after blocking legacy auth is requiring MFA for all users on modern auth via a separate Conditional Access policy. That’s covered in the MFA enforcement guide on this site.