New tools to block legacy authentication in your organization

Published 03-12-2020 11:30 AM 51.1K Views

Hey folks,


If you’re a regular reader of this blog series, you know we’ve been advocating for admins to enable multi-factor authentication (MFA) for a while. In one of my previous posts, Your Pa$$word doesn’t matter, I showed how vulnerable passwords are to attack and why enabling MFA reduces the likelihood of being compromised by more than 99.9 percent.


For MFA to be effective, you also need to block legacy authentication. This is because legacy authentication protocols like POP, SMTP, IMAP, and MAPI can’t enforce MFA, making them preferred entry points for adversaries attacking your organization. In September 2019, Exchange Online announced the deprecation of legacy authentication prior to its removal on October 13, 2020. For more on the impact of legacy auth, and how we weaned Microsoft users off of it, check out the talk Lee Walker and I gave at RSA a few weeks ago.


The numbers on legacy authentication from an analysis of Azure Active Directory (Azure AD) traffic are stark:

  • More than 99 percent of password spray attacks use legacy authentication protocols
  • More than 97 percent of credential stuffing attacks use legacy authentication
  • Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled



Disabling legacy authentication for users is a must-do on your identity security checklist. In this blog post, I’ve asked Daniel Wood, a PM on the Identity Protection team, to walk through all the steps you need to take to secure your organization and introduce three changes we’ve made in Azure AD to make your job easier.


As always, we’d love to hear your thoughts! Ping me on Twitter (@alex_t_weinert) and stay safe out there.


Hey everyone!


As one of the PMs on the Identity Protection team, I’m going to walk you through a step-by-step guide to blocking legacy authentication in your organization. But first, I’m excited to announce three new capabilities our team has released to make the job easier.


  1. The sign-in logs are now available in the Azure portal to all tenants for 7 days
  2. The sign-in logs now include the user agent used to sign in
  3.  The sign-in logs client apps filter now includes all legacy Exchange Online protocols
    legacy auth update pic.png

Blocking legacy authentication in your organization requires the right data. We worked with our customers and built the tools they asked for to give them the insights they need. The changes we’re announcing today will give all of you even more data about legacy authentication usage in your organization, so you can turn it off systematically and get the full benefits of protecting your organization with MFA.


Step 1: Understanding legacy authentication usage in your organization

The first place to look when identifying legacy authentication usage in your organization is the Azure AD Sign-ins page, which is now available in the Azure portal to all tenants for 7 days. The sign-in logs provide a wealth of information, including user, application, client app, device—and now—user agent. Filtering by client app will let you identify sign-ins by modern and legacy authentication. Client apps, including Browser or Mobile Apps and Desktop clients, are considered modern authentication, while the others, such as IMAP, POP, and MAPI are considered legacy authentication. 




Larger customers will need to aggregate this data into a report or analyze the data using queries to fully understand patterns of legacy authentication usage. There are many ways to do this using Azure Monitor (with Azure AD Workbooks or Log Analytics), Excel, Microsoft Graph API, or a SIEM system.


Aggregating reports in Azure AD Workbooks and Log Analytics using Azure Monitor

We recommend streaming your sign-ins to Azure Monitor for real-time reporting and aggregation using Azure AD Workbooks and Log Analytics. Azure Monitor makes it easy to set the retention period and even set a daily cap on the amount of data stored.


Once your sign-ins are streaming to Azure Monitor, navigate to the Workbooks tab in Azure AD and open the new Sign-ins using Legacy Auth workbook. Here you will see information about which client apps are being used in your organization.




Using Kusto Query Language (KQL), you can write your own queries to create custom reports using Azure Log Analytics. In Azure AD, simply click Logs to begin writing your own queries.




Downloading sign-ins to Excel in JSON or CSV format

To download the sign-ins to JSON or CSV format, click on the Download button at the top of the Sign-ins page. If you filter the sign-ins by certain client apps, your download will be based on the filter selections you’ve made. We recommend downloading to JSON because this format includes all the sign-in details, including user agent. The CSV format will only show the top-level information in each row of the sign-in logs.




You can then open a JSON file in Excel using the Get Data function.



Using the Microsoft Graph API to get sign-ins

If you need to download more than 250,000 sign-in records, you can do so using the audit logs API in Microsoft Graph.


Step 2: Create Conditional Access policies in report-only mode

Once you’ve identified legacy authentication usage patterns in your organization, it’s time to start blocking legacy authentication. In most organizations, you can’t block legacy authentication for everyone right away. We recommend starting by blocking legacy authentication for only the group of users that don’t use it. As you make progress upgrading to modern authentication and disabling legacy authentication, you can expand the list of users in the group.


The easiest way to monitor the impact of blocking legacy authentication without disrupting users is using Conditional Access report-only mode. Policies in report-only mode are evaluated at sign-in, but the grant controls are not enforced, so you can see who is using legacy authentication in real time without blocking them. Start by creating a report-only policy that blocks legacy authentication for everyone in your organization. Remember that Conditional Access policies do not apply to legacy authentication clients by default, so you need to explicitly scope your policy to block client apps that are not Browser or Modern authentication clients (i.e. legacy authentication clients). Let the policy run for a few days to get the most accurate reflection of legacy authentication usage in your organization.




You can determine how many users will be blocked by the policy by using the new Conditional Access Insights workbook and selecting your policy in the Conditional Access policy filter. To access this workbook (after you have integrated your sign-in logs with Azure Monitor), navigate to the Workbook blade and select Conditional Access Insights. Clicking on a tile such as Failure will filter the dashboard by those users that would be blocked by the policy. Create an exclusion group and add any users for whom you are not quite ready to block legacy authentication.




Step 3: Blocking legacy authentication in your organization


Blocking legacy authentication using Azure AD Conditional Access

Once you have monitored your policy in report-only mode for a few days and you understand the impact of the policy, you’re ready to start blocking legacy authentication. The easiest approach is changing the state of the policy from Report-only to On. Alternatively, if you want to continue monitoring the impact of blocking legacy authentication in report-only mode for users that aren’t ready yet, you can create a separate Conditional Access policy that enforces blocking legacy authentication for the users that you identified in Step 2.


Blocking legacy authentication service-side

In addition to Conditional Access, you can also block legacy authentication service-side or resource-side (versus at the authentication platform). For example, in Exchange Online, you could disable POP3 or IMAP4 for the user. The problem with this is you do not want to block protocols that can do legacy and modern authentication (i.e. EWS, MAPI) as you may still need them. To help with this, Exchange Online released a feature called authentication policies, which you can use to block legacy authentication per protocol for specific users or for the entire organization. The protocol connection is denied before checking credentials against Azure AD or ADFS, so the enforcement is done pre-authentication.


Hopefully, this blog post has given you all the information you need to get started with blocking legacy authentication in your organization. For any questions, you can reply to this blog post in the comments below, send an email to our team (, or reach out to Alex (@alex_t_weinert) and me (@daniel_e_wood) on Twitter.





Senior Member

Hy @Alex Weinert  thanks for this Post. In my opinion one authentication type is missing in the aggregated report, its "Exchange Active Sync". Also in your Step1 picture the protocol is not filtered. Isn't it that EAS also used basic authentication and needs to be disabled by using Outlook App or for example Apples native iOS App > 11.0 which uses modern Authentication by oAuth 2.0 support.


Hi @Daniel Nitz, thanks for reading and I'm happy to address your comments to the blog post. 


The aggregated report shows all legacy auth protocols used, including Exchange ActiveSync, but a protocol does not get listed if there are no sign-ins of that type. Since there were no sign-ins using Exchange ActiveSync in the time range specified (14 days), Exchange ActiveSync does not appear in the Sign-ins using Legacy Auth workbook. 


The screenshot in Step 1 is filtered to include 14 client apps. You can see whether a filter is applied where it says Client app: 14 selected. 


As the blog mentions, there are two ways you can block legacy authentication. The first way is via Conditional Access, and the second way (which you mention in your comment) is to disable the protocol at the service level. 



Daniel Wood

Senior Member

Hi Daniel,


many thanks for your response!! I noticed that even if I have many Exchange Active Sync logons, this logon type does not come up. For example in a customer tenant I have following situation. 

I can see lot of sign ins using EAS




But the Report doesn't show the Active Sync Protocol.




The query shows me that Exchange Active Sync is filtered out




So a problem in the query?


Hi @Daniel Nitz--thanks for your observation. Indeed you are correct--we were inadvertently filtering out Exchange ActiveSync in the workbook query. That will be corrected soon. 

Occasional Visitor

In addition to this, the Microsoft documentation on setting up Conditional Access to block legacy authentication does not appear to consider ActiveSync a legacy authentication protocol:


Further, the instructions on that page for setting up the policy clearly exclude Exchange ActiveSync clients from the block.


Hi @mromp-bdo, thanks for your comment. We will update our guidance in the doc. Legacy Exchange ActiveSync will be deprecated in October as announced by the Exchange team earlier this year, so it should be blocked by organizations if possible. 

New Contributor

For conditional access, I'm attempting to setup a legacy authentication block. I do not have any option to set conditions. Is this a limitation of Azure P1? @danielwood95 





Hi there, what licensing skew do you have? Conditional Access requires Azure AD P1/EMS E3/M365 E3 licensing. If you are able to create a Conditional Access policy though, you should not be restricted in which conditions you can configure. The screenshot you've posted shows unexpected behavior, so I will follow up with you individually to get some more details. 

Occasional Contributor

Just curious if anyone has noticed this oddity.


We disable IMAP and POP on every mailbox within our tenant. We don't use MFA and are slowing transitioning away from legacy auth. In my report(s) I see numerous entries for authentication attempts from varying parts of the world using IMAP. I opened a support ticket with the (not so) fine folks at Azure Active Directory support and just wasted multiple days running in circles (language/comprehension disconnect). I learned merely a few hours ago, the support/ticket system is specific to "code red", "may day", "system down" triage and root cause type support and not "why does my report show me inaccurate information?" type support.


So, my question is this. If IMAP is disabled, why does my sign-ins report indicate someone from Brazil, Vietnam, etc., attempted to sign in to a licensed user's mailbox and failed due to the use of an "incorrect password"? The client app column indicates IMAP is/was used. That said, which is incorrect, the column or my concern (understanding) that IMAP isn't really disabled? Please note: Yes, IMAP is disabled on every mailbox. I am the only global admin for the tenant and I double-checked every mailbox in question before posting this.  :0)

New Contributor

@lance-aughey Hey I just had the same experience yesterday and finally figured it out (based on a few other websites).


Disabling the protocol/service is not the same as authentication. Yes you've disabled the IMAP protocol on the mailbox but you haven't blocked it at the authentication stage. To do this you need to use either CA or Authentication Policies (or both). Check out this MS Doc for Authentication Policies and blocking legacy auths.

You can apply it at the entire org level or to individual users.

Super Contributor

Hi @Alex Weinert   

Can you enlighten me? - why is the 'Common Data Service' listed as using Legacy Auth. under 'Insights and Reporting'  in CA? (I've created "Block Legacy Auth." and running this in Reporting mode)

Also in the 'Identity Protection' it's listed as Legacy Auth. Sign In?

Version history
Last update:
‎Jul 24 2020 01:18 AM
Updated by: