This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(310.4, 17%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPV%3C/text%3E%3C/svg%3E)
Hello,
We use MFA in our tenant and it works good for certain identities like ExternalAzureAd.
But with MicrosoftAccount for example, it's not working.
We have the Authentication strengths like : Password + Microsoft Authenticator (Push Notification)
In the sign in Logs we can see : Require Authentication strength - : The user could satisfy this authentication strength by registering for one or more MFA methods.
Would you have any leads ?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 71%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EF%3C/text%3E%3C/svg%3E)
Hello,
I have the exact issue, ExternalAzureAd works but users with MicrosoftAccount or mail just fail, the login gets denied. Have you found a solution?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 73%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
Hi FlorianDietrich-6737, Testing conducted about a month ago revealed that authentication strength still does not function with Microsoft Accounts (MSAs). However, foreign Entra ID accounts do support authentication strengths. Ultimately, both account types present themselves (by default) to the tenant as B2B guests forcing the use Multifactor.
Does anyone know of a proven (not theoretical) approach or method for targeting the following Foreign B2B guest types:
Thank you!
Hello @Princess Victoria Rosenthal , enabling MFA for external or guest users should prompt for MFA when using a personal account. In case MFA is not enable or has been skipped you will see "Single-factor authentication" under the Authentication requirement column in the affected user sign-in logs. For more information on why MFA is not being enforced under Conditional Access take a look to the Conditional Access column/details of the aforementioned logs. Additionaly, to get the most out of the sign-in logs take a look to Use the sign-ins report to review Azure AD Multi-Factor Authentication events.
For more information about setting up MFA take a look to Overview of Azure AD Multi-Factor Authentication for your organization, Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication, and Features and licenses for Azure AD Multi-Factor Authentication.
Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.
We have the exact same problem. All users except MicrosoftAccount type fail to authenticate on "Require Authentication Strength" - standard "Multifactor Authentication".
We have enabled the Inbound settings to trust External Azure Tenants. We have Microsoft Accounts in "External Identity Providers".
I have tested this with my own personal Microsoft Account that has Microsoft Authenticator and Yubikey with Passwordless ON.
All other B2B Azure tenants are fine and are able to authenticate.
The users is prompted for MFA. Provides correct credentials. Gets:
You can't get there from here
An authentication policy cannot be fulfilled. Please contact your administrator.
In my Sign-In logs I see:
Authentication requirement
Multifactor authentication
Status
Failure
Continuous access evaluation
No
Original transfer method
None
Sign-in error code
53003
Failure reason
Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.
Additional Details
If this is unexpected, see the conditional access policy that applied to this request in the Azure Portal.
Account is marked as:
User type
Guest
Cross tenant access type
B2B collaboration
Resource
Windows Azure Active Directory
And failure reason is:
Grant Controls Not satisfied
Require Authentication strength - Passwordless MFA: The user could not satisfy this authentication strength because they were not allowed to use any authentication methods which satisfied the authentication strength.
@Alfredo Revilla - Upwork Top Talent | IAM SWE SWA
Hopefully you saw the last thread from @Gediminas Margis above. Mentioned above, we too continue to experience a significant behavior difference between Microsoft Entra ID and Microsoft consumer (MSA) accounts.
Within my Entra tenant, Trust multifactor authentication from Microsoft Entra tenants for inbound cross-tenant access (defaults) is enabled (checked). Enabling this tenant option changes tenant functionality in the following ways:
We see the following behavior difference between:
As a side note: enabling Trust multifactor authentication from Microsoft Entra tenants is a misnomer. This trusts both Entra tenants and Microsoft consumer. Are there future plans to allow MSA accounts to begin utilize CA Policy Authentication Strengths? Thank You Shawn MayCurrently, you can only apply authentication strength policies to external users who authenticate with Microsoft Entra ID. For email one-time passcode, SAML/WS-Fed, and Google federation users, use the MFA grant control to require MFA.
Hello @gediminasmargis, hello @shawnmmay-9254. Sorry to hear about that, please post your issue as a new thread and mention me. I will take it ASAP.
Hello Shwan, althought all errors ay be related, the one you and Gediminas report (The user could not satisfy this authentication strength because they were not allowed to use any authentication methods which satisfied the authentication strength) do not seem to be the same as the one reported by the original poster (The user could not satisfy this authentication strength by registering for one or more MFA methods). Also, and for the sake of clarity and readibility is that I recommend creating a new post instead of extending this one. In the meantime please share the Authentication used or its settings (in case of custom) and the CA policy settings.
@Alfredo Revilla - Upwork Top Talent | IAM SWE SWA Here is what I've come up with as a decision tree. Please let me know your thoughts on the accuracy of this.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(140.8, 69%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
What are the benefits and pitfalls of choosing the Home vs Resource tenant for token issuance? We were reviewing the org level Inbound Access Trust Settings, specifically the "Trust multifactor authentication from Microsoft Entra tenants" and wondered what the tradeoffs here would be.
Small Correction on available AuthN types.