A security architect is designing identity controls for a multi-tenant SaaS AI application built on Azure. The application uses Microsoft Entra External ID (B2C) for customer authentication. The architect wants to enforce MFA for all customer sign-ins through a standard policy. Which Entra External ID feature provides this?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you use the user flow (sign-in/sign-up policy) with MFA enforcement enabled because it defines the customer authentication journey in Entra External ID (B2C) and can require a second factor on every sign-in. That's the native way to enforce MFA for consumer sign-ins.
Full Explanation
The user flow (sign-in/sign-up policy) with MFA enforcement enabled is correct because in Microsoft Entra External ID (B2C), user flows (formerly called policies) define the authentication journey for end users. MFA can be enforced within the user flow configuration, requiring customers to verify their identity with a second factor (such as email OTP or phone) as part of every sign-in journey. This is the native mechanism for enforcing MFA in B2C consumer scenarios. The Entra ID Protection sign-in risk policy for external users is wrong because Entra ID Protection sign-in risk policies are for enterprise Entra ID (B2B/workforce), not for B2C consumer identity tenants; B2C has its own identity protection features. The Conditional Access policy requiring MFA, scoped to the Azure AD B2C tenant, is wrong because standard Conditional Access in a resource tenant does not directly apply to B2C user authentication flows—B2C Conditional Access requires specific configuration within the B2C tenant, and the standard all-sign-in MFA control for B2C customer journeys is the user flow configuration. The Trusted IP Named Location exclusion in the resource tenant is wrong because Named Location exclusions are for Conditional Access in the workforce tenant, not for B2C user flow MFA enforcement.