Legacy Auth and the risk

What’s the skinny?

Welcome back ContosoEDU world! We all know that the world for our digital accounts has changed drastically since the old days of Windows NT. With the ever growing reliance on cloud based services (SaaS being a huge one) we now more than ever need to focus on protecting our identities. Once of way to do just that is one that seems to have the most controversary, specially as we talk about students, and that way is MFA.

Now this post is not about MFA specifically, at least not this time, but something that should be done following MFA enablement or heck even before. Disable legacy authentication protocols! Why is this important? I’ve enabled MFA Nick! Well yes you did, hopefully, but legacy authentication protocols like POP, SMTP, IMAP, and MAPI can’t enforce MFA which makes them prime targets for adversaries.

So let’s take a quick example scenario: Martha from HR has MFA enabled as she is a high risk user due to her access to HBI data (remember HBI = High Business Impact) since she handles employee information. So the theory is that if her credentials become compromised via something like a phishing attack her account would be protected. In most cases, like 99% of the time, that is true! But since her organization still allows POP and IMAP to support 3rd party email clients the attack can now leverage these protocols to obtain copies of her email among other things they might try to do since they have an open window. Blocking legacy authentication helps to mitigate, nothing is ever 100%, these forms of attacks.

To help put some of this into perspective:

  • 99% of password spray attacks use legacy auth protocols
  • 97% of credential stuffing attacks use legacy auth protocols
  • Azure AD accounts in institutions that disable legacy auth protocols see roughly 67% fewer compromises than those with it still enabled

The above statistics are from Alex Weinert at Microsoft

So what can be done?

Azure AD with the help of conditional access can make disabling or blocking these protocols much easier and even helps IT get an understanding of who might actually even be using these! If no one is using these then just disable them completely and call it a day. But seriously the report is very helpful to help determine user impact and gives you the evidence you need to get approval prior to making any changes.

Now typically this is where I go and do a step by step to show you how to achieve this. However, Microsoft has this well documented so there is no use in re-creating what has already been done! You can read Microsoft’s documentation by going here. From there you will see: prerequisites, scenario description, implementation, policy deployment, what you should know, and any next steps.

Things to know

So since I’m not going to walk you through it I will simply point out a few things to note.

  1. Make sure you know and understand the basic concepts of Conditional Access (noted in the doc)
  2. Pay close attention to the protocols considered “legacy authentication” as you might be surprised by one or two. This is even more important as you plan for any accidental outages caused by your new conditional access policy (CAP).
  3. There are different ways to see what’s possibly using legacy authentication in your environment. One of which is noted in the doc shared above, direct link here, but another method is to use Azure AD Workbooks.
    • The first method is free. As in the reports are included in your A3 licensing but require a bit more “manual” work on your part to filter the data and/or export the data to JSON to edit in Excel. But at the end of the day you’ll have an idea of usage.
    • The second method does incur a charge since you will be using Azure Log Analytics/Azure Monitor. But the layout of the data is much nicer and makes assessing usage a lot easier. You can also leverage the conditional access policy you’ll create to block legacy auth in report only mode and leverage Azure Log Analytics to see that data.
  4. Be prepared for users to complain about app XYZ. This is most common for users of the Thunderbird mail client and/or Android OEM mail clients (not all support modern auth).
    • Unless you want to create an exception process (and where liability falls if they become compromised) it’s best to recommend they use any modern mail client. For the best experience Outlook for Windows, macOS, iOS, Android, and Outlook for the Web will always be the go to.
    • By the way if you haven’t used Outlook for the Web recently, you really should. In many cases I prefer it over the full Outlook client… just saying.
  5. TEST! Make sure you test out things as best you can as always.


So to summarize; legacy authentication protocols are bad. Modern authentication with MFA is good. With phishing attacks not slowing down this is a great way to help continue our push to mitigate compromised accounts while maintaining flexibility and productivity.