MFA for Entra External ID, explained for app builders

Customer logins are a target. Attackers know that a single reused password can open a customer-facing app, which has led to many companies making second-factor authentication no longer optional for external accounts. Microsoft Entra External ID is the customer identity and access management platform that handles external users and lets you turn on multi-factor authentication for everyone who signs in to your app.

Entra External ID runs inside an external tenant, which is a separate directory from the workforce tenant your employees use. That separation matters. Your staff identities, internal groups, and corporate conditional access stay in the workforce tenant, while customers, partners, and other outside users live in the external tenant with their own sign-up and sign-in rules. In other words, the external tenant is what enables the configuration of multi-factor authentication for customer accounts without touching employee policy.

The mechanism that governs the customer experience is the user flow. A user flow defines the sequence a person sees when they create an account or sign in: which attributes you collect, which first-factor authentication method applies, and whether a second factor gets requested. Once you create a user flow and attach it to an application, every external user will hit the same sign-up and sign-in user flow upon accessing the application. When you want to add MFA to that experience, you start with the methods the external tenant allows, then layer policy on top.

One main user flow can serve several apps, meaning that changes made to the MFA behavior in that flow are also updated across all associated apps at once.

Supported MFA methods for external identities  

Entra External ID external tenants support three second-factor verification methods today: email one-time passcode, SMS-based authentication, and FIDO2 passkeys. Each sits at a different point on the security and usability scale, and each carries its own prerequisites. When choosing the best method for your environment, pick based on the risk of the data behind the login, not what's easiest to switch on.

The most phishing-resistant choice is the FIDO2 passkey. A passkey uses public-key cryptography bound to the user's device or a hardware key, so there's no shared secret an attacker can phish or replay. A passkey also satisfies multi-factor authentication in a single gesture, because the device unlock (a fingerprint or PIN) plus possession of the key counts as two factors at once. This single-tap passwordless sign-in method is both stronger and faster than typing a code. The catch: Passkeys require a custom URL domain in the external tenant before they'll function, since the credential binds to your sign-in domain rather than the default Microsoft one.

Email one-time passcode  

Email one-time passcode sends a short code to the address on the account, and the user types it back to prove control of that inbox. It needs no phone number or app install, making it the lowest-friction option for a broad consumer base. Treat it as a baseline second-factor verification method rather than a high-assurance one, because anyone who already controls the mailbox controls the factor.

SMS-based two-factor authentication  

SMS-based authentication, sometimes called SMS-based two-factor authentication, texts a code to the user's mobile number. This method is familiar and works on any phone. However, it also comes with two important things to weigh: First, SMS delivery is metered and pricing tiers vary by country, so a global user base can run up real costs. Second, SMS-based authentication is protected by telephony throttling, a Microsoft control that caps how many messages a tenant can send to deter toll-fraud abuse, and that throttling can delay codes during a spike. SMS is an acceptable fallback. It shouldn't be your only line.

FIDO2 passkeys as passwordless MFA  

Email one-time passcode is the direct alternative to SMS-based authentication when you want a no-phone option, but for accounts touching payment or personal data, push users toward passkeys. The table below shows each method's strengths and trade-offs.

Method

Strength

Prerequisite

Best for

Email one-time passcode

Low to medium

Valid email address

Broad consumer sign-up

SMS-based authentication

Medium

Phone number, SMS budget

Users without app or passkey support

FIDO2 passkey

High, phishing-resistant

Custom URL domain

High-value or sensitive accounts

Conditional access policies for external MFA  

Turning on an MFA method is what makes it available. A conditional access policy is what makes it required. In an external tenant, conditional access is the rules engine that decides, per sign-in, whether to allow access, block it, or demand a second factor. A conditional access policy enforces multi-factor authentication by evaluating signals, such as the application being accessed, the user or group, and the sign-in risk level, then applying a grant control to the result.

The relationship between conditional access and the authentication methods in your user flow is layered, not duplicated. The user flow decides which first-factor and second-factor options can appear. The conditional access rules decide when the second factor actually fires. In this case, the user flow could be left permissive with a conditional access MFA policy that only challenges users hitting a sensitive app or coming in from an unusual risk signal. This keeps low-risk sign-ins fast while still raising the bar where it counts to ensure Zero Trust least privilege access.

You enable the underlying MFA method in the admin center first, then create a user policy for it.

Step-by-step: Creating a conditional access policy for external MFA  

This walkthrough builds a conditional access policy in the Microsoft Entra admin center that requires MFA for external tenant users. Test with a temporary external account, not a real customer.

  1. Check prerequisites: Confirm your external tenant has at least one MFA method enabled (email one-time passcode is the quickest to verify) and that you have a test external user mapped to your sign-up and sign-in user flow.

  2. Open the policy editor: In the Microsoft Entra admin center for the external tenant, go to Protection > Conditional Access > Create new policy.

  3. Name and scope users: Give the policy a clear name. Under Users, select the external user group you want covered. Leave a break-glass admin account out of scope.

  4. Pick the app: Under Target resources, select the customer-facing application tied to your user flow. A user flow example: a sign-up and sign-in flow attached to a retail web app where this policy now governs that app's logins.

  5. Set the grant control: Under Grant, choose Require multi-factor authentication, then click Save. This is the line that enforces MFA on every matching sign-in.

  6. Test in report-only: Set the policy to Report-only, sign in as your test user, and check the sign-in logs to confirm the policy would've fired. The user flow mapping means the MFA prompt appears right inside the sign-in experience the customer already sees. Once the logs look right, flip the policy to On.

Authentication context for step-up MFA  

Standard conditional access challenges at the front door. Authentication context moves the challenge deeper, so a stronger factor fires only when a user tries something sensitive inside an app that they're already signed in to. Think of a customer who browses an account freely but triggers a passkey prompt the moment they change payout bank details.

Authentication context builds on conditional access policy rather than replacing it. You define a context value in the admin center, your application references that value in code at the sensitive operation, and a conditional access policy bound to the context requires the stronger MFA. This contextual authentication pattern is how you apply step-up authentication context without forcing every user through a hard challenge at login. It fits Zero Trust least privilege access cleanly because trust gets re-checked at the exact action that needs it. The limitation worth naming: Authentication context only works if your app developers instrument the sensitive actions, so it isn't a setting you can flip on alone.

Use it for money movement, data export, and profile-takeover style changes.

Federating external identity providers and MFA implications  

Many customer apps let people sign in with an account they already have. Identity provider federation connects your external tenant to Google, Facebook, Apple, or a custom OIDC or SAML provider, and that connection changes the MFA picture. When a user federates in, the external identity provider performs the first-factor authentication, ultimately constraining the available methods for multi-factor authentication that your tenant can apply on top.

The practical effect: A federated user may bypass certain second-factor options, because the home provider already asserted who they are, and some providers pass their own MFA claim along. If you need a guaranteed second factor, write a conditional access policy that requires MFA regardless of how the user arrived, and confirm whether the federated IdP's assertion satisfies it or whether your tenant prompts again. This is also the path most teams use when they migrate from Azure AD B2C to Entra External ID and want consistent customer identity access management behavior across providers.

MFA in B2B collaboration scenarios  

B2B collaboration is a different shape of external access, where a guest from another organization's tenant uses your app. The external identity platform encompasses B2B collaboration alongside customer sign-ups, and here the home tenant usually owns the MFA. Cross-tenant access settings are where you decide the trust boundary: You can configure your tenant to trust the MFA claim the guest's home tenant already performed or to challenge the guest again on your side. Trusting the inbound claim spares the guest a double prompt. Not trusting it gives you control when you can't vouch for the partner's policy. Set this deliberately, because the default is to re-prompt.

Managing external tenant MFA settings and cross-tenant access  

Day-to-day MFA management for an external tenant happens in the Microsoft Entra admin center. These steps cover enabling methods, setting cross-tenant trust, and configuring the custom domain work passkeys depend on.

  1. Enable MFA methods: In the external tenant, open the authentication methods settings and enable email one-time passcode, SMS-based authentication, or passkey for the target groups. Disable methods you don't want offered so they never appear in the user flow.

  2. Set up the custom URL domain: Passkey (FIDO2) requires a custom URL domain as a prerequisite, so add and verify your branded domain before enabling the passwordless sign-in method. Without it, the passkey option won't register for users.

  3. Configure cross-tenant access settings: Open cross-tenant access, then set inbound trust for B2B guests to decide whether your tenant accepts a partner tenant's MFA claim or requires its own.

  4. Monitor adoption: Use the sign-in logs and authentication methods activity reports to track how many external users have registered a second factor and which methods they pick. Sketch your sign-up and sign-in user flow as a simple user flow diagram so you can see exactly where the MFA step lands before you change anything.

  5. Plan around the trade-off: Enabling passkeys improves security, but the custom URL domain and DNS verification add setup time. Make sure to budget a day for this step rather than expecting an instant toggle.

The external tenant handles your customers, ADSelfService Plus handles your workforce

Everything covered above lives inside an external tenant, a purpose-built boundary for customer identities. But most organizations running Entra External ID also have a hybrid Active Directory environment behind it: Windows endpoints, RDP sessions, UAC prompts, and on-premises apps that Entra's native MFA doesn't reach by default.

That's the gap ManageEngine ADSelfService Plus is built for. It extends Entra ID MFA beyond the cloud to secure the parts of your infrastructure that conditional access policies alone can't touch, all enforced from a single platform, using the same authenticators your team already knows.

Why choose ADSelfService Plus for Entra ID MFA?

  • Endpoint-centric MFA: Enforce Entra ID MFA on Windows logins for Entra joined and hybrid joined machines, RDP sessions, and UAC prompts—coverage native Entra MFA doesn't extend to out of the box.

  • 17+ authenticators: From FIDO2 passkeys and biometrics to push notifications and hardware OATH tokens, there's a method that fits every user and every risk level.

  • Up to three verification factors: Go beyond the standard two-step model and stack up to three identity checks on top of a password for your most sensitive access scenarios.

  • Granular policy control: Configure separate MFA policies for specific domains and groups within the same tenant—biometric verification for finance, OTP for general staff, and no blanket rules that force a one-size-fits-all experience.

If you've got the customer-facing layer locked down, ADSelfService Plus is where you close the loop on the workforce side.