Legacy authentication protocols such as POP, IMAP and SMTP AUTH cannot perform MFA, so attackers use them for password spray. In this lab you measure legacy sign-ins from the Entra sign-in logs, create a Conditional Access policy in report-only mode, check its impact, then switch it on with your emergency accounts excluded.
Key takeaways
- Legacy protocols skip MFA, so one blocked protocol removes a whole attack route
- Measure real usage from sign-in logs before you block anything
- Report-only mode shows the impact without affecting users
- Always exclude emergency access accounts from the policy
Why this lab matters
Legacy authentication means older protocols that send a username and password and nothing else: POP3, IMAP4, SMTP AUTH, Exchange ActiveSync with basic authentication and older Office clients. They cannot show an MFA prompt. If a password is guessed or leaked, a legacy protocol lets the attacker straight in, even when the same user is asked for MFA in a browser.
The fix is a single Conditional Access policy. The risk is blocking a printer, a scanner or a line of business app that nobody remembered. So you measure first, block second.
Use a test tenant. You need the Conditional Access Administrator role and Microsoft Entra ID P1 or P2. If your tenant still uses security defaults, legacy authentication is already blocked and Conditional Access policies cannot be created until security defaults are turned off.
Step 1: Measure legacy sign-ins
Use the sign-in logs
- Open the Microsoft Entra admin centre and go to Identity, Monitoring and health, Sign-in logs.
- Set the date range to the last 7 days, or 30 days if you have the retention.
- Add the filter Client app and tick every entry under Legacy Authentication Clients.
- Check both the interactive and non-interactive tabs. Download the results as CSV.
Or query with Graph PowerShell
Connect-MgGraph -Scopes "AuditLog.Read.All"
$since = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
$modern = "Browser", "Mobile Apps and Desktop clients"
Get-MgAuditLogSignIn -All -Filter "createdDateTime ge $since" |
Where-Object { $_.ClientAppUsed -and $_.ClientAppUsed -notin $modern } |
Group-Object UserPrincipalName, ClientAppUsed |
Sort-Object Count -Descending |
Select-Object Count, Name
Each row is a user and protocol pair. A count of zero across the tenant means you can move quickly. Any rows that remain need an owner.
Step 2: Find an owner for each result
| What you see | Likely cause | Usual fix |
|---|---|---|
| SMTP from one account, steady volume | Scanner, printer or application sending mail | Move to OAuth, or a mail relay service built for devices |
| IMAP or POP from a few users | Old mail client or a mobile mail app | Move the user to Outlook or a modern client |
| Failed attempts from many countries | Password spray | No fix needed. The block stops it |
| Exchange ActiveSync | Old phone mail profile | Recreate the profile with modern authentication |
Step 3: Create the policy in report-only mode
- Go to Protection, Conditional Access, Policies, New policy.
- Name it
CA-BLOCK-LegacyAuth. - Users: include All users. Exclude your emergency access accounts.
- Target resources: All resources.
- Conditions, Client apps: set Configure to Yes and tick only Exchange ActiveSync clients and Other clients.
- Grant: Block access.
- Set Enable policy to Report-only and create it.
Leave the policy in report-only for at least one full business week, so weekly jobs and month end tasks have a chance to appear.
Step 4: Review the impact
Open any legacy sign-in in the sign-in logs and select the Report-only tab. A result of Report-only: Failure means the sign-in would have been blocked. Work through the list from Step 2 until every remaining failure is either fixed or is an attack you are happy to block.
Step 5: Enforce and verify
- Edit the policy and change Enable policy to On.
- From a test account, try an IMAP or POP connection with a mail client set to basic authentication. It should fail.
- Find that attempt in the sign-in logs. The Conditional Access tab should show
CA-BLOCK-LegacyAuthwith the result Failure, and the sign-in status should be Failure with error code 53003.
You are finished when the policy is On, a legacy test sign-in is blocked with error 53003, and a normal browser sign-in for the same user still works.
Evidence to keep
- The CSV of legacy sign-ins before the change.
- A screenshot of the policy settings, including the excluded accounts.
- The blocked test sign-in showing the policy name.
- A short list of any devices or apps you migrated, with the owner of each.
Clean up
In a test tenant, set the policy back to Off or delete it when you are done. In a real tenant this policy stays on permanently.
Frequently asked questions
What counts as legacy authentication in Entra ID?
Any protocol that cannot perform modern authentication, including POP3, IMAP4, authenticated SMTP, Exchange ActiveSync with basic authentication and older Office clients. In Conditional Access these are the client app types Exchange ActiveSync clients and Other clients.
Will blocking legacy authentication break printers and scanners?
It can, if a device sends email with a username and password over SMTP AUTH. That is why the lab measures usage and runs the policy in report-only mode first, so you can move those devices to a supported method before enforcing the block.
Do security defaults already block legacy authentication?
Yes. Security defaults block legacy authentication for all users. You only need this Conditional Access policy when security defaults are turned off because you manage your own policies.
Why exclude emergency access accounts from the policy?
Emergency accounts are your way back in if a policy is misconfigured. Excluding them from every blocking policy, and monitoring their use, prevents a tenant lockout.