When it comes to securing your organization, nothing is more effective than enabling multi-factor authentication (MFA) for your users. Whether using traditional methods like phone or token codes, or modern passwordless methods like the Authenticator, Windows Hello, or FIDO, MFA reduces the probability of account compromise by more than 99.9%. As part of adopting MFA, you should block legacy authentication endpoints that can’t support MFA. Legacy authentication protocols like POP, SMTP, IMAP, and MAPI can’t enforce MFA, making them preferred entry points for adversaries attacking your organization.
Organizations use Azure AD Conditional Access to enforce Zero-Trust Least-Privileged Access policies. Conditional Access allows you to determine access based on explicitly verified signals collected during the user’s sign-in, such as the client app, device health, session risk, or IP address. This is the best mechanism to block legacy authentication, but a recent analysis showed fewer than 16% of organizations with Conditional Access have policies that apply to sign-ins using legacy authentication protocols.
To help organizations more easily achieve a secure Zero Trust posture, we’re announcing 2 updates to help customers block legacy authentication:
Daniel Wood, a program manager on the Conditional Access team, has written a blog to explain how these changes can help secure your organization. As always, please share your feedback below or reach out to email@example.com with any questions.
Alex Simons (@Alex_A_Simons)
Corporate Vice President of Program Management
Microsoft Identity Division
Today, I’m excited to announce we’re taking a big step forward in helping to make organizations more secure by changing the default Conditional Access configuration for new policies to apply to all client apps—including legacy authentication clients.
We’ve simplified the admin experience to make it easier for admins to create policies targeting modern authentication clients and legacy authentication clients. By default, all new Conditional Access policies will apply to all client app types when the client apps condition is not configured. Sign-ins from legacy authentication clients don’t support MFA and don’t pass device state information to Azure AD, so they will be blocked by Conditional Access grant controls, such as requiring MFA or compliant devices. If you have accounts which must use legacy authentication, you can grant them policy exceptions to keep them from being blocked.
If you want to create a Conditional Access policy that only targets legacy authentication clients, switch the client apps Configure toggle to Yes and deselect Browser and Mobile apps and desktop clients, leaving Exchange ActiveSync and Other clients selected.
And for those of you who manage your policies using the Microsoft Graph API, we’ve simplified the client apps schema with the release of the new Conditional Access API in v1.0 to match the new UX. Here’s an example of the new default configuration for the client apps condition when you create a new policy using the API.
If you have existing Conditional Access policies, they will continue to apply to the same client apps with no change. However, if you view an existing policy, we’ve made it easier to see which client apps are selected by removing the Configure Yes/No toggle. Existing policies where the client apps condition was not configured now look like this:
Before creating a new policy, it’s good to understand who’s using legacy authentication in your organization. To see which client apps and protocols are being used in your organization during sign-in, simply navigate to the Sign-ins page and filter the results by client app type.
We hope that these changes make it easier for admins to secure their organizations by blocking legacy authentication. As always, please share your feedback below or reach out to
Daniel Wood (@Daniel_E_Wood)
Microsoft Identity Division
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.