Authentication and Conditional Access for External ID

Applies to: Workforce tenants External tenants (learn more)

When an external user accesses resources in your organization, the authentication flow is determined by the collaboration method (B2B collaboration), user's identity provider (an external Microsoft Entra tenant, social identity provider, and so on), Conditional Access policies, and the cross-tenant access settings configured both in the user's home tenant and the tenant hosting resources.

This article describes the authentication flow for external users who are accessing resources in your organization. Organizations can enforce multiple Conditional Access policies for their external users, which can be enforced at the tenant, app, or individual user level in the same way that they're enabled for full-time employees and members of the organization.

Authentication flow for external Microsoft Entra users

The following diagram illustrates the authentication flow when a Microsoft Entra organization shares resources with users from other Microsoft Entra organizations. This diagram shows how cross-tenant access settings work with Conditional Access policies, such as multifactor authentication, to determine if the user can access resources. This flow applies to both B2B collaboration, except as noted in step 6.

Step	Description
1	A user from Fabrikam (the user’s home tenant) initiates sign-in to a resource in Contoso (the resource tenant).
2	During sign-in, the Microsoft Entra security token service (STS) evaluates Contoso's Conditional Access policies. It also checks whether the Fabrikam user is allowed access by evaluating cross-tenant access settings (Fabrikam’s outbound settings and Contoso’s inbound settings).
3	Microsoft Entra ID checks Contoso’s inbound trust settings to see if Contoso trusts MFA and device claims (device compliance, Microsoft Entra hybrid joined status) from Fabrikam. If not, skip to step 6.
4	If Contoso trusts MFA and device claims from Fabrikam, Microsoft Entra ID checks the user’s authentication session for an indication that the user completed MFA. If Contoso trusts device information from Fabrikam, Microsoft Entra ID looks for a claim in the authentication session indicating the device state (compliant or Microsoft Entra hybrid joined).
5	If MFA is required but not completed, or if a device claim isn't provided, Microsoft Entra ID issues MFA and device challenges in the user's home tenant as needed. When MFA and device requirements are satisfied in Fabrikam, the user is allowed access to the resource in Contoso. If the checks can’t be satisfied, access is blocked.
6	When no trust settings are configured and MFA is required, B2B collaboration users are prompted for MFA. They need to satisfy MFA in the resource tenant. If device compliance is required but can't be evaluated, access is blocked for B2B collaboration users.

For more information, see the Conditional Access for external users section.

Authentication flow for non-Azure AD external users

When a Microsoft Entra organization shares resources with external users with an identity provider other than Microsoft Entra ID, the authentication flow depends on whether the user is authenticating with an identity provider. In either case, the resource tenant identifies which authentication method to use, and then either redirects the user to their identity provider or issues a one-time passcode.

Example 1: Authentication flow and token for a non-Azure AD external user

The following diagram illustrates the authentication flow when an external user signs in with an account from a non-Azure AD identity provider, such as a federated SAML/WS-Fed identity provider.

Step	Description
1	The B2B guest user requests access to a resource. The resource redirects the user to its resource tenant, a trusted IdP.
2	The resource tenant identifies the user as external and redirects the user to the B2B guest user’s IdP. The user performs primary authentication in the IdP.
3	Authorization policies are evaluated in the B2B guest user's IdP. If the user satisfies these policies, the B2B guest user's IdP issues a token to the user. The user is redirected back to the resource tenant with the token. The resource tenant validates the token and then evaluates the user against its Conditional Access policies. For example, the resource tenant could require the user to perform Microsoft Entra multifactor authentication.
4	Inbound cross-tenant access settings and Conditional Access policies are evaluated. If all policies are satisfied, the resource tenant issues its own token and redirects the user to its resource.

Conditional Access for external users

Organizations can enforce Conditional Access policies for external B2B collaboration users in the same way that they’re enabled for full-time employees and members of the organization. With the introduction of cross-tenant access settings, you can also trust MFA and device claims from external Microsoft Entra organizations. This section describes important considerations for applying Conditional Access to users outside of your organization.

Assigning Conditional Access policies to external user types

When configuring a Conditional Access policy, you have granular control over the types of external users you want to apply the policy to. External users are categorized based on how they authenticate (internally or externally) and their relationship to your organization (guest or member).

• B2B collaboration guest users - Most users who are commonly considered guests fall into this category. This B2B collaboration user has an account in an external Microsoft Entra organization or an external identity provider (such as a social identity), and they have guest-level permissions in your organization. The user object created in your Microsoft Entra directory has a UserType of Guest. This category includes B2B collaboration users who were invited.
• B2B collaboration member users - This B2B collaboration user has an account in an external Microsoft Entra organization or an external identity provider (such as a social identity) and member-level access to resources in your organization. This scenario is common in organizations consisting of multiple tenants, where users are considered part of the larger organization and need member-level access to resources in the organization’s other tenants. The user object created in the resource Microsoft Entra directory has a UserType of Member.
• Local guest users - Local guest users have credentials that are managed in your directory. Before Microsoft Entra B2B collaboration was available, it was common to collaborate with distributors, suppliers, vendors, and others by setting up internal credentials for them and designating them as guests by setting the user object UserType to Guest.
• Service provider users - Organizations that serve as cloud service providers for your organization (the isServiceProvider property in the Microsoft Graph partner-specific configuration is true).
• Other external users - Applies to any users who don't fall into these categories, but who aren't considered internal members of your organization, meaning they don't authenticate internally via Microsoft Entra ID, and the user object created in the resource Microsoft Entra directory doesn't have a UserType of Member.

Learn more about Conditional Access user assignments.

MFA for Microsoft Entra external users

In a Microsoft Entra cross-tenant scenario, the resource organization can create Conditional Access policies that require MFA or device compliance for all guest and external users. Generally, a B2B collaboration user accessing a resource is then required to set up their Microsoft Entra multifactor authentication with the resource tenant. However, Microsoft Entra ID now offers the ability to trust MFA claims from other Microsoft Entra tenants. Enabling MFA trust with another tenant streamlines the sign-in process for B2B collaboration users.

If you configured your inbound trust settings to accept MFA claims from a B2B collaboration user's home tenant, Microsoft Entra ID checks the user's authentication session. If the session contains a claim indicating that MFA policies were already met in the user's home tenant, the user is granted seamless sign-on to your shared resource.

Learn more about how to configure inbound trust settings for MFA.

MFA for non-Azure AD external users

For non-Azure AD external users, the resource tenant is always responsible for MFA. The following example shows a typical MFA flow. This scenario works for any identity, including a Microsoft Account (MSA) or social ID. This flow also applies for Microsoft Entra external users when you don't configure trust settings with their home Microsoft Entra organization.

1. An admin or information worker in a company named Fabrikam invites a user from another company named Contoso to use Fabrikam's app.

2. Fabrikam's app is configured to require Microsoft Entra multifactor authentication upon access.

3. When the B2B collaboration user from Contoso attempts to access Fabrikam's app, they're asked to complete the Microsoft Entra multifactor authentication challenge.

4. The guest user can then set up their Microsoft Entra multifactor authentication with Fabrikam and select the options.

Fabrikam must have sufficient premium Microsoft Entra ID licenses that support Microsoft Entra multifactor authentication. The user from Contoso then consumes this license from Fabrikam.

Microsoft Entra multifactor authentication reset (proof up) for B2B collaboration users

The following PowerShell cmdlets are available to proof up or request MFA registration from B2B collaboration users.

1. Connect to Microsoft Entra ID:

   $cred = Get-Credential
   Connect-MsolService -AzureEnvironment AzureChinaCloud -Credential $cred
   

2. Get all users with proof up methods:

   Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
   

   For example:

   Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
   

3. Reset the Microsoft Entra multifactor authentication method for a specific user to require the user to set proof up methods again, for example:

   Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.partner.onmschina.cn
   

Device compliance and Microsoft Entra hybrid joined device policies

Organizations can use Conditional Access policies to require users' devices to be managed by Microsoft Intune. Such policies can block external user access, because an external user can't register their unmanaged device with the resource organization. Devices can only be managed by a user's home tenant.

However, you can use device trust settings to unblock external users while still requiring managed devices. In your cross-tenant access settings, you can choose to trust claims from an external user's home tenant about whether the user's device meets their device compliance policies or is Microsoft Entra hybrid joined. You can set device trust settings for all Microsoft Entra organizations or individual organizations.

When device trust settings are enabled, Microsoft Entra ID checks a user's authentication session for a device claim. If the session contains a device claim indicating that the policies were already met in the user's home tenant, the external user is granted seamless sign-on to your shared resource.

Device filters

When creating Conditional Access policies for external users, you can evaluate a policy based on the device attributes of a registered device in Microsoft Entra ID. By using the filter for devices condition, you can target specific devices using the supported operators and properties and the other available assignment conditions in your Conditional Access policies.

Device filters can be used together with cross-tenant access settings to base policies on devices that are managed in other organizations. For example, suppose you want to block devices from an external Microsoft Entra tenant based on a specific device attribute. You can take the following steps to set up a device attribute-based policy:

• Configure your cross-tenant access settings to trust device claims from that organization.
• Assign the device attribute you want to use for filtering to one of the supported device extension attributes.
• Create a Conditional Access policy with a device filter that blocks access to devices containing that attribute.

Learn more about filtering for devices with Conditional Access.

Mobile application management policies

We don't recommend requiring an app protection policy for external users. Conditional Access grant controls such as Require approved client apps and Require app protection policies require the device to be registered in the resource tenant. These controls can only be applied to iOS and Android devices. Because a user’s device can only be managed by their home tenant, these controls can't be applied to external guest users.

Location-based Conditional Access

The location-based policy based on IP ranges can be enforced if the inviting organization can create a trusted IP address range that defines their partner organizations.

Policies can also be enforced based on geographical locations.

Risk-based Conditional Access

The Sign-in risk policy is enforced if the external guest user satisfies the grant control. For example, an organization could require Microsoft Entra multifactor authentication for medium or high sign-in risk. However, if a user hasn't previously registered for Microsoft Entra multifactor authentication in the resource tenant, the user is blocked. This is done to prevent malicious users from registering their own Microsoft Entra multifactor authentication credentials in the event they compromise a legitimate user’s password.

The User-risk policy, however, can't be resolved in the resource tenant. For example, if you require a password change for high-risk external guest users, they're blocked because of the inability to reset passwords in the resource directory.

Conditional Access client apps condition

Client apps conditions behave the same for B2B guest users as they do for any other type of user. For example, you could prevent guest users from using legacy authentication protocols.

Conditional Access session controls

Session controls behave the same for B2B guest users as they do for any other type of user.

Next steps

For more information, see the following articles:

• Zero Trust policies for allowing guest access and B2B external user access
• Frequently Asked Questions (FAQs)