Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Visitor 1

Legacy Protocol

Hi, according to the documentation for CSP security requirement


all the legacy protocol IMAP, SMTP, POP3 are essentially "blocked", meaning we cannot use IMAP and App password? 

Many MSPs out there are using ConnectWise, Autotask etc. as ticketing system. Does that mean we have to use a different tenant or something?


Visitor 1

The document outlining the requirements says that the two baseline policies that are required to be compliant are 'Require MFA for Admin' and 'End user protection'. It doesn't state that the baseline policy 'Block legacy authentication' is required. This would indiciate that legacy protocol cans continue working even when the other two baseline policies are enabled. Is there something I'm missing that states otherwise?


I'm going based on the information found here: https://partner.microsoft.com/en-US/resources/collection/partner-security-requirements#/


The MFA for Admin and End User Protection also blocks legacy authentication, see e.g. https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-baseline-protect-end-users#legacy-protocols.

The baseline policy "block legacy authentication" is for a different use case - e.g. ensure only modern auth is used, but not requiring every user to go through MFA prompt. If you force MFA for all users using the now mandatory baseline policies for MFA it will also (automatically) block legacy auth.

Level 1 Contributor

I've been testing the End User Protection baseline policy, and contrary to what the docs say, it doesn't seem to be blocking legacy authentication. I expect that it will in the (near) future, but will open a support case just to be sure.


Currently the end user protection baseline policy does not trigger MFA for all access attempts, only those which are considered to be risky - this is why those legacy protocols still work. But these conditiions will change and affect user account in CSP tenants.


If you want to test this, set a custom conditional access rule where you enforce MFA for the respective user accounts (which you use for accessing services using legacy protocols).

Level 4 Contributor

@JanoschUlmer wrote:

Currently the end user protection baseline policy does not trigger MFA for all access attempts, only those which are considered to be risky - this is why those legacy protocols still work. But these conditiions will change and affect user account in CSP tenants.


If you want to test this, set a custom conditional access rule where you enforce MFA for the respective user accounts (which you use for accessing services using legacy protocols).

Partner Security Requirements


Do we need to block legacy apps for all users, even non-administrator service accounts?

Either I have missunderstood how the end user protection baseline policy works, or the article above is telling us to enable a baseline policy that only requires MFA for all users WHEN a risky sign-in event happens.


That doesn't sound like enforcing MFA for all users and blocking legacy protocols to me.



Yes, you need to enable MFA for all user accounts, even non-administrator accounts - and thus also for accounts used by services.


As mentioned, there will be changes to the end user protection baseline policy that affect CSP accounts specifically, details will be provided soon. So you have not misunderstood they way the baseline policy poilcy currently works 🙂 - currently it will only trigger MFA when a risk is detected, but this will change. Thus my recommendation to test with a custom conditional access rule that just enforces MFA to mimic the behavoir you will see later.

Level 1 Contributor

I have spent the last week trying to get answers for this, but so far not got anywhere. 


We can enable 2FA for all our accounts, but we like many other partners use a service desk that uses IMAP to check for tickets and SMTP to send out replies and notifications. So we need IMAP access to our help@ email address. 


From my interactions with Kaseya they have no knowlege of these requirements or any plans to implement any changes to their system, they just said if you can't use IMAP you wouldn't be able to use their product. I know that Connectwise also uses the same approach as do many other systems. 


Unless our software providers update their systems to use Exhange API and token authentication, then we have to use IMAP and you can't expect us all to swtich helpdesk systems after the 1st of August, or set up new 365 tenants with different domains and change our support email addresses. 


Can we not enable 2FA manually, create an app password for the service email address and then restrict that IMAP login with a policy to only be allowed from a certain IP address and lock it down to the service desk IP?

Level 4 Contributor

When MFA is setup on a per user basis, the app password works for imap /smtp. That does not mean it is considered in compliance and will continue working when the technical enforcement takes place in the future (when ever that happens, no ETA and all)
Level 1 Contributor



Hopefully the policy will just get updated to allow for restricted use of legacy protocols and save us all a huge headache. 


Either that or the technical enforcement will be delayed for long enough for vendors to make changes to their systems so that we can continue to use them. I doubt many will even know anything about these new requirements, but I'm sure once the knowlege gets out there and they learn that may have to lose any Microsoft partner customers because their helpdesk software is not compliant with their policies, then they will soon update their software.


Just hope for some clarity soon. We're just at then end of two month implementation of Kaseya BMS so would be a huge pain to change systems and do that again. 

Level 4 Contributor

Keep in mind, a domain can only exist in one tenant. We are talking about,
1) Forwarding the mail to a mailbox in another tenant (or an address managed by the help desk vendor)
2) moving all mail enabled objects for that domain to a different tenant
3) setting up and using a different domain in another tenant (support@mail.contoso.com)
4) using a solution that supports ews / modern authentication / secure app model.

Zendesk for example supports pop, imap and forwarding. Forwarding has some drawbacks and benefits. But it is an option, and real time ingestion over polling is definitely a pro.
Level 2 Contributor



I have not tried enabling MFA and setting up an app password because I have been trying to get confirmation from Microsoft on the compliance of that option first. As I mentioned, they have wavered between "Maybe" and "No". The following links are just to illustrate the confusion and to help serve as a reference for Microsoft on communication breakdown.









Partner Office Hours for Security Requirements: Option 5


Additionally, @JanoschUlmer has mentioned that MFA enforced through Conditional Access does not allow App Passwords (this appears to be true from my research). So they would need to confirm that either a per-user enabling of MFA would be allowed or App Password support would be brought to Conditional Access.

Level 3 Contributor

@TomR Yeah, i'm aware of the short comings of App Passwords and CA rules, totally understand. My intent would be to toggle enforced MFA on the service accounts, and put in App Passwords in place in Connect Wise. We're going to give this a whirl this week with some less used e-mail connectors in Connect Wise and i'll report back if it works.

Level 2 Contributor



I just wanted to circle back to the issue that started this thread as it is one that is shared by myself and many Managed Service Providers. We already have all of our admins and users (with the exception of service accounts) in O365/Azure AD using MFA through AAD Premium. We use Connectwise as our PSA and the email connector used to ingest emails into our ticketing system requires IMAP. We have raised the issue with Connectwise but cannot make them move any faster to meet your deadline so we are put in a position where there are three options:

1) Change our PSA (not happening in less than 3 weeks)

2) Migrate our production resources to another tenant

3) Raise awareness to Microsoft that the world isnt so black and white


I keep pulling for Option 3 as there has been this "Maybe we can work something out" sort of language used throughout these communications. It also seems reasonable enough that an email account with no extra roles/permissions and that is not even configured in our partner center should be capable of having an exclusion. The longer that we wait on you to give clear guidance, the less time that we have if we are forced to migrate to a new tenancy because of one email account.


I really do appreciate that Microsoft wants to be more proactive about security but the timetable and communication around this has been absolutely horrible. I really hope this can show you what your partners are up against when broad language like "all users" is used.

Level 3 Contributor

@TomR We're in the same boat Tom, 100% agree with all your points. Have you tried enforced MFA /w App Password generation? Microsoft still hasn't "confirmed" if this will be allowed, but I don't believe they explicitly said NO right off the bat? Maybe that will appease them? Have you tried this? I'm trying this week, not sure if it will even work?

Level 4 Contributor

Lot's of good information from JanoschUlmer in this thread



The article below goes into why the requirements are what they are ,which is always nice to understand. The article also talks about requiring MFA registration for all users, and only requiring MFA under certain conditions. 


What are baseline policies?


End user protection (preview)

High privileged administrators aren’t the only ones targeted in attacks. Bad actors tend to target normal users. After gaining access, these bad actors can request access to privileged information on behalf of the original account holder or download the entire directory and perform a phishing attack on your whole organization. One common method to improve the protection for all users is to require a stronger form of account verification when a risky sign-in is detected.


End user protection (preview) is a baseline policy that protects all users in a directory. Enabling this policy requires all users to register for Azure Multi-Factor Authentication within 14 days. Once registered, users will be prompted for MFA only during risky sign-in attempts. Compromised user accounts are blocked until password reset and risk dismissal.

Level 3 Contributor



Can you elaborate on what "But these conditions will change and affect user account in CSP tenants." means? We use Identity Protection to force MFA on Risk Based logins already, in addition to blocking users at High Risk, i'm curious what these "Changes" you speak of are in relation to risk based conditions?

You also don't state WHAT Risk Level the current End User Baseline policy hits on, Low+ or Medium+?

Level 4 Contributor

Janosch, I'm getting mixed messages from Microsoft on this topic. Do we need to enable those baseline policies or not?

During the community call yesterday, attendees were told that enabling the baseline policy is one way to be compliant, but we could also use AAD P1/P2 to and create more flexible (exceptions for certain accounts) policies that are also acceptable.


When will we be given a better understanding of what partners need to do to meet these requirements and know if will be compliant before the enforment date?


Edit: grammer


Sorry for the confusion and mixed answers, in my answer I was too much focussed on using the baseline policies as only option - currently trying to get more clarification and will update this thread asap.


You are correct that you don't need to enable the baseline policies if you use other methods for enforcing MFA, this is mentioned in the program guide. So this might open the option to use AAD premium features + app passwords - as said I want to double check.


The detailed & official contractual requirements are now published in the updated program guide: 




Level 3 Contributor

Is there any information around the requirments needed for compliance when you are using Azure P1. My tenant is using AZ P1 at this time and we want to know how to match the 14 day enrollment for users and also if there are any compliant exceptions that can be made for service accounts and SRS device accounts.


Hi @dferrell


The requirement is to have MFA enforce for each user, including service, accounts in your partner tenant. This can be accomplished through the impelementation of the baseline protection policies, Azure AD P1/2 license, or a third party solution. To my knowledge the only way to take advantage of the 14 day enrollment is through the use of the baseline policies. When you enforce MFA using an Azure AD P1, or P2, license then the next time the account is used for authentication it will have to go through the MFA enrollment process. 


It is my understanding that there will not be any exception for these security requirements. We are currently working with the Azure AD team to confirm that you can utilize app passwords for devices and systems that do not support modern authentication.