MFA with External Users in Entra ID: Why Inbound Trust Alone Is Not Enough

–> Auch auf deutsch verfügbar!

This article was translated from German with the help of Claude.

If you work with external users (guests) in Microsoft Entra ID, you probably know this problem: A guest tries to access a resource in your tenant, gets prompted for MFA, and fails. The error message is cryptic, the user is frustrated. What’s going on?

In this article, I explain why external users are often treated as Microsoft Accounts (MSA), why Inbound Trust Settings don’t work in that case, and what additional trap Authentication Strengths in Conditional Access Policies set.

The Problem: External Accounts Are Treated as Microsoft Accounts

#

When you invite an external user via B2B Collaboration into your tenant, they redeem the invitation (“Redemption”). Entra ID uses a Redemption Order to decide which identity provider is used. The default order is:

1. Microsoft Entra ID (if the guest has an Entra ID account in their home tenant)
2. External Federation (SAML/WS-Fed)
3. Microsoft Account (MSA) as fallback

The problem: If Entra ID cannot associate the guest with an Entra ID tenant, e.g. because the email domain is not linked to any Entra ID tenant, the guest is treated as an MSA account (Microsoft Account). And that’s where the trouble starts:

• Inbound Trust Settings only apply to Microsoft Entra Tenants, not to MSA accounts
• Your tenant cannot trust the MFA of an MSA account, even if you enabled “Trust multifactor authentication from Microsoft Entra tenants”
• The guest is prompted to register for MFA in your resource tenant, or access fails entirely

Solution Part 1: Disable MSA as Fallback

#

The first step is to ensure that external users don’t redeem their invitation as an MSA account. To do this, disable Microsoft Accounts as a fallback identity provider in the Cross-Tenant Access Settings.

How to do it

#

1. Sign in to the Microsoft Entra Admin Center (at least as Security Administrator)
2. Navigate to Entra ID → External Identities → Cross-tenant access settings
3. Select the Default settings tab and click Edit inbound defaults
4. Switch to the B2B collaboration → Redemption order tab
5. Under Fallback identity providers: Disable Microsoft service account (MSA)
6. Click Save

Note: Email One-Time Passcode (OTP) is enabled by default in all tenants and automatically takes over as fallback when MSA is disabled. Only if someone has explicitly disabled Email OTP does it need to be re-enabled under External Identities → All identity providers.

Important: Existing guest users who have already signed in with an MSA will continue to use it. You need to reset their redemption status for the new setting to take effect.

With this configuration, guests that cannot be associated with an Entra ID tenant will be authenticated via Email One-Time Passcode (OTP) instead of being treated as MSA.

Why Disable MSA?

#

Disabling MSA in the default settings is not just a workaround, but generally recommended for enterprise scenarios:

• MFA Trust does not apply to MSA: “Trust MFA from Microsoft Entra tenants” only applies to Entra ID tenants. As long as MSA is active as a fallback, some guests will fall into this gap.
• No organizational control: MSA are personal accounts (@outlook.com, @hotmail.com etc.). No admin manages them. You don’t know whether MFA is enabled, what password policies apply, or whether the account is compromised.
• Conditional Access works better: For MSA guests, CA Policies work differently than for Entra ID guests. You cannot trust Device Compliance or Hybrid Join claims, for example.
• Email OTP is the better fallback: A time-limited one-time code via email is more secure and predictable than an uncontrolled MSA login.

With MSA disabled, you have two clean paths: Entra ID (with trust) or Email OTP (no trust, but controlled). No uncontrolled third path.

Note: For guests with personal Microsoft Accounts (@outlook.com etc.), the sign-in experience changes: They will receive an Email OTP code instead. In typical B2B partner scenarios with corporate accounts, this has no impact.

Reference: Prevent your B2B users from redeeming an invite using Microsoft accounts

Solution Part 2: Configure Inbound Trust Settings

#

For guests that actually come from a Microsoft Entra Tenant, you also need the Inbound Trust Settings. This tells your tenant to trust MFA claims from other Entra ID tenants.

1. In the Microsoft Entra Admin Center → External Identities → Cross-tenant access settings
2. Default settings → Edit inbound defaults → Trust settings tab
3. Enable Trust multifactor authentication from Microsoft Entra tenants
4. Save

Tip: You can also configure this setting per organization if you don’t want to trust all external tenants by default. Create a specific configuration for the partner tenant under Organizational settings.

So far, so good. For many scenarios, these two steps are sufficient. But not for all.

The Trap: Authentication Strength and External Users

#

If you have configured your Conditional Access Policies with Authentication Strengths, as recommended by Microsoft, guest users can still fail despite enabled Inbound Trust Settings. The reason is more nuanced than it appears at first glance.

What Works and What Doesn’t

#

Authentication Strength and Inbound Trust are not fundamentally incompatible. What matters is which Authentication Strength you require and which MFA method the guest used in their home tenant:

• Built-in “Multifactor authentication” Strength (the weakest of the three): Works with Inbound Trust as long as the guest used one of the methods accepted by Microsoft for cross-tenant scenarios in their home tenant (e.g. Microsoft Authenticator Push, FIDO2, Software OATH Token).
• “Passwordless MFA” or “Phishing-resistant MFA” Strength: This is where it gets tight. Your resource tenant cannot reliably validate which specific method the guest used in their home tenant. If you require Phishing-Resistant but the guest authenticated via Authenticator Push (not Passwordless) in their home tenant, validation fails.
• Custom Authentication Strengths: Same problem. The more specific the requirement, the more likely external users will fail.

The Additional Trap: External Authentication Methods

#

If the guest’s home tenant uses a third-party MFA provider via the External Authentication Methods (EAM) integration, things get definitively problematic. Microsoft explicitly warns about this in the documentation:

⚠️ Warning: External authentication methods are currently incompatible with authentication strength. You should use the Require multifactor authentication grant control.

— Microsoft Learn: Require multifactor authentication for all users

This warning primarily refers to External Authentication Methods (EAM), meaning scenarios where the home tenant has integrated a third-party provider (e.g. Duo, RSA SecurID) as MFA provider via the EAM interface. In this case, your resource tenant cannot validate the guest’s MFA method via Authentication Strength, regardless of which strength level you have configured.

Why This Affects Almost Everyone in Practice

#

A typical baseline policy looks like this:

• Users: All users (incl. Guests)
• Target resources: All resources
• Grant: Require authentication strength → Multifactor authentication

This is the Microsoft recommended baseline policy. Even with the weakest Built-in Strength, guests frequently fail in practice because:

1. As the resource tenant, you don’t know which MFA provider the home tenant uses (native Entra MFA or EAM third-party)
2. You cannot control which MFA method the guest actually uses
3. The error message does not clearly point to Authentication Strength as the cause
4. Everything works perfectly for internal users

This makes the safe fallback to the classic “Require multifactor authentication” grant control for guests the more pragmatic choice in most environments.

Trade-off: With the classic MFA grant control, you lose the ability to enforce Phishing-Resistant MFA for guests. If this is relevant for your security concept (e.g. for access to sensitive resources), you can configure tighter settings for specific partner tenants via Organizational Settings and keep Authentication Strength there. Prerequisite: You have confirmed with the partner that they use native Entra MFA with appropriate methods.

Solution Part 3: Separate CA Policy for Guests

#

The most pragmatic solution: A dedicated Conditional Access Policy for external users with the classic grant control instead of Authentication Strength.

Create a CA Policy for Guests

#

Create a new Conditional Access Policy for external users:

1. Users: Select users and groups → Guest or external users → B2B collaboration guest users
2. Target resources: All resources (or the relevant apps)
3. Grant: Require multifactor authentication (not “Require authentication strength”!)

Exclude Guests from the Existing Policy

#

In your existing policy for all users (that uses Authentication Strength), exclude guest users:

1. Under Exclude → Select Guest or external users

This way, you keep Authentication Strength for internal users (e.g. phishing-resistant methods) while guests are covered by the separate policy with the classic MFA grant control.

For regulated environments: If you need to enforce Phishing-Resistant MFA for specific partner tenants, you can additionally create a third CA Policy scoped to a specific group of known partner guests that uses Authentication Strength. Prerequisite: You have verified with the partner that they use native Entra MFA with compatible methods (FIDO2, Windows Hello for Business, Certificate-Based Auth), so no third-party providers via EAM.

Summary

#

For MFA to work with external users / guests in your Entra ID tenant, you need three things:

Sources:

• Prevent your B2B users from redeeming an invite using Microsoft accounts
• Cross-tenant access settings: Inbound Trust Settings for MFA
• Require multifactor authentication for all users: Conditional Access Policy
• Require authentication strength for external users
• Authentication and Conditional Access for External ID: MFA method comparison
• External authentication method provider reference