Over the last several years, organizations have been investing heavily in strengthening identity security within Microsoft 365. To strengthen security, they have enforced multi-factor authentication (MFA), conditional access policies, risk-based sign-in detection, and device compliance checks. These enhanced security measures are foundational components of modern, zero-trust architecture.
Even though organizations have configured these security protocols, one item has been overlooked and can quietly undermine all of it. This overlooked item is legacy authentication in Microsoft 365.
What legacy authentication actually means
Legacy authentication refers to older protocols that rely on basic authentication. The issue with basic authentication is that it transmits a username and password with every request and sometimes in an unencrypted manner. Common examples of protocols that use basic authentication are as follows:
- POP3
- IMAP
- SMTP AUTH
- Exchange ActiveSync using Basic Auth
- Older Office clients not using Modern Authentication
Unlike modern authentication methods that leverage token-based access (OAuth), legacy protocols cannot enforce MFA challenges, evaluate conditional access policies consistently or support device-based or risk-based controls. If the credentials are valid, then access is granted. Even if your organization enforces MFA authentication, these legacy authentication methods can easily bypass it.
Why attackers focus on it
Most breaches today are identity driven. Password spray, credential stuffing, and brute-force attacks target authentication endpoints like email clients and devices. The days of using these different methods to breach a firewall or perimeter device aren’t over, but they’re less frequent due to how organizations have secured those devices.
Legacy endpoints have become attractive due to the following reasons:
- They do not require interactive sign-ins.
- They often bypass modern protections, such as MFA.
- They can be targeted at scale.
- They are frequently left enabled “just in case” they are needed.
Microsoft reports that organizations blocking legacy authentication have significantly reduced account compromise rates. In fact, to help organizations adopt legacy authentication methods altogether, Microsoft began enabling a feature called Security Defaults for Microsoft 365 tenants. To continue using these legacy authentication methods, organizations had to manually disable Security Defaults.
The false sense of security
A common scenario that is still used in organizations is they go through the steps to enable or enforce MFA and believe they are secure. The issue is if they still use SMTP AUTH, like using an SMTP relay or emailing through a line-of-business application, attackers can attempt authentication without triggering MFA prompts or modern authentication.
Security maturity isn’t just about enabling advanced features or better security measures; it also is about disabling and removing the weak measures. Allowing legacy authentication creates a disconnect between security intent and security reality.
A strategic approach to disabling it
Disabling legacy protocols should be planned and handled with care so as not to disrupt the organization. Here are steps to help mitigate disruptions to the business.
- Review Azure AD sign-in logs for legacy authentication usage.
- Review Exchange mail flow reports to see which email addresses still use SMTP AUTH.
- Identify service accounts or applications relying on Basic Auth.
- Migrate applications to Modern Authentication (OAuth-based).
- Block legacy authentication via Conditional Access policies.
- Disable Basic Authentication in Exchange Online.
- Monitor and validate.
Most organizations find that legitimate dependency on legacy authentication is minimal and often limited to outdated devices or applications that should be modernized anyway. Legacy authentication is identity technical debt and should be dealt with as quickly as possible. In today’s security landscape, blocking or disabling legacy authentication isn’t optional, it is foundational.
This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.
