Legacy Authentication May Still Exist in Your Microsoft 365 Tenant — Here’s How to Find It
Microsoft has spent years removing Basic authentication from Microsoft 365.
That has eliminated many of the most obvious legacy sign-in routes.
But it does not mean every organisation can assume:
“Legacy authentication is no longer our problem.”
Printers, scanners, old applications, monitoring systems, websites and specialist business software may still rely on older authentication methods.
SMTP AUTH deserves particular attention because Microsoft has extended the retirement timetable for Basic authentication.
So the useful question in 2026 is not:
“Has Microsoft disabled Basic authentication?”
It is:
“Is anything in our tenant still attempting to use legacy authentication, and what will break when we finally block or remove it?”
Microsoft recommends identifying legacy-authentication use through Microsoft Entra sign-in logs before enforcing a block.
What Is Legacy Authentication?
Legacy authentication generally refers to older username-and-password authentication methods that cannot use modern identity controls properly.
Microsoft’s Entra guidance describes legacy authentication as Basic authentication and identifies common examples involving older Office clients and mail protocols such as:
POP
IMAP
SMTP AUTH
Exchange ActiveSync
other older client types.
The major weakness is that these authentication flows cannot properly support protections such as:
multifactor authentication
phishing-resistant authentication
device compliance
modern Conditional Access controls
passwordless authentication
Microsoft explicitly warns that legacy authentication does not support MFA and prevents organisations from fully moving towards passwordless authentication.
That makes legacy authentication particularly attractive to attackers using stolen or guessed passwords.
Didn't Microsoft Already Disable Basic Authentication?
For most Exchange Online protocols:
yes.
Microsoft has removed Basic authentication from Exchange Online for protocols including:
Exchange ActiveSync
POP
IMAP
Remote PowerShell
Exchange Web Services
Offline Address Book
Autodiscover
Outlook for Windows
Outlook for Mac.
That is an enormous improvement.
But there are still reasons to audit your environment.
You may have:
applications attempting old sign-in methods
forgotten Conditional Access exclusions
accounts outside your blocking policy
old devices generating failed legacy sign-ins
SMTP AUTH using Basic authentication
specialist hybrid or line-of-business workflows
So the fact that many Basic-authentication routes have already been removed does not mean you should stop looking for legacy activity.
SMTP AUTH Is the Big 2026 Exception
SMTP AUTH is commonly used by:
multifunction printers
scanners
websites
alarm systems
monitoring tools
accounting applications
line-of-business software
Microsoft originally planned to remove Basic authentication from SMTP AUTH much sooner, but changed the timetable in January 2026.
The current plan is:
Now to December 2026
SMTP AUTH Basic authentication behaviour remains unchanged.
End of December 2026
Basic authentication for SMTP AUTH will be disabled by default for existing tenants, although administrators can still enable it where necessary.
New tenants after December 2026
SMTP AUTH Basic authentication will be unavailable by default.
Second half of 2027
Microsoft intends to announce the final removal date.
That means businesses should use the remaining time to migrate.
It is not a reason to keep old configurations indefinitely.
Step 1: Check Microsoft Entra Sign-In Logs
This is the best place to start.
Open the Microsoft Entra admin centre.
Go to:
Entra ID > Monitoring & health > Sign-in logs
Microsoft recommends adding the:
Client App
column and filtering for legacy authentication protocols.
Also repeat the investigation under:
User sign-ins (non-interactive)
because background applications and services may authenticate without an employee actively signing in.
Look for client types such as:
Exchange ActiveSync
IMAP
POP
SMTP
other legacy clients
The exact entries visible depend on your environment.
Don't Check Only Successful Sign-Ins
Failed legacy-authentication attempts matter too.
A failure could reveal:
old printer credentials
forgotten software
expired service-account passwords
badly configured mobile devices
an attacker trying password spraying
an application that will stop working when enforcement becomes stricter
Microsoft recommends filtering sign-in logs to identify clients that depend on legacy authentication, not simply looking at successful authentication.
A repeated failed SMTP attempt every six hours may tell you more about a forgotten business dependency than a successful employee login.
Step 2: Use the Legacy Authentication Workbook
For larger environments, raw sign-in logs can become difficult to analyse.
Microsoft provides a:
Sign-ins using legacy authentication
workbook.
Go to:
Entra ID > Monitoring & health > Workbooks
The workbook can help summarise legacy authentication by:
protocol
application
user
sign-in result
time range
and can examine up to 90 days of data depending on the logging setup.
This can be particularly useful for systems that authenticate infrequently.
A month-end finance process may only appear once every several weeks.
Step 3: Identify What Is Actually Behind Each Sign-In
Do not stop at:
SMTP — serviceaccount@company.co.uk
You need to know what system is using that identity.
For every legitimate legacy dependency, record:
Field What to capture
Account Which identity is authenticating?
Device/application What is actually using it?
Protocol SMTP, IMAP, POP or another client
Owner Which team owns the system?
Purpose Why does it need access?
Last use Is it still active?
Replacement OAuth, Graph, relay, upgrade or retirement
Deadline When will it be fixed?
This turns an authentication report into a migration plan.
Otherwise you simply accumulate:
“legacy auth exceptions”
that nobody ever removes.
Step 4: Review Your Conditional Access Policy
Microsoft’s current recommendation is to block legacy authentication using Conditional Access where licensing permits.
The recommended policy structure is broadly:
Users: all users
Resources: all resources
Client apps: Exchange ActiveSync clients + Other clients
Grant: Block access
Microsoft specifically recommends deploying the policy in:
Report-only
mode first.
That allows you to see what would be blocked without immediately disrupting the business.
Check whether your policy is:
enabled
disabled
Report-only
targeting all intended users
excluding too many accounts
targeting all resources
The existence of a policy does not prove you are protected.
Step 5: Review Exclusions Carefully
Conditional Access exclusions are sometimes necessary during migration.
They are also one of the easiest ways to accidentally keep legacy authentication alive indefinitely.
Look for exclusions involving:
service accounts
old employee accounts
generic groups
legacy-device groups
Ask:
Why does this exclusion still exist?
If nobody knows, investigate it.
Microsoft recommends excluding emergency access accounts from Conditional Access policies to prevent accidental tenant lockout, but ordinary users and service accounts should not automatically receive permanent exclusions.
An exception should have:
documented reason
named owner
compensating controls
review date
removal date
Security Defaults Can Already Block Legacy Authentication
Smaller Microsoft 365 environments may use Security Defaults instead of custom Conditional Access policies.
Microsoft says customers without Conditional Access licensing can use Security Defaults to block legacy authentication.
So if an old printer suddenly fails to authenticate, do not immediately disable Security Defaults.
First identify whether the device can be migrated to:
OAuth
SMTP relay
another supported mail-delivery method
Weakening tenant security to keep a ten-year-old scanner working is rarely a good long-term design.
Step 6: Check SMTP AUTH Separately
SMTP AUTH deserves its own review because:
SMTP AUTH enabled
does not necessarily mean:
Basic authentication is being used.
SMTP AUTH can use OAuth.
Microsoft supports OAuth 2.0 for SMTP AUTH, POP and IMAP.
So the correct question is:
How is this application authenticating?
Not simply:
Is SMTP enabled?
For Exchange Online PowerShell, you can review organisation-level configuration:
Get-TransportConfig |
Format-List SmtpClientAuthenticationDisabled
You can also check an individual mailbox:
Get-CASMailbox user@company.co.uk |
Format-List SmtpClientAuthenticationDisabled
A mailbox being allowed to use SMTP AUTH does not prove that its software is using Basic authentication.
Use sign-in/reporting evidence to determine the actual authentication flow.
What Should Replace Basic Authentication?
There is no single replacement for every workload.
OAuth 2.0
Where the application supports modern authentication, migrate it to OAuth.
This is generally the cleanest route for supported Exchange Online workloads.
Microsoft Graph
Applications sending, reading or processing Microsoft 365 information may be better redesigned around Microsoft Graph and appropriately scoped application permissions.
SMTP AUTH With OAuth
Some systems can continue using authenticated SMTP while replacing the username/password Basic-authentication flow with OAuth.
SMTP Relay
Printers and other internal devices may be better suited to a properly configured relay or connector depending on the environment.
Replace the Application or Device
Sometimes the correct answer is:
this software is too old.
If a device requires permanent weakening of identity security simply so it can send an email, replacement may be cheaper than maintaining the security exception.
Report-Only Before Enforcement
This is one of the most important deployment rules.
Create or review the legacy-authentication Conditional Access policy.
Start with:
Report-only
Then monitor it for long enough to capture:
everyday use
weekly jobs
month-end processes
payroll
occasional scanning
monitoring alerts
scheduled scripts
Microsoft explicitly recommends Report-only deployment before turning the policy on.
Do not run it for two hours on Tuesday morning and declare the tenant clean.
A Safer Enforcement Sequence
I would use this approach:
1. Review sign-in logs.
2. Review non-interactive sign-ins.
3. Use the legacy-authentication workbook.
4. Identify legitimate applications and devices.
5. Assign an owner to each dependency.
6. Migrate to OAuth, Graph, relay or a replacement system.
7. Configure the blocking policy in Report-only.
8. Review what the policy would block.
9. Pilot enforcement with a controlled group.
10. Enable tenant-wide enforcement.
11. Monitor failures.
12. Review remaining exclusions until only justified exceptions remain.
The objective is not simply:
turn on another Conditional Access policy.
It is:
remove the business dependency on authentication methods that cannot meet your security requirements.
Why MFA Alone Does Not Solve This
A common misconception is:
“Every employee has MFA, therefore legacy authentication isn't a problem.”
Legacy authentication is precisely problematic because it cannot participate properly in modern MFA flows.
Microsoft states that legacy authentication clients cannot support MFA and do not provide device-state information required by modern Conditional Access controls.
That means you need:
MFA + removal/blocking of legacy authentication
rather than treating them as alternatives.
Failed Legacy Attempts Can Be Good News
Once enforcement is working, you may continue seeing legacy authentication attempts in sign-in logs.
That does not automatically mean the policy failed.
If the attempts are:
blocked
the security control may be doing exactly what you intended.
The remaining job is to determine whether the attempts are:
an attacker
obsolete software
a forgotten device
a system somebody still relies on
Then eliminate unnecessary noise and fix legitimate dependencies.
Common Systems Businesses Forget
When performing a review, do not look only at employee PCs.
The overlooked systems are often:
multifunction printers
scanners
websites
network appliances
backup software
monitoring platforms
CCTV/alarm systems
accounting software
ERP systems
old scripts
helpdesk platforms
Speak to:
finance
operations
facilities
marketing
application owners
IT may not know that an old building-management system has been authenticating to Microsoft 365 once per day for six years.
How Hamilton Group Can Help
Hamilton Group can help businesses identify and remove legacy authentication without breaking the systems that still depend on it.
We can assist with:
Microsoft Entra sign-in analysis
Conditional Access
Security Defaults
SMTP AUTH
Microsoft 365 security reviews
printer and scanner email configuration
OAuth migrations
SMTP relay
Microsoft Graph
legacy service accounts
controlled enforcement
The goal is not simply to block an old protocol.
It is to reach a point where no important business process depends on a sign-in method that bypasses the modern identity protections you expect Microsoft 365 to provide.
Visit hgmssp.com or call 0330 043 0069.