So – you have started testing “Require authentication strength”, as requested by Microsoft. But have you been receiving issue reports from partner organizations or guests who cannot switch to your tenant? Or maybe you are a Teams administrator that has been seeing reports that your users cannot Collaborate with a specific Organisation?
From the other perspective – you have started enforcing / recommending Passwordless Authentication, but your Users inform you that they can no longer work with some external Organisations. They sign in to their account using a FIDO2 Key / Windows Hello for Business as usual. But if you check the Sign-in logs after they fail to switch tenants, you just see error code 53003 – Blocked by Conditional Access.
In hindsight, the error message is actually quite helpful. Unfortunately, Single Sign-On (SSO) triggers first, and there’s no option to switch to a password-based login.
I consider myself a good storyteller, but I understand if you just want to skip to the solution.
Here’s a possible explanation.
My Troubleshooting Journey
Moving forward, I will use the proper terms "Home Tenant" for the Tenant the User with the issues originates from, and "Resource Tenant" for the tenant he is trying to access as a guest.
Since this is a cross-tenant issue, the first and often lengthiest step is getting a hold of the Admin of the Resource Tenant. In this case I was lucky to have a backchannel to contact them, so this was less painful than it might have been.
Once I was in contact with the tenant admin of the org my customer was having trouble with, we checked the conditional access settings, but I found nothing that would make me suspicious of an underlying configuration issue.
The Resource Tenant was using the default authentication strength “Multifactor authentication” for Guests, which includes most available authentication methods. Especially those that were in use in our case – Windows Hello for Business and Microsoft Authenticator.
When we viewed the sign-in logs in the Resource Tenant, we found the following:
Logins were failing
Despite the Authentication Details indicating Successful MFA
The Home Tenant obviously only contains very rudimentary information, since the Conditional Access evaluation happens in the Resource Tenant
Diving into the Documentation
Since nothing seemed obvious, I thoroughly reviewed all relevant Microsoft documentation and considered possible issues. At the same time, I opened a case to begin the usual process of gathering information with Microsoft support engineers.
To start with, I found a promising article on Requiring Authentication Strength for External Users. However, it didn’t mention any specific gotchas or issues that might arise with external users.
The article advises configuring MFA trust settings "as intended", but since we did not intend to trust any MFA claims, we moved on.
Another warning from the Article that I did not see applying: Since we aren’t using Email OTP, SAML/WS-FED, or Google authentication, we shouldn’t have to fallback to the "Require MFA" Grant Control.
Next, I followed the reference to Configuring cross-tenant access settings to trust mfa.
This page is also referenced an Admin Center Info Box when configuring Authentication Strengths in Conditional Access. The text is somewhat unclear to me, but now that I know the issue stems from an inability to complete first-factor authentication in the Resource Tenant, I can see the relevance.
This documentation only provides a vague description of how your tenant would accept MFA claims from a user’s home Entra tenant. I could already anticipate the discussions that would arise around the word "trust". I wasn’t eager to test this, especially since I couldn’t immediately answer questions like, "How far does this trust go?", "Can we still enforce authentication strengths?", or "Could errors in their tenant be used to bypass our MFA?"
Additionally, there is no mention of any limitations that might arise if this trust is not configured.
For Quick reference, my Answers would now be:
- "Claims provided by the Home Tenant are treated as equivalent to those your tenant would provide."
- "Cross-tenant trust means users signing in to your tenant won’t have to repeat authentication if they already meet your requirements, but your authentication strengths must still be fulfilled."
- "To some extent—accepting federated MFA is particularly risky in my opinion, as you’re not only trusting their Entra tenant but potentially an unknown third-party IDP."
Another reference from my starting point explaining how to create a policy to enforce authentication strengths: In the same documentation tree, there’s a dedicated Section for External Users, including an interesting table comparing the authentication methods available in a Home and Resource Tenant. However, since we can see the Authenticator prompt completing successfully in our case, there shouldn’t be an issue here either.
The documentation explicitly states that MFA trust is optional for B2B Collaboration
Unfortunately, the troubleshooting section also didn’t reveal any new insights or approaches.
Personally, I saw no reasonable source for the issues my users were having. The partner organization was hesitant to configure "MFA trust" because it implies a level of security exposure.
The support technician I worked with was adamant that the observed behavior and solution are clearly outlined in the documentation, so let me know where I’m being bone-headed.
The Solution
After troubleshooting, we reached a conclusion, but it felt suboptimal. In testing, The Resource Tenant admin and I had already concluded that we needed to trust MFA claims.
I couldn’t believe that B2B collaboration would depend on all organizations configuring tenant trust. We also had to wait for the change process to be approved, and I feared that since this wasn’t a change on our end, I might have to repeat the process with other organizations.
However, this is exactly what Microsoft Support confirmed: If you want to use Authentication Strengths for B2B users, you must configure External Access Settings – if you don’t want to massively inconvenience any organizations you’re working with that have already switched to passwordless authentication.
The situation was explained to me as follows: Without MFA Trust, the Resource Tenant will prompt users to complete second factor Authentication within the Resource Tenant. However, with Authentication Strengths, the validity of the password (first factor) isn’t asserted when using passwordless authentication methods – and there’s no mechanism to trigger the Home Tenant to do so. This results in a failed authentication.
Option 1: Keep Using Authentication Strength
To continue using authentication strengths, configure MFA Trust in the External Access Settings of the Entra Portal:
Alternatively, you can configure MFA Trust only for specific organizations you collaborate with or those affected by the issue. Whether you should set this as the default depends on how often you want to revisit the configuration and the number of organizations you collaborate with.
Especially in B2B collaboration, it might be prudent to create an authentication strength that excludes less secure methods, such as SMS or Federated MFA. However, this will depend on the authentication methods used by the organizations you work with. Use Report-Only Conditional Access Policies to evaluate changes before full deployment."
Option 2: Revert to "Require MFA" Control
This control is unaffected by the issues we’ve discussed. Although users will need to complete second-factor authentication in the Resource Tenant, it reliably works.
If you’re on the receiving end of this issue, send this article to the admins of the Resource Tenant. Until they adjust their settings, your users won’t be able to use Windows Hello for Business, and likely MacOS Platform Authentication and FIDO2 keys as well (although I haven’t tested these, logically they should be similarly affected). Users will need to log in with a password instead, allowing them to complete MFA in the Resource Tenant they’re trying to access. Unfortunately, there’s nothing you can do to resolve this on your end beyond asking the other organization to make the necessary changes.
You might think this is an oversight, especially since the Resource Tenant should immediately recognize that it won’t be able to complete the authentication.
…
Final Thoughts
I’ll be honest — I only fully grasped the solution after opening a Microsoft case, and it seems this issue is internally known. Looking back at the documentation in hindsight, it seems like the actual problem was somewhat obscured.
That’s why I wrote this article — to hopefully save someone else from going through the same trouble.
This episode also highlighted how widespread passwordless authentication really is. The organization with the "misconfiguration" had been collaborating with many others, and this was the first time the issue surfaced.
Hopefully, in the future, there will be a more robust solution, whether it’s a proper "proof-up" or an enhancement in authentication strength to better handle passwordless methods — without relying on cross-tenant access settings. At the very least, a clear error message or warning would be helpful. We’ll see.