Legacy Authentication Is Still On in Your Microsoft 365 Tenant — Here’s How to Check

Microsoft has disabled Basic authentication for most Exchange Online protocols, but that does not automatically mean every legacy sign-in route has disappeared from your Microsoft 365 environment.

Old printers, scanners, mobile apps, monitoring systems and line-of-business applications may still rely on authentication methods that do not support modern controls properly. SMTP AUTH with Basic authentication also remains relevant during Microsoft’s revised retirement period, with Microsoft now planning to disable it by default at the end of December 2026 before removing support during 2027. 

That leaves many businesses with an uncomfortable question:

Is legacy authentication still being used in our tenant—and what will break when we block it?

The safest answer is not to enable a block immediately and hope for the best. Start by checking your sign-in logs, identifying genuine dependencies and migrating or replacing the affected systems.

What Is Legacy Authentication?

Legacy authentication refers to older sign-in methods that send a username and password without using the modern token-based authentication controls supported by Microsoft Entra ID.

Common legacy client types can include:

• POP3
• IMAP4
• Older Exchange ActiveSync connections
• Older Office clients
• SMTP AUTH using Basic authentication
• Other clients that do not support modern authentication

These methods are risky because they may not support multifactor authentication, Conditional Access or other modern identity protections in the expected way. Microsoft recommends blocking legacy authentication with Conditional Access because password-based attacks frequently target these older protocols. 

Modern authentication uses OAuth-based tokens and can work with controls such as:

• Multifactor authentication
• Conditional Access
• Sign-in risk policies
• Device compliance
• Authentication strength
• Session controls

Blocking legacy authentication reduces the number of ways an attacker can use a stolen password.

Didn’t Microsoft Already Turn Basic Authentication Off?

Microsoft has permanently disabled Basic authentication for many Exchange Online protocols, including POP, IMAP, Exchange ActiveSync, Remote PowerShell and several older Exchange connection methods. 

However, you should not assume that the problem has completely disappeared.

Your environment may still contain:

• SMTP AUTH using Basic authentication
• Older applications using non-Exchange legacy sign-in methods
• Devices configured with outdated mail settings
• Conditional Access exclusions
• Accounts outside the scope of your blocking policy
• Hybrid or specialist systems using older authentication flows

Microsoft’s current SMTP AUTH timetable means businesses should continue checking printers, scanners and applications rather than waiting for the service to stop working. Basic authentication behaviour for SMTP AUTH remains available during 2026, with Microsoft planning further enforcement from the end of that year. 

Why Legacy Authentication Is Dangerous

Legacy protocols often depend entirely on the password.

An attacker who obtains the credentials may be able to authenticate without satisfying the same MFA or device requirements applied to a modern browser or application.

This creates opportunities for:

• Password spraying
• Credential stuffing
• Reuse of breached passwords
• Mailbox access
• Unauthorised email submission
• Bypassing device-based access policies

A user may appear protected because MFA is enabled, while an older protocol still accepts their username and password through another route.

The objective is therefore not merely to register users for MFA. It is to remove authentication paths that cannot use your intended controls.

Step 1: Check Microsoft Entra Sign-In Logs

The most useful place to begin is the Microsoft Entra admin centre.

Go to:

Microsoft Entra ID → Monitoring & health → Sign-in logs

Microsoft Entra records sign-in activity and allows administrators to filter and customise the displayed results. 

Set a date range long enough to capture less frequent systems. Thirty days is a reasonable starting point, but month-end finance tools or occasional scanners may require a longer review.

Then add or use the Client app filter.

Select the legacy client categories available in your tenant, which may include entries such as:

• Exchange ActiveSync
• Exchange Web Services
• IMAP4
• MAPI over HTTP
• Offline address book
• Other clients
• POP3
• Reporting web services
• SMTP
• Autodiscover

Browser and modern mobile or desktop applications are generally treated separately from these legacy client categories.

Review both successful and failed sign-ins.

A failed attempt still matters because it may show:

• An old device repeatedly trying to connect
• An application using an expired password
• Password-spraying activity
• A system that will fail once enforcement changes
• An attacker targeting a legacy protocol

Step 2: Use the Legacy Authentication Workbook

Microsoft Entra provides a Sign-ins using legacy authentication workbook that can help identify users and applications using older authentication methods. 

In the Entra admin centre, open:

Identity → Monitoring & health → Workbooks

Then locate the legacy-authentication workbook.

The workbook can help summarise:

• Legacy sign-ins over time
• Accounts involved
• Client applications
• Source IP addresses
• Protocols being used
• Successful and failed attempts

This is particularly useful when raw sign-in logs contain thousands of events.

Use the workbook to identify the patterns, then return to the individual sign-in records for detailed investigation.

Step 3: Check Your Conditional Access Policies

Go to:

Microsoft Entra ID → Protection → Conditional Access → Policies

Look for a policy with a name such as:

• Block legacy authentication
• Block Basic authentication
• Block legacy client apps
• Baseline legacy authentication block

Open the policy and check:

• Whether it is enabled
• Whether it is in report-only mode
• Which users are included
• Which users or groups are excluded
• Which resources are targeted
• Which client apps are selected
• Whether the grant control is set to block access

Microsoft’s recommended Conditional Access configuration targets all users and resources, selects legacy authentication clients and begins in Report-only mode so administrators can assess the impact before enforcing the block. Emergency access accounts should be excluded from the policy. 

Do not assume that the presence of a policy means you are protected. It may be:

• Disabled
• Report-only
• Assigned to the wrong group
• Missing guest users
• Excluding too many accounts
• Configured only for selected applications

Step 4: Check Microsoft-Managed Policies and Security Defaults

Microsoft may provide a managed Conditional Access policy that blocks legacy authentication. Review whether it exists, whether it is active and how it overlaps with your own policies. 

Smaller tenants may use Security Defaults rather than custom Conditional Access.

Security Defaults include protections designed to block legacy authentication protocols. 

Check the current setting under:

Microsoft Entra ID → Overview → Properties → Manage security defaults

Do not disable Security Defaults simply to make an old printer work unless equivalent protections have been deliberately implemented another way.

Step 5: Review SMTP AUTH

SMTP AUTH deserves separate attention because it is commonly used by:

• Multifunction printers
• Scanners
• Website contact forms
• Monitoring platforms
• Accounting systems
• Older business applications

In Exchange Online, SMTP AUTH can be controlled at both the organisation and mailbox level.

To check the organisation-wide setting with Exchange Online PowerShell:

Get-TransportConfig |

    Format-List SmtpClientAuthenticationDisabled

A value of True means SMTP AUTH is disabled for the organisation.

To check an individual mailbox:

Get-CASMailbox user@company.co.uk |

    Format-List SmtpClientAuthenticationDisabled

Microsoft documents both organisation-wide and mailbox-specific controls for authenticated SMTP submission. 

Remember that enabling SMTP AUTH does not automatically mean Basic authentication is being used. Applications can use OAuth with SMTP AUTH. The issue is the authentication method, not simply the protocol name.

Common Systems That Still Depend on Legacy Authentication

The systems most often missed are not employee laptops.

They are usually background devices and applications such as:

• Printers sending scanned documents
• Alarm and monitoring systems
• Backup software sending alerts
• Websites sending enquiry emails
• Building-management systems
• Old mobile devices
• Accounting or ERP applications
• Custom scripts
• Help-desk tools
• Network appliances

These systems may authenticate only once in a while, which is why a short sign-in review can miss them.

Speak to finance, operations, facilities and application owners before blocking access. IT may not know every device that sends email.

What to Record for Each Legacy Sign-In

Create a migration list containing:

Do not create one broad exception for every old system. Each dependency should have an owner and a removal plan.

How to Replace Legacy Authentication

The correct replacement depends on the workload.

Update the Application to OAuth

Where supported, configure the application to use OAuth 2.0 rather than a stored username and password.

This is the preferred route for applications that need authenticated access to Exchange Online.

Use Microsoft Graph

Applications reading or sending Microsoft 365 data may be better redesigned to use Microsoft Graph with appropriately scoped permissions.

Use SMTP AUTH With OAuth

A device or application that supports OAuth-based SMTP submission may continue using SMTP without Basic authentication.

Use SMTP Relay

Some internal devices can send through an appropriately secured SMTP relay or connector without using a normal employee mailbox password.

Replace or Retire the Device

Older hardware may not support modern authentication at all.

If a device requires permanent weakening of tenant-wide protections, replacement may be safer and cheaper than maintaining the exception.

Use an Alternative Microsoft Service

Depending on the volume and purpose, services such as Azure Communication Services Email or other supported delivery options may suit application-generated mail better than a user mailbox.

Test the Block in Report-Only Mode

Before enforcing the policy, set the Conditional Access policy to Report-only.

This allows sign-ins to continue while the logs show what the policy would have done. Microsoft recommends this approach in its legacy-authentication blocking guidance. 

Run the policy long enough to capture:

• Daily activity
• Weekly jobs
• Month-end processing
• Payroll
• Scheduled reports
• Occasional scans
• Backup and monitoring alerts

Review the Conditional Access results in the sign-in logs.

You are looking for legitimate activity that would be blocked—not reasons to postpone the policy forever.

Be Careful With Exclusions

An exclusion may be temporarily necessary while a critical system is upgraded.

However, exclusions become dangerous when they are:

• Undocumented
• Applied to large groups
• Assigned to employee accounts
• Never reviewed
• Used instead of fixing the application

Where an exception is unavoidable:

• Use a dedicated account.
• Restrict where it can sign in from.
• Give it no unnecessary licences or permissions.
• Prevent interactive use where possible.
• Use a long, unique credential if the legacy system still requires one.
• Monitor its activity.
• Set a removal date.

An exception should be a temporary risk decision—not the final architecture.

Enable the Block Gradually

A safe rollout might be:

1. Review at least 30 days of sign-in activity.
2. Identify every legitimate legacy dependency.
3. Contact system owners.
4. Migrate or replace affected applications.
5. Place Conditional Access in report-only mode.
6. Pilot enforcement with IT and a small user group.
7. Monitor failures and support tickets.
8. Expand to the full organisation.
9. Review exceptions monthly.
10. Remove the remaining exclusions.

Keep emergency access accounts outside the policy, but monitor them closely and never use them for ordinary work.

Common Mistakes

Assuming Microsoft Has Already Solved It

Most Exchange Basic authentication is gone, but SMTP AUTH and other old sign-in patterns may still require attention.

Checking Only Successful Sign-Ins

Repeated failures can expose forgotten systems or active attacks.

Blocking Before Identifying Dependencies

Printers, websites and monitoring systems may stop sending important messages.

Excluding Service Accounts Forever

The business avoids disruption but keeps the weakness permanently.

Confusing SMTP AUTH With Basic Authentication

SMTP AUTH can use OAuth. Confirm how the application actually authenticates.

Reviewing Only User Devices

The forgotten dependency is often a scanner, script or line-of-business application.

Legacy Authentication Checklist

• Review Entra sign-in logs by client app.
• Use the legacy-authentication workbook.
• Review successful and failed attempts.
• Check Security Defaults.
• Review custom and Microsoft-managed Conditional Access policies.
• Check policy exclusions.
• Review SMTP AUTH globally and per mailbox.
• Identify every device and application owner.
• Replace Basic authentication with OAuth or another secure method.
• Test the block in report-only mode.
• Enforce gradually.
• Review exceptions until none remain.

Final Thoughts

Legacy authentication can remain hidden because it often belongs to devices and applications that nobody checks until they stop working.

Do not assume that MFA registration or Microsoft’s retirement of older Exchange protocols has closed every route.

Use Microsoft Entra sign-in logs and the legacy-authentication workbook to identify current activity. Review Security Defaults and Conditional Access. Check SMTP AUTH separately, then migrate genuine dependencies before enabling a tenant-wide block.

The goal is not simply to switch on another policy.

It is to reach a position where no critical business system still depends on an authentication method that cannot support your modern security controls.

Unsure Whether Legacy Authentication Is Still Active?

Hamilton Group can help you identify and remove legacy authentication across Microsoft 365.

Our experts can help you:

• Analyse Microsoft Entra sign-in logs
• Review legacy-authentication workbooks
• Audit Conditional Access and Security Defaults
• Identify SMTP AUTH usage
• Find printers, scanners and applications using old credentials
• Migrate systems to OAuth or secure relay
• Create and test a block policy
• Manage temporary exceptions safely
• Monitor failed authentication attempts
• Complete a controlled tenant-wide rollout

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to close the legacy sign-in routes still exposing your Microsoft 365 environment.