Basic Authentication and Exchange Online – June 2021 Update
Published Jun 16 2021 01:08 PM 205K Views

Update: For latest information related to basic authentication in Exchange Online, please see Basic Authentication and Exchange Online – May 2022 Update.

It’s been a few months since our last update on Basic Authentication in Exchange Online, but we’ve been busy getting ready for the next phase of the process: turning off Basic Authentication for tenants that don’t use it, and therefore, don’t need it enabled.

We have millions of customers who have Basic Auth enabled in their tenant, but only use Modern Auth. Many of them don’t know Basic is enabled, and the risks that it presents – so we are going to do our bit to help secure their data by turning it off for them.

Over the last few months, we have been building the supporting process and tools we need to do that at scale, and now we’re ready to start rolling it out.

The Process

As we’ve said before, we’re only currently planning to turn off Basic Auth for those customers who are not using it. For customers that use still Basic for some or all the affected protocols*, we are not touching authentication settings for those protocols (for the time being).

(*as previously announced these are: Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), Remote PowerShell (RPS) , Outlook (EWS + MAPI, RPC, and OAB) and SMTP AUTH)

We have been busy analyzing Basic Auth usage data for our customers and now have a solid understanding of who uses it and who does not. And we’re going to start turning it off for those who are not using it.

The process is: We’ll randomly select customers with no usage in any, or all affected protocols, send them a Message Center post informing them that in 30 days we’re going to turn off Basic Auth. 30 days later, we’ll turn it off and send another Message Center post to confirm it was done. Customer protected... check!

We’ve already done this for a pilot set of tenants so we feel good about how this works, but before we scale up we wanted to build a tool to help our customers just in case we get it wrong. Why would we get it wrong? Well, very low usage is hard to detect if connections are rare, and some customers might even suddenly start using Basic auth. On that note….

You should know that we can’t really tell if Basic auth usage is legitimate usage, or an account that has already been compromised – we just see this as someone logging in to the mailbox, and in this case will not disable the protocol. Now therefore is another great moment to plug the Azure AD Sign-In log, as it can help surface ‘unexpected’ usage.

What if we do not spot that new usage , and we disable Basic? What then? Well, that’s where a new tool we’ve been building comes in – a tool that provides self-service re-enablement.

We’ve built a new diagnostic into the Microsoft 365 admin center. You may have seen this before for things like EWS migration throttling, or you read this excellent recent post about it. These diagnostics have proven really popular with customers, so we simply built on that technology.

Self-Service Re-Enablement

If you want to re-enable a protocol that we have disabled for Basic Auth, or want to see what protocols we have disabled, open the Microsoft 365 admin center and click the small green ? symbol in the lower right hand corner of the screen.


Once you do that you enter the self-help system which, (in case you didn’t know) can use some very clever logic to help you find a solution to all kinds of problems. But if you want to get straight to the new Basic Auth self-help diagnostic simply enter the magic phrase “Diag: Enable Basic Auth in EXO” or you can click on the following button (will launch the diagnostics in Admin center for you):


(Don’t tell anyone, this is our little secret. Published on one of the most popular blogs we’ve ever had at Microsoft. Shhh.)

Once you do that, you’ll see a page very similar to this:


Once you click Run Tests, the tool will check your tenant settings to see if we have disabled Basic Auth for any protocols, and then display the results.

If we have not disabled Basic Auth for any protocols we’ll tell you just that. But assuming we have done something, you’ll see a list of protocols that are disabled. My tenant has the full set of protocols disabled as you can see from the following:


Now that’s great, you can see what we did, but the best thing is, you can also re-enable the protocols yourself (if you want to). You can simply select the protocol (or a group of protocols, in the case of Outlook), check the box to agree to the warning (you know turning Basic Auth back on is bad right?) and then click Update Settings:


If you want to re-enable another protocol (again – why would you do that…?) re-run the diag and you can do just that.

That’s it – that’s how you can re-enable a protocol if we turn it off as part of this larger security effort. This is the only way to re-enable 8 of the 9 protocols included in the scope of this effort. (Up until the point at which we start to disable Basic Auth for protocols which are in-use – we are still planning on doing that and will have news on that later this year)

Note: Self service re-enablement of Basic Auth does not currently work for GCC tenants. For GCC tenants, please open a ticket with our support team to re-enable Basic Auth.

The only protocol you cannot re-enable in this way is SMTP AUTH – that’s not a part of this diagnostic because there’s already a lot of diagnostic wizardry available to help you with SMTP AUTH, and you can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is set SmtpClientAuthenticationDisabled to $True for tenants, and you can just go right ahead and turn it back on (set to $False) if you subsequently decide you need and want to use it.

One other notable difference in behavior with SMTP AUTH compared to the others is that the switch for SMTP AUTH controls Basic and OAuth client submission, they are not individually switchable. You can still enforce the use of OAuth using Conditional Access, but it’s a little more involved than just on or off for Basic, you can read more about authenticated SMTP submission here.

So how are we controlling the use of Basic Auth for the other 8 protocols? Good question, so good in fact we added that to the list of other excellent questions you might have below.

Some Questions and Answers

Why do I need this diagnostic tool? Why can’t I just go look at the Authentication Policies in my tenant and disable/delete them if I do not want Basic disabled for any protocol?

Good question! We are not turning off Basic using Authentication Policies. Therefore, Authentication Policies setting has no effect on the way that we will disable (and you can re-enable) Basic Auth using this diagnostic.

I use Basic Auth still for <insert your device, third party app, home grown app, etc. here> and I do not want you to turn it off!!

As long as your app checks mail or does whatever it does pretty regularly, we’ll consider that ‘active usage’ and not touch the authentication settings for the protocol it uses for the time being.

How exactly is Microsoft turning Basic Auth on or off on a per-protocol level?

We’ve added a new org level parameter that can be set to turn Basic Auth on or off for individual protocols within a tenant. Admins can view the parameter (-BasicAuthBlockedApps) using Get-OrganizationConfig. It’s not something you can change, and the values we store in there aren’t very user friendly, but luckily Exchange Online knows how to read and enforce them. A value of Null there means we’ve not touched your tenant. A value other than Null means we have, and the diagnostic is the way to determine what is disabled there.

I just got the Message Center post but I know I have an app that still needs to use Basic Auth. Please do not turn it off, I don’t want to have to re-enable it.

We are looking to add ‘opt-out of Basic Auth disablement’ functionality to this diag quite soon so you can do just that. The idea is that once you get the Message Center post you can use the diag to say “please don’t disable basic auth for IMAP” for example. And we’ll respect that. However… we strongly encourage you to request an opt-out only for the protocols you know you need, and don’t just ask for them all. Leaving unused protocols enabled for Basic Auth is a huge security risk to your tenant and your data.

When is Microsoft going to start turning off Basic Auth for protocols that we are actively using?

As announced earlier this year we’ve paused that program for now, but it will be coming back, so make sure you keep an eye on the blog and the Message Center for that announcement and keep working to eliminate the need for Basic Auth in your environment!

The Exchange Team

Occasional Visitor

How does this jive with blocking Basic Auth with Authentication Policies (Set-AuthenticationPolicy) and blocking Basic Auth with Conditional Access Policies?

I have tenants that have already blocked Basic Auth with one of the above.

@mikerocode This is blocked an entirely different way as the blog says. And our way of doing it overrides all (sorry, the house always wins) other methods. We're also not looking to see what policies you might have, we're just looking at usage. So, if your usage is zero (perhaps because of your policies), we might go ahead and put this block in anyway. If you then were to remove your Auth Policies or CA polices, Basic will still be blocked. 


But aside from that, good job for already putting those blocks in. You win. 

Occasional Visitor

@Greg Taylor - EXCHANGE Makes sense and was actually the answer I was hoping for. Thanks for responding!


Thanks for the excellent post! I would just like to point out the following tiny typo in order to make this amazing post even more amazing!

Original: can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is Set- SmtpClientAuthenticationDisabled to $False for tenants...

Suggested: can already switch SMTP AUTH on and off yourself by using the Set-TransportConfig cmdlet. Because unlike the other 8, all we’re doing to disable Basic Auth for SMTP AUTH is set -SmtpClientAuthenticationDisabled to $False for tenants...


@The_Exchange_Team  @jettan - Thanks for providing an update to this touchy subject. Dare I ask whether there are any other improvements in the pipeline to help us identify and eliminate basic auth usage? In a large tenant, working with the sign in logs is still clunky. For example, the JSON export contains a lot of information that is lost when you import it into Excel. If the export is too large, the download of the JSON fails. Since the search result doesn't show how many entries will be downloaded, this turns into a hit and miss as to how many days can be included in one download to prevent a failed download.


The screenshots in one of the referenced pages shows a download limit of 250,000 records. In our tenant, this limit is 100,000. What can I do to do to get this increased?


Lastly, I usually struggle with double negatives, but doesn't -SmtpClientAuthenticationDisabled set to $False mean that you are enabling Basic Auth for SMTP AUTH for your tenant whereas the paragraph above states this is the cmdlet to disable it?


Occasional Visitor

How long does it take for the protocols to be enabled after running the diag tool?

What would happen if I were to retry enabling the protocol multiple times due to some error?


@jettan Thanks, fixed that!

@Kreera House Thanks - fixed the typo!

@Kreera House - good catch on the True/False switch - I too hate double negatives, and clearly they are too much for me sometimes. The 100 vs. 250k limit - let me look into that. Thanks for highlighting. 


@itzadeeb about an hour at the most. If you get an error trying to re-enable protocols and it doesn't sort itself out - open a support ticket. 



@Greg Taylor - EXCHANGE I'd like to second Kreera's comment about identifying basic auth users, specifically ActiveSync. It's very clunky and difficult to rationalize when you have 70k+ users with multiple devices.


It would be nice to get a report in the Message Center like MS has done in the past with other announcements.



Senior Member

Any ETA on removing Basic Authentication for the legacy Office 365 reporting services
Or on replacing it with something modern?

@Steven Johnson It's something we've been thinking about. If we were to send customized MC posts though they would only be able to tell you how many users are using Basic for each protocol, not the details of which users are using Basic. We don't have access to that kind of data (usernames). Would that still be useful? If you know which protocols have the most usage you could focus on those in the sign-in reports you have access to (which will show you the usernames). 


@dmbuk not yet, work in progress with no news to share at the moment. 

@Greg Taylor - EXCHANGE yes! That would be helpful. At minimum, we could compare with the numbers we're collecting via sign-in logs. Thanks for the reply!

@Steven Johnson great, ok. Let me think about that some more. It'll be the mother of all mail merges. 

Regular Visitor

I confirm there is an issue with numbers of rows returned raised by @Kreera House .

"The 100 vs. 250k limit - let me look into that."
In my case only Exchange Active Sync Sign-in end up with 100k and this covers only 2 days...

Regular Visitor

Update to my previous comment. Now it's clear. There is 'old experience' and 'new experience' at SignIns. In older interface it is written:
You can download up to 250,000 records. If you want to download more, use reporting APIs. Click here to learn more.
but in new experience, it's written:
You can download up to a maximum of 100,000 records per file (e.g. if you are downloading the interactive and non-interactive sign-ins files, you will get 100,000 rows for each file). If you want to download more, use our reporting APIs or export to a storage account, SIEM or Log Analytics through "Export Data Settings". Click here to learn more. 


@Slawomir_Lipski thanks for the follow up! That's correct - we generally recommend that customers use Azure Event Hubs, Azure Storage, or Azure Monitor to export and analyze large amounts of log data. 

Exporting sign-in logs data from Azure AD requires a premium license for your Azure AD tenant. You can use the following methods to export logs:

  • In general, we recommend customers prioritize data export to Azure Event Hubs, Azure Storage, or Azure Monitor. Those export pathways are all capable of handling the load even from customer tenants with hundreds of thousands of users. Stream Azure Active Directory logs to Azure Monitor logs | Microsoft Docs
  • Customers can also use Graph APIs to export sign in logs, but we recommend customers implement the recommended MS Graph paging logic to ensure they can pull all their logs. Access Azure AD logs with the Microsoft Graph API | Microsoft Docs
  • Customers can also download logs, but the amount of data in the sign in logs can cause browser timeouts for large customers. Currently, in browser downloads are limited to 100k events. 
New Contributor

Our organisation would gladly migrate it's email provisioning and mailbox management tools from using Basic Auth if we could get the OAuth2 method working effectively.  Our testing indicates that the remote PS we need to use is unworkable using the new connectivity method with certificate thumbprint owing to connection delays and possibly general slow response.  In many cases the connection delay for each action is up by an order of magnitude over basic auth.  This results in a terrible user experience and in most cases of complex / repeated actions, actual timeouts which break the processes.  We have heard (somewhere) that Graph API is being updated to have more  mailbox functionality added which will apparently work much better.  Hopefully when we see this it will allow functionality equivalent to PS get-mailbox, Get-MailboxStatistics, Get/Add/Remove-MailboxPermission etc? 


Does anyone have any indication of what the timeline is for either an improvement in connectivity speed for thumbprint connection or a  suitable extension to Graph API?

Occasional Visitor

We run the hybrid agent for onprem-to-o365. Is this something that is definitely going to affect us? 


@cball985 - no. It will affect any users whose mailboxes are in EXO, and who are using Basic Auth. The Agent itself doesn't use Basic Auth. 


@pmtelstra work in progress is all I can share at the moment. 


Any update on sync-modernmailpublicfolder.ps1 script?

Occasional Contributor

Very good article, thank you! What happens to Tennants that are recreated in the future? Is the Basic Auth. automatically disabled there? If so, can you still activate it?

@krishraja - it's being worked on. 

@JanMartenHohnroth first off, thanks! Secondly, good question. New tenants get created with Security Defaults enabled already today - but we are making a change so that new tenants will also have Basic Auth disabled too - that should start happening in the next few months. 


Occasional Visitor

How does this affect Infopath? I think it might be using Basic Auth but surely there must be loads of people using it?

Occasional Visitor

If we wanted to disable Basic Auth for each of the protocols one-at-a-time before MS takes the steps, is there a cohesive primer for doing so?   Thanks.

Frequent Visitor

OMG I had a ticket open with Microsoft for over a MONTH because I could not get basic authentication to work for a script I needed. Then they finally showed me this article.   You would think they would know about it, and you would think that the other online tools that you can use to disable/enable basic authentication should maybe mention "Oh by the way check this place also other wise your settings here don't matter".   </rant>



Senior Member

Be alert that MS may prematurely disable the iMap basic auth, but leave it showing as active for the tenancy and for the mailboxes involved.

There will be no notifications in Message Centre.

They may also do this over a weekend when noone around to fix or report.


You may think this is unlikely to occur because it would be highly unprofessional, even amateurish.  But here we are.

@MC_Cox we haven't done any such thing. If we proactively disable basic we post to your SHD (and we announced we would do this, and provided information on how to re-enable). If you think we have done something, DM me. 

To anyone coming here to post - make sure you check the latest blog. 

Occasional Visitor

Why would you go ahead and implement a change prior to the published date? This breaks a lot of things... You guys are a**hats...

@LR_Brown - What change? We said we'd turn off things that weren't being used, and we might turn things off and back on if they were being used. We've not done anything other than that. If you think we're not sticking to that, please do tell me. 

Regular Visitor

Hello @The_Exchange_Team 


As per the latest article published in May - 2022, There is no way to request an exception after October!  So, please let us know if the implementation of "opt-out of Basic Auth disablement" is still on the card? We have many legacy applications and some email clients that use POP3 / SMTP basic authentication method to connect. Currently, we have no plan to upgrade those apps due to some business process limitations.



Mithilesh Pandey 

@MKP12 - there has never been a way to opt out after October - that has always been very clear. The 'opt out' was only ever available for the proactive push we've been doing, prior to October, where we turned off things that were not in use. 


You need to get working and upgrade those apps prior to October 1st. 

Occasional Visitor

@Greg Taylor - EXCHANGE- IMAP was disabled on our tenant even though we were using it in conjunction with a 365 App Password for one of our (internally developed) applications to retrieve emails/attachments from my mailbox.  I don't personally have access to our 365 Admin for this tenant, but worked with one of our IT admins through the steps above and, used the Help Article tool to re-enable IMAP, but it's still not working.  My app is getting "xm001 NO LOGIN" when it attempts to establish the IMAP connection.


How long does it take for the Help Article tool to take effect after you've re-enabled IMAP?
(If it matters, our tenant is, maybe, a few 100 users.)


After October, what path/protocol/method are we supposed to use to facilitate this type of work flow?

Is there an 365 Exchange API, another protocol we can use in C#/.NET or something?  I haven't been able to find a clear answer on this yet.


Couple other things:

  • while I don't have 365 admin to this tenant, I am a MS Partner and have a fairly good understanding of 365 admin in general
  • things were working fine for 2+yrs prior to about 2:30AM EST today
  • my account has MFA enabled and using a 365 App Password to make the IMAP connection (we cycled the MFA and App Password today just to make sure something wasn't stuck there).
  • it's been about 35mins since we re-enabled IMAP in the Help Article tool




  • It took about 42mins for our tenant, but programmatic IMAP access w/ a 365 App Password seems to be working again for us. 
  • When possible, I'd still like any info you can provide that informs us what protocol/methodology we should be implementing now for when this IMAP access ultimately gets taken away in October.  Thanks again!
Regular Visitor

Thanks, @Greg Taylor - EXCHANGE for the reply. Is there any way to configure the MS Outlook email client to connect to POP3 MailBox using the modern auth / OAuth2 method? 



Mithilesh Pandey

@TseTed - App password == Basic Auth. Announcing OAuth 2.0 Client Credentials Flow support for POP and IMAP protocols in Exchange Online -... 

@MKP12 - No. If you want to keep using POP3, you need to use a 3P client, like Thunderbird. Maybe it's time to stop using POP......? If you have Outlook - use MAPI. 




It looks like POP3 has been disabled on all of our accounts despite them being very much active.


We do have a plan in place to move to OAuth2 before the deadline but we are not able to make that change just yet.


To say I am displeased is an understatement - we basically can't access our business emails for 48h. To make matters worse, this is the second time it has happened. It shouldn't be happening at all on accounts actively using POP3 connections.


Even worse, following the steps above for Self Service Re-enablement doesn't work (apparently) as the 'organization configuration is  dehydrated' and so the configuration cannot be modified.



@chilliboom - do you receive an error when you try to opt-out/re-enable using the self-help tool in MAC? If you opt-out we won't touch your tenant until Oct 1st. 


Hi Greg,


I'm following the instructions above to try the 'Self-Service Re-Enablement'.


When I do the search for Diag: Enable Basic Auth in EXO I get the confirmation of the problem:

Exchange Online POP3 Basic Auth Disabled
Incident # ‎EX402696‎
Users not configured to use Modern Authentication with the affected protocol may be unable to sign in.
However, when I then click on 'Run Tests' in the diagnostics section underneath, I don't get the option to re-enable any of the protocols - I just get this message instead:
These are the current Basic authentication settings:
The organization configuration is dehydrated. In the Microsoft datacenters, an organization configuration being dehydrated means that it has certain objects consolidated to save space. In this state, configuration cannot be modified. This can be changed by running the Enable-OrganizationCustomization cmdlet.
Note that you are only required to run the Enable-OrganizationCustomization cmdlet once in your Exchange Online organization. If you attempt to run the cmdlet again, you will get an error.

@chilliboom - thanks for that - I'll investigate. In the meantime, connect using PowerShell, run the command, and the self-help diagnostic will be available for you. Connect to Exchange Online PowerShell | Microsoft Docs

Occasional Visitor

@Greg Taylor - EXCHANGE 

Let me get this straight because the information is extremely convoluted and unclear.

  • I have my account set for modern authentication
  • I have a POP3 account which is receiving forward email from Gmail
  • I have to use POP3 because I need to reply back using the original email address using a SendGrid account for STMP forwarding
  • I cannot use an Exchange setup because I cannot control the SMTP (email DMARC and other such rules will cause the email to be block)
  • And I thought I just read somewhere that Outlook for Windows DOES NOT have modern authentication ability for POP3. Do I have that correct? And if so WTF?

I too have been knocked offline for 48 hours and am struggling with this second outage. Am I correct in thinking I am going to be dead in the water come October? I have multiple email accounts and Outlook is one of the only ways to manage multiple accounts at the same time especially if they come from different sources (ie. Gmail, Outlook 365, etc.) Whoever thought web mail (Google!) was the be all and end all, is brain dead. It is great if you have one account, but those nitwits don't understand that with the browser, if you log in you and cannot log in with a second account because of the cookie handling. It screws up and you can only view one account at a time. Long story short, those guys at Google with all there friggen PhDs are pretty stupid.


Am it screwed here by this?

@codesmithery - others here may have some advice on this too - but why not use MAPI for the Exchange account, and configure Outlook to connect directly to Gmail for POP3 rather than forward it? Maybe that's not possible, I don't know. But you are correct, Outlook for Windows does not support POP3/OAuth to Exchange Online. You might also want to take a look at Thunderbird as a client. 

Occasional Visitor

Greg, thanks for the reply. I wish I could connect directly to Gmail, however the company I am consulting to won't allow that, hence this kludge approach.


So, then what is the point of using Outlook then? This makes no sense whatsoever. I switched over the other accounts I directly control to Exchange (I like the instantaneous receives but not the fact I can have a single inbox like with POP3).


And BTW, this has been communicated badly and I mean bad. There was no communication and what the ramifications are. There is absolutely no communication that you will loose Outlook for Windows support in October. Only it is being trumpeted to turn on modern authentication.


And to rub salt into the wound, your communications are late. I got a Admin notification this morning that POP3 was being disable to two days. It is the 23rd AND it said starting the 20th. You guys can do better than that or did you steal the playbook from Google on how to PO the customers off that they will switch to someone else?


@Greg Taylor - EXCHANGEI've not been able to connect via Powershell over the weekend. I wasn't too worried though as this block was only supposed to last for 48h.


However, it is now way past 48h and I am still blocked from downloading via POP3.

Senior Member

I see you've removed the Run Tests button.  While I agree with you, my customer's vendor won't have an XOAuth2 solution for another two months, so I need to re-enable Basic Auth for now.  What's the current correct procedure?

@chilliboom  - PowerShell and POP are un-related... All up advice, is to check Service Health Dashboard and Message Center if you want to see what has been disabled. 

@dontneedausername - We haven't removed the Run Tests button (you mean to run the diag?) - are you sure you're using the right trigger phrase? 

Senior Member

@Greg Taylor - EXCHANGE I was signed in as a delegated administrator, so that option wasn't available.  I signed in as a global administrator and it was there.  I guess the button is not available to partners.

Occasional Visitor

Be Aware!      Our Message center didn't notify us of IMAP disablement
Just because the notice states you can Opt Out or they won't disable IF you are using the specified protocol - they will and did to us
And the option to Out-Out isn't visible to Exchange Admins  - guess i can try with GA

Occasional Visitor



is the option to re-enable basic authentication for certain protocols disabled? I only get the option to opt-out, but all the protocols are already disabled. I neew EWS to be enabled for a short time, but the re-enable option isn't there anymore, only the opt-out option.

Do I need to use another seach phrase?

@Toedels - we've not turned anything off for weeks now - EWS has been off for weeks, why do you need it back on? You'll have to open a support ticket to get it turned back on. 


You know this a very old blog? Make sure you have read the latest - Basic Authentication Deprecation in Exchange Online – September 2022 Update - Microsoft Tech Communi...

Version history
Last update:
‎Jun 20 2022 07:05 AM