Configure Authentication Strength for External Users in Conditional Access

With organizations becoming more collaborative with external users, the need to secure access to critical resources becomes paramount. Without the right safeguards, sensitive information shared with external users could be at risk. To combat this, Microsoft Entra offers Authentication Strength in Conditional Access policies, allowing you to specify the exact combination of strong MFA methods external users must complete. In this blog, let’s explore how to enforce authentication strength for external users in Conditional Access policies that raise your external security to the next level.

Conditional Access Authentication Strength is a feature that controls which MFA methods a user can use to sign in and access resources. In the past, MFA was governed by the “Require multi-factor authentication” option, which permitted users to choose any MFA method they preferred. With the introduction of the Authentication Strength feature, admins can now specify the exact MFA methods that users must use. This feature allows administrators to define acceptable combinations of authentication methods, such as passwords, MFA, or stronger options.

For example:

• To protect sensitive data, admins can require stronger authentication methods like phishing-resistant MFA.
• For less sensitive resources, they might allow less secure methods like password and SMS MFA.

Admins can create CA policies to enforce specific authentication methods. They can choose from built-in strengths such as MFA, passwordless MFA, or phishing-resistant MFA. Additionally, admins can define a custom authentication strength, giving them the flexibility to combine stronger security methods. This level of control allows admins to tailor authentication requirements based on factors like the data being accessed, the user’s location, or their risk level.

Note: In a Conditional Access policy, the controls “Require multifactor authentication” and “Require authentication strength” cannot be used together. This is because the built-in authentication strength for multifactor authentication is essentially equivalent to the “Require multifactor authentication” grant control.

To keep external users secure when accessing your resources, it’s important to configure MFA trust settings in cross-tenant access. Here’s how it works:

When a Microsoft Entra external user attempts to access your resources, they first log in using their account from their home tenant. Microsoft Entra ID then checks the MFA trust settings to determine the required MFA type.

MFA Trust Options:

• When MFA trust is enabled, Microsoft Entra checks if the external user has already completed MFA in their home tenant. If they have, the system acknowledges this and allows them to proceed without requiring additional MFA in the resource tenant.

• When MFA trust is disabled, the resource tenant will challenge the external user to complete MFA again, even if they’ve already done so in their home tenant. This ensures that MFA is performed using the methods required by the resource tenant’s policies.

How to Enable Inbound MFA Trust Settings?

To enable MFA trust settings for cross-tenant access, follow these steps:

1. Sign in to the Microsoft Entra admin center.
2. Navigate to Identity –> External Identities –> Cross-tenant access settings.
3. In the Organizational settings section, select Inbound access settings for the organization you want to trust.
4. Under Inbound settings, navigate to the Trust settings tab in the top bar.
5. For custom settings, select Customize settings. You will find the following options:
   • Trust multifactor authentication from Microsoft Entra tenants: Select this option if you want to allow Conditional Access to trust MFA from other Microsoft Entra tenants. This means that if a user already did MFA in their own organization, it will be trusted. However, this doesn’t apply to technicians from service providers who use special admin privileges (GDAP).
   • Trust Compliant Devices: Select this option to trust compliant devices from external organizations when their users access your resources.
   • Trust Hybrid Joined Devices: Select this if you want to trust hybrid joined devices (devices joined to both on-premises Active Directory and Microsoft Entra) from external organizations.

6. If you want users from a specific external tenant to skip the consent prompt when accessing your resources for the first time, check the option for Automatically redeem invitations.

7. After configuring the necessary settings, click Save.

Tip: If you want to ensure a higher level of security, you can leave the MFA trust disabled. Even if an external user has already completed MFA in their home tenant, they will still be required to complete MFA again. This will ensure they use the specific authentication methods defined by your Conditional Access policy in the resource tenant. However, you may not be able to require FIDO2 MFA from external users, as Microsoft permits only certain MFA methods to be enforced by resource tenants.

Authentication Methods Supported by Home Tenant and Resource Tenant for External Users:

Authentication Method	Home Tenant	Resource Tenant
Text message as second factor	✔	✔
Voice call	✔	✔
Microsoft Authenticator push notification	✔	✔
Microsoft Authenticator phone sign-in	✔
OATH software token	✔	✔
FIDO2 security key	✔
Windows Hello for Business	✔
Certificate-based Authentication	✔

For example,

• The external user logs into their home tenant (Company A). They can use MFA methods like SMS codes or biometrics based on Company A’s settings.
• When the external user attempts to access resources at another organization (Company B). Company B may have specific MFA requirements that differ from Company A, such as requiring the Microsoft Authenticator push notification.

It’s important to note that the available MFA methods can differ depending on whether the user is performing MFA in their home tenant or your tenant.

Before setting up authentication strength for external users in Conditional Access, make sure your cross-tenant access settings match your MFA trust requirements.

To create a Conditional Access policy, you need Global/Security/Conditional Access administrator permission along with Microsoft Entra ID P1 and P2 licensing options. You can also create CA policies by using pre-defined Conditional Access policy templates.

Follow the below-mentioned steps to require an authentication strength for external users in Conditional Access:

1. Sign in to the Microsoft Entra admin center.
2. Navigate to Protection –> Conditional Access.
3. Click on Create new policy and provide a name for the policy.
4. In the Assignment section, choose Users.
5. In the Include category, click on ‘Select users and groups’, and then pick Guest or external users.
6. Choose the external user types to apply the CA policy to. Under Exclude, add your organization’s emergency access or break-glass accounts if there are any.
7. Under Target resources, go to Cloud apps and choose the apps to include or exclude from authentication strength requirements.
8. In the Access controls section, navigate to Grant and select Grant access.
9. Enable Require authentication strength, and then pick a built-in or custom authentication strength from the drop down.
10. Confirm your settings and flip the Enable policy toggle from ‘Report-only’ to On.
11. Click Create to create your CA policy.

Once set up, the policy ensures that external users meet the required authentication strength, like completing MFA, to access your resources.

External User Experience:

Let’s say authentication strength requires the external user to complete Microsoft Authenticator phone sign-in. So, when the external users try to access any organizational resources, the user will be prompted to use an additional sign-in method like below.

I hope this blog has provided you with valuable insights on enforcing authentication strength for external users within the Conditional Access policy. If you have any questions or need further clarification, please don’t hesitate to reach out in the comments section.