Basic Auth and Exchange Online – February 2020 Update
Published Feb 25 2020 07:00 AM 328K Views

Update: The full timeline for retirement of Basic Authentication in Exchange Online is now published in Basic Authentication Deprecation in Exchange Online – September 2022 Update.

It’s been a few months since we announced changes we will be making to Exchange Online to improve security.

We’re pleased to provide an update today and to try and answer some of the questions we’ve received since that post. We do understand a change like this can be disruptive.

Azure AD Sign-In Report

The first piece of news is that the improved Azure Sign-In report which can help you understand Basic Auth usage in your tenant is available. We still have work to do on it, but we decided we’d rather get the word out now as we continue to work on it than wait until it’s all complete. The report has recently been extended to include data you’ll find helpful for identifying clients and apps still using Basic Auth, and we have more updates coming soon.
Take a look at a blog the Identity team posted that will help you use some of the more advanced features available within the report.

The report is part of the Azure Active Directory admin center, called Sign-ins. It’s typically available in the side menu under Azure Active Directory, and you can always search if you can’t find it.

On this overview page you’ll see the sign-in activity in your tenant, dates, times, user IP address and so on. You can add columns, and we’d suggest you add Client app if it’s not already there.

Basic Auth Feb Update Pic 1.png

Now you can add a filter, Client app (then apply), and then a new dialog will allow you to pick the client app(s) to view. To view Basic Auth connections today you should select everything except Browser and Mobile Apps and Desktop Clients. When non-browser clients are using Modern Auth they will be placed into the Mobile Apps and Desktop Clients group.

If you have custom apps you’ll see them here, the screenshot below shows only the defaults provided. Basic Auth Feb Update Pic 2.png

 Once you have your filter in place, you’ll see only those connections that meet the filter criteria (i.e. using Basic Auth). If you click on any of the lines, you’ll see more information in the pane below.

Basic Auth Feb Update Pic 3.png

The User agent field can be handy for identifying app versions, if the app sends the string that is, many apps don’t (and User agents can be modified).

An easier way to view the data is to export it and use something like Excel to filter/group – as you likely will have a LOT of data. Today if you choose to download the report as a csv, the User agent data will be missing. But, if you download as JSON, and then convert it to csv so Excel can read it – the User agent string will be available. (We’re adding User agent to the CSV download dataset soon).

The simplest way to do this is to open a new Excel workbook, go to the Data menu, Get Data, From JSON – and import the file you downloaded from the Azure Sign-in report page.

Basic Auth Feb Update Pic 4.png


Excel analyzes the file and then opens the Power Query Editor. Each Record is an entry from the Sign-in Log report. If you select any item in that list you’ll see the details in the window below.

Click on Transform / To Table and accept the defaults of no delimiter and extra columns as errors, then click OK.

Basic Auth Feb Update Pic 5.png

 The last step is to click on the small double-headed arrow shown in the red circle below and uncheck Use original column name as prefix (shown in the blue circle below) – then click OK.

Basic Auth Feb Update Pic 6.png


Finally, Close & Load to turn that JSON into an Excel workbook you can use to filter and sort your connections and start to identify the changes you need to make.

Outlook and Basic Authentication

Switching to Outlook, we want to try and answer a few questions we received after our last post. We didn’t explicitly mention Outlook for Windows or for Mac in our previous post – and we’re sorry for any confusion that might have caused.

Both Outlook for Windows and for Mac are impacted by our turning off Basic Auth in Exchange Online. Both clients rely upon Exchange Web Services (EWS) and so if they are still using Basic Auth, they will be affected. Both clients need to be switched to use Modern Auth before October 2020.

The good news is that up to date versions of both of those clients fully support Modern Auth and have for several years. Outlook for Windows added support for Modern Auth with the release of Outlook 2013 (though it required a registry key to be enabled) and Outlook 2016 onwards have Modern Auth enabled by default. Outlook for Mac has supported Modern Auth since Outlook for Mac 2016.

So it’s very likely you are already using a Modern Auth capable version of Outlook. How can you tell if you are using Modern Auth?

The simplest way to tell when using the Windows version is the very different authentication dialog each use. On the left below is the classic Basic Auth dialog, on the right in the mini web-like page Modern Auth dialog:

Basic Auth Feb Update Pic 7a.png

There’s another way to check too (and again this is Outlook for Windows) hold CTRL and right click the Outlook tray icon, choose Connection Status and you’ll see all the connections Outlook has to Office 365. ‘Bearer*’ means Modern Auth – ‘Clear*’ means Basic Auth. As you can see from the image below, our test guinea pig’s corporate email is using Modern Auth – his personal email (also hosted in Exchange Online as you can tell from the Server name in use) is not. Oops.

Basic Auth Feb Update Pic 9.png


If you see Basic Auth being used by the client, it might be because Modern Auth is disabled in your tenant.

If your tenant was created before August 1, 2017, that’s most likely it (and that’s precisely why this member of the Exchange Team’s own O365 tenant is forcing him to connect with Basic – so he needs to fix that - sharpish).

So if you need to enable Modern Auth on your tenant, go read about that here. But before you just flip the switch, we do want to point out that this change affects your entire tenant. Just make sure you understand how such things as Conditional Access might impact the authentication flow. So be thoughtful, use the new report to see usage and when you are ready, make the change. Also, if your organization is in Hybrid, know that turning on Modern Auth on the tenant doesn’t impact your mailboxes on-premises. But you can enable Modern Auth there too. Read more about Hybrid Modern Authentication here.

How do you know if you are using Basic or Modern Auth with Outlook for Mac? You almost certainly are using Modern Auth – the number of connections we see using Basic is miniscule. If you are not, the Sign-in report would show it too.


The next piece of news we want to share is an update on the status of adding Modern Auth support to POP and IMAP for O365 commercial customers (we’ve had Modern Auth for IMAP in consumer for years).

We’ve completed our development work and are rolling out Modern Auth support for POP and IMAP in Exchange Online now. Documentation for developers is being finalized and we’ll link to it in this blog post when it is available.

Now if you are using POP or IMAP for your day to day email access, and if your current email client vendor has added support for Modern Auth, then great. But to be honest, using POP or IMAP for day to day access to your mailbox means you are really missing out. Even if you are using Outlook with those protocols you don’t get the complete calendar or contacts experience, and so switching to Outlook and using the default connectivity protocols, either for Windows/Mac, is going to make your use of email more functional and productive. And you might want to check out Outlook on the Web (OWA) – it’s changed enormously over the past few years and is a very capable and feature-filled client used by millions of people every day.

What if you are using POP and IMAP for various devices in your office? Chances are these devices are sending mail (things you have scanned for example) using SMTP email submission, so this change to POP and IMAP won’t impact them – but if you do have devices polling for mail, and the vendor has long gone or can’t update the devices to support Modern Auth for POP and IMAP, then we’re sorry… but they will hit issues.

It has to be said too that these devices are often a weak link in your security chain anyway. They have credentials stored on them, no-one ever changes the password – and if an attacker can get just one username and password in your tenant, they can see the entire tenant directory and from there go on to do far worse things.

What about 3rd party apps that integrate with your email, and use POP or IMAP to access a mailbox you have in Exchange Online? First port of call should be to speak to that vendor and ask what their plans are. As you might have seen, we’re not the only major cloud provider securing applications by removing Basic Auth, so if that application vendor wants to help their customers stay secure, they need to move to Modern Auth.

Finally, SMTP. We’re pleased to announce that we’re nearly done with the engineering work for Modern Auth for SMTP and hope we will soon be able to start the process of deploying that to the service. We’ll provide another update with some guidance on configuration and general usage as soon as we have it available.

PowerShell and Automation

PowerShell, scripts and automation – we are absolutely committed to supporting non-interactive scripts via Remote PowerShell using Certificate Based Authentication. We’re still working hard on the code, have some customers working on this with us already, and will have more to say on this in the next couple of months. Please be patient, we know many of you are desperate to get your hands on something that works, we’re working really hard to deliver that to you.

We do hope though that you are using the new PowerShell V2 Module already, and know all about Azure Cloud Shell which we provide details about here.

Exchange ActiveSync

Finally, we’ll address Exchange ActiveSync. As we have said previously, many up to date versions of mobile device email clients support Modern Auth already. Take a look at the usage report for your tenant and you’ll find the users on devices not using Modern Auth. The User Agent string will hopefully tell you the version of the device they are using. If they are using a device that should support Modern Auth, but isn’t using Modern Auth – users might need to reset or reconfigure their account.

As we said in the last post, we’re strongly recommending you switch to Outlook for iOS and Android in favor of the native apps. There are many security and business benefits over native apps when connecting to Exchange Online. We also just published details of a Total Economic Impact™ study Forrester which details the security, productivity and cost benefits a switch to Outlook mobile can provide. You can find that here


That pretty much sums up the update for now. We do plan on making updates more regularly now the report is available, and as we close in on October 2020. Look out for more information in due course.

The Exchange Team



Brass Contributor



great write up - but:

October 2020 is in about 7 months. You state about PowerShell Connections:

We’re still working hard on the code, have some customers working on this with us already, and will have more to say on this in the next couple of months

So another couple of months later you will disable basic auth and we still do not know how to prepare for our scripts. I work for a Microsoft Partner where we have hundreds of Orchestrator Scripts running for different customers all doing some magic which needs to be changed in order to make a Remote PowerShell Connection. Hopefully you will have to say more about this topic NEXT month and not in a couple of months.

Steel Contributor

The elephant in the room here is that disabling Basic Authentication for Exchange ActiveSync will break almost every Android phone connecting to Office 365 that is using the native Mail app - with the exception of Samsung devices, which support modern authentication.

'Finally, we’ll address Exchange ActiveSync. As we have said previously, many up to date versions of mobile device email clients support Modern Auth already. Take a look at the usage report for your tenant and you’ll find the users on devices not using Modern Auth. The User Agent string will hopefully tell you the version of the device they are using.'

Switching to Outlook won't be a popular answer (but to be honest, this is really Google's fault, not Microsoft's).

Brass Contributor

Great Article w/ Perfect Timing ... ! Looking forward to the RPS automation to be covered.

Iron Contributor
Hi @Gregg Taylor and team. Thanks for this updated post. It’s great to see the availability of basic auth reporting and some progress on the IMAP and POP modern Auth support. I have a few questions. We’re seeing quite a lot of Outlook for Windows and Outlook for Mac users in our Basic Auth reports even though our EXO tenant is configured for modern auth and we have the registry keys in our GPOs to ensure modern auth is used. It’s good to know from the above how we can check whether Outlook client is using modern auth... but what do we do to fix these Outlook users? On the Windows side it’s mostly Office 2013 users... but how do we fix them? On the Mac side the majority of users are on the latest monthly release of Outlook 365 ProPlus and yet some of them (300+) are still using Basic Auth according to reporting. What actions can we take to fix them since they should already be using modern Auth? With regards to Remote PowerShell, we’ve been told our Microsoft contact that using the new V2 version of the EXO PowerShell Module should be sufficient to ensure that we’re using modern Auth. We’ve updated all our automation scripts to use the new V2 module and as far as I can tell, based on the sign-in logs, modern Auth is being used. So why the comments in the above post about waiting for a few more months for cert based Auth in Remote PowerShell?

@ChrisAtMaf  Gmail app on Android phones supports modern auth/Oauth for ActiveSync since mid-2019 have you tested that recently?

@stukey glad the post has helped. 

For both Win and Mac Outlook - if the client app is showing as Mobile Apps and Desktop Clients - then they are using Modern Auth. What do they show as? If you are sure they appear to be using Basic then take a look at one of those Outlook 2013 clients, check the connection status dialog box - if it shows Clear* then make sure the EnableADAL key is present and set to 1. For the Mac clients, it's a pref setting, I'll need to check on that. 


PowerShell - yes, if you are using the v2 module you are using MA - the problem we need to solve still is non-interactive scripts, scripts that run when an admin is not at the console. That's what we need to deliver. 

Copper Contributor

Thanks for the write up. It explains why I've seen different results over the last few days as i've been looking at these logs already for some time.


One question I have is concerning Skype for Business ( We are moving to Teams but that's still some way out).

I still see the Skype client (Lync.exe) coming up a lot in my logs. Is there a similar way to check how Skype is Authenticating? We have the tenant side enabled for Modern Auth. and we use the most recent version of the client.  How can we ensure/check it's using Modern Authentication?





Iron Contributor
We see the same as @RalfHermsen. Skype for Business clients in our logs using basic auth. We too have modern auth enabled at the tenant level and are using the latest version of Skype from Office 365 ProPlus.
Steel Contributor

@RalfHermsen @stukey Do you have Modern Authentication enabled for Skype for Business? It is disabled by defaults on all tenants created before August 1, 2017 and is enabled separately to Exchange Online:



Iron Contributor
@greg Taylor Re: Remote PowerShell. I was also referring to non-interactive scripts. We’re using the V2 EXO module in all our non-interactive PowerShell automation scripts. We were advised by our Microsoft contact “Certificate Based Authentication is only applicable for scenarios where tenant has enforced MFA on all the accounts or if they have not invested in a secure password manager solution and would like to go for a solution where credential store is not required. Since your org has already invested in [removed] password manager, you can use Modern Auth to run automation scripts using Service Account with V2 EXO module.” Based on the sign-in logs, it appears that our Service Account that runs all of our automation PowerShell scripts is now using Modern Auth for all connections to EXO as the client app is showing as “Mobile Apps and Desktop clients” in the report. So am still confused as to why the above blog post states we need to wait another few months for the cert-based auth solution for automation/non-interactive requirements. Can you clarify? Re: Office for Windows and Mac. My comments were based on a previous manual report our Microsoft TAM provided, not on the Azure AD sign-in logs. In those logs we simply see the client app as “MAPI OVER HTTP” and the user string shows as “Microsoft office 15/Outlook 15.0.5172” as an example. Another example from Mac is client app as “autodiscover” and user string as “MacOutlook/”. We’re also seeing the same in the reports for Mac Outlook but with client app as “REST”. We have not yet had the chance to check the actual workstations of the impacted users. But we have 100s of users in these categories. We have the EnableADAL reg key set on all workstations using GPOs. If you can clarify the pref setting required on MacOS, I can ask our Mac team to check. Couple of other issues we’ve observed from a first look at the sign-in logs. The date column isn’t included in the downloadable reports which is very annoying because you can’t correlate the activity with a specific date/time. The only date provided is the date the report was created/downloaded, not the date of the sign-in activity itself. And the 250,000 record download limit is way too low for our tenant. If we want to download a report for all Basic Auth use across all protocols for one month, we immediately exceed the record limit. Even for 7 days we exceed the limit. Which means manually exporting smaller logs either on a per protocol basis or weekly or even daily, which is a lot of manual work!
Copper Contributor


Yes it is enabled;

ClientAdalAuthOverride : Allowed


On the client side we use the latest Office version (O365). any option to actually check what the Skype client is actually using would be very helpfull.


Copper Contributor


I agree on the logging. You can ingest the logs into a SIEM solution or Azure monitor from the Microsoft Graph and build history that way. I dont have the articles at hand but will post them tonight how you can set that up.


We've been ingesting the JSON logs and building history that way as well as the Sign In log limitations for large tenants can be quite cumbersome

Steel Contributor

@RalfHermsen @stukey OK - we also found setting the following DWORD to 1 can help with already-logged-in Skype for Business switching over to modern-authentication:


HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync\ AllowAdalForNonLyncIndependentOfLync

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Lync\ AllowAdalForNonLyncIndependentOfLync


We also found setting this DWORD to 1 helps in the same way for Exchange Online, just in case:



Iron Contributor
Thanks @RalfHermsen. I will check with our SIEM team. @greg Taylor - Also ignite my comment about the date in the downloadable sign-in logs. The test report I downloaded only had the date for today, 26th Feb, so I assumed that was an issue. Turns out it was because it only exported data for today, and the stopped due to the 250,000 record limit.
Copper Contributor

@ChrisAtMaf That article is a very nice find. It mentions options to force Modern Auth. Especially for skype when connection to Exchange. 


Thanks! and will get back with results during the week




After a second look at the article it's mainly related to a situation after migrating from on prem to O365. Thats not the case for us but it does give me some additional points to investigate on the affected clients

Brass Contributor

The article insinuates that everything except "Mobile Apps and Desktop Clients" is using basic authentication but "Browser" should be excluded as well IMHO as not all "Browser" sign-ins are basic authentication.

Copper Contributor

Thanks! Great article.  I may have missed it in this and other articles... I see a lot of information about what breaks and what the prerequisites are when you enable Modern Auth and what breaks and what the prerequisites are when you disable Basic Auth. 


Obviously if you do not have Modern Auth enabled you are using Basic Auth, but if I simply enable Modern Auth will I break anything?  I assume that clients using Basic Auth will continue to do so and clients that can use Modern Auth will start to do so. From there I can run the report mentioned above and see what is still using Basic Auth to pinpoint what I need to go after and "fix".  We have had a lot of discussion internally about what will happen when we enable Modern Auth in our Hybrid environment.  Do we "have to" enable Modern Auth on-premise and the same time as in the tenant?  Will we break anything if we don't or will Basic Auth carry us through and continue to work for those that need it?  


I hope I'm not the only person feeling the stress of moving forward for fear of breaking something.  We are not ready to flip a switch and move from Basic to Modern Auth.  But I'm thinking there has to be a way to transition smoothly.  I just have not seen much talk about doing that.  But like I said at the beginning... I may have missed it.

Steel Contributor

Will app password be affected?  For example, a user creates an app password to allow Gmail to pull their data. 

Brass Contributor

For ActiveSync user agent, is there a minimum version number we should be looking for that supports modern auth?

@stukey portal has its limits - main one is 250k entries. either filter first then export or use SIEM/log analytics. this note has some good pointers WRT discovering legacy auth: 


@ph_ly - yes. app passwords will be affected/blocked.


@Glenn Van Rymenant - there is no flow in a browser that uses basic auth.

Brass Contributor

@Daniel Stefaniakfigured as much, thanks for confirming, should be updated in the article.

@Kevin Fletcher - We feel you, don't worry. A switch like this can be nerve-racking. I was there the day we switched our own on-prem forest to Hybrid Modern Auth, and had missed registering an SPN so all hell broke loose. But, that's how you learn not to do that. You do not need to enable Modern Auth on-prem (what we refer to as Hybrid Modern Auth typically) to enable it in EXO. You can leave that using whatever it does today. There are benefits to enabling HMA on-prem, but that can wait for another day. Plan it for a period of low usage, communicate the change, and try it. You can always roll back. 


@JasonSCarter - not really, it's not an EAS protocol thing, it's a client implementation thing. 


@Glenn Van Rymenant - it's confirmed right here in the comments. :smile:


@stukey (and others) - the 250k limit - 

There is a Graph API to download sign-in logs, but the admin will need an AADP premium license - the API limit is 1M records per call (and you could string many calls together).


@stukey - PowerShell scripts - you are correct (and the PM we both know and I are discussing this), that using the PowerShell v2 module if you have a password manager/vault solution which your scripts can access would allow you to run non-interactive scripts using OAuth. There are some scenarios that this won't work for (or if you don't have a vault solution), so for that we're working on the CBA route. 


Copper Contributor

We are using the free version of Azure Active Directory (the one that comes with the subscription). Unfortunately I cannot see the report since the Sign-ins module needs a license. Is there another way that I can see what is using basic authentication ?





Brass Contributor

@Greg Taylor - EXCHANGE 


If our up to date version of Outlook is still connecting via basic (clear) and we flip the switch to modern org wide, will Outlook "heal" the connection and flip to Modern? Will users be prompted to re-authenticate using Modern? Or will Outlook profiles need to be rebuilt?

Copper Contributor

I have the same question as @Michael Rennie 

Brass Contributor

We've been using Log Analytics/Sentinel to generate legacy auth reports, then fronting that with PowerBI so our field staff and slice and dice the data for their support areas. I posted them here:




Copper Contributor
Where can I find the Forrester report?
@Marcocho - that is what we are expecting to change any day now; the Azure team is working to get this particular report available to all tenants (so it does not require a P1 or P2 Azure subscription). Please keep checking back daily, it should not be too long now.
Copper Contributor

@Nino Bilic , when you say to check back daily, are you talking about this blog or the message center in the Office Portal ?



@Marcocho - sorry I was not specific enough... The new report should light up on the following URL: (or you can get to it by browsing to the Azure portal). That report right there, should stop showing the error that you need Azure P1 or P2 to access it, and simply start working. That is our expectation at this point; that it will simply become available, no additional announcement anywhere.

@Matthew PAHLS  - refresh the page, I just added a link now it has been published. 


@chrisbuesold  - nice job!


@Michael Rennie - Outlook usually won't switch until it is restarted - though if the network drops, it might come back and get a Modern Auth prompt. Best advice - restart Outlook and it should pick up the change. No need to rebuild profiles. 

Iron Contributor
@Greg Taylor - EXCHANGE Re: PowerShell. Thanks for the updates! Good news on the PowerShell front and thanks for confirming what we’re doing should work... Can you go into more detail about the non-interactive scenarios that won’t work with the EXO V2 PowerShell module? Re: Outlook clients that are still reporting in as using Basic Auth even though all the reg key settings are in place to enable/force modern auth. What can we do to fix/remediate them? Also do you have details of the pref setting for Outlook for Mac?
@Michael Rennie and @Marcocho - as @Greg Taylor - EXCHANGE said. I just tested this whole thing for myself also (in my tenant). Had a profile with Basic auth latest Outlook and then enabled Modern auth on the tenant. Restarted the Outlook client in a few minutes, and Outlook simply logged in, but then I saw auth listed as Bearer. Zero issues. But be mindful that this is a tenant level switch (as mentioned in the blog post). By setting it, you are not actually disabling Basic auth, you are just enabling the tenant for modern auth for Outlook desktop clients.

@stukey - we plan to do a post with more details on PowerShell in the next week or two with luck, so let's save it for then. 


If Outlook Windows clients are still using Basic I'd crack out Fiddler and check out what's really going on. We have a Fiddler add-in for EXO that will help. 


For Mac - It’s posted on MacAdmins (under “Preferences” tab):


Brass Contributor

We use Office 365 MDM (not Intune) to manage our mobile devices The profile that gets pushed down to the devices seems to only support basic auth (we use app passwords). When is this going to be updated to push down a profile that supports modern auth? 

Brass Contributor

I appreciate this is a very specific question, but do you know if the latest Thunderbird client will support Modern Auth?  I think Thunderbird supports OAuth2.0.

We have many Linux developers who use Thunderbird (IMAP).  

Copper Contributor

I understand making authentication more secure is the way forwards but you need to give customer the option for each client being used.  in out case we are using a much more secure and polished MDM solution for our mobile devices which are using basic authentication currently and im unsure if they will be making the required changes before Oct20 - good product - poor support.   

Steel Contributor

@Daniel Stefaniak Thanks for that - is there an official Google announcement on this?

Brass Contributor

For Lync.exe - are you saying we need to set registry keys to force modern auth or will eventually the person will be signed out and then when they re-logon they would use modern auth.      We just enable modern auth on Skype for business.      We thought over time this would correct itself. 





 @The_Exchange_Team : As for ActiveSync in the sign-in report, does it mean that ActiveSync clients using ModernAuth will fall under "Mobile apps and Desktop clients" and we can safely assume anything under the "ActiveSync" filter is using Basic Auth?
ClientApp Filter.png
Is there anything else in the sign in details that would indicate it is basic auth? Authentication Details perhaps?

Another question: Does the Sign-ins report show the first pre-authentication step (Step 1 in the diagram)? Assuming the user doesn't have an Exchange Authentication policy assigned to them?


Copper Contributor

DPM2019/SCOM2019 doesn't seem to allow us to use Modern Auth for sending logs via SMTP so we configured an internal SMTP relay that allows us to receive logs/alerts by email via our EXO.

Does that mean this solution will stop working ?

I'm asking that because the report shows the account and IP used by the SMTP relay and you understand we need to receive SCOM and DPM logs. So either there's a way to keep using that or there's a better way (any suggestions ?).



Copper Contributor

I've tried to export via JSON unsuccessfully a couple times now. I keep receiving this error:


File download error
Given data uri is not formatted correctly with data uri syntax


I've successfully downloaded multiple CSV files. Anyone else getting a similar error with JSON?

Steel Contributor

@Daniel Stefaniak Gmail does not work from what I can tell. My account with basic Auth already blocked per current MFA recommendations fails.  You can authenticate and then it errors out on the last screen.  From what I read, Gmail supports oath but not Microsoft's specific implementation.  

Iron Contributor

Thanks for the very informative update.


Can you confirm whether Samsung Native Android Mail Client v6.1.11.6 supports Modern Auth and how to force it to use it instead of an App Password.


Thanks much,

Copper Contributor

Thanks for the reply @Greg Taylor - EXCHANGE. It's good to know that we can leave on-prem alone for now.  

You mention enabling for EXO.  What about SfB Online?  All of our Skype users are online but we do have some SfB servers on-prem due to the way we use SecureAuth for authentication.  If we enable modern auth for SfB Online (and not on-prem) will it cause issues.  

Sorry.  I don't mean to try to put you on the spot.  I'm thinking we just enable EXO first and see how things go.

Steel Contributor

@Steven Seligman On my phone, I choose the Office 365 option when adding the account, and am successfully able to to pull email after accepting the O365 permissions as well as going through the separate Permissions activesync prompt.   If a user is running basic today they will have to delete and re-add to switch to modern, but I suspect it is automatic.


Another item not mentioned - you can force this future state on yourselves via conditional access policies for select groups immediately by blocking legacy authentication.  That way you can do a phased roll-out.

@ph_ly it does for me - I just did MFA and modern auth on Pixel phone in GMail app (required at least Adnroid O if not P - don't remember which one) 

@GregL - that team are investigating and working on that. 

@Paul Mitchell (there are 4, hope I got the right one) - That's really a question for them not us. But I believe they are working on it. 

@Matthew Levy - Yes - anything reported as 'ActiveSync' is using Basic. Auth policies block Basic at step 1 (if set to block Basic). If you don't have Auth Policies then the Sign-in report is showing events that happen at step 4. 

@cges-dd - No, this change won't affect SMTP. We are adding OAuth support to SMTP AUTH as we stated. Soon. 

@t-rev - I'll ping the Azure team

@Steven Seligman - I can't, but maybe someone here can. 

@Kevin Fletcher  - is the doc to read.  

Version history
Last update:
‎Sep 01 2022 08:10 AM
Updated by: