How to configure a global flag in Azure AD B2C portal, and read it in the Custom Policy to enable/disable MFA dynamically?

Question

I am using "Azure AD B2C with Custom Policies (Identity Experience Framework)" and implementing MFA as part of my sign-in flow & step -up flow (trigger MFA while accessing the sensitive info). And I have 2 separate custom policies (One for sign in flow, another for step up flow)

I have a requirement to introduce global flags (e.g., isMFARequiredForSignIn, isMFARequiredForStepUp****) which can be configured at the Azure AD B2C level and used inside the custom policies to:

1. Enable or disable MFA dynamically during the sign-in flow & step-up flow
2. Avoid redeploying the custom policies whenever the flags changes
3. Optionally include this flags value in the issued token

What I tried:

I explored using "Policy Keys (Identity Experience Framework → Policy Keys)" to store a boolean value (true/false), but it seems Policy Keys are only intended for secrets (API keys) and cannot be read as claims or used in orchestration logic.

What I am looking for:

Is there a way to define a tenant-level or global configuration flag in Azure AD B2C that can be:

• Read inside the custom policies
• Used in orchestration step preconditions (e.g., to skip or execute MFA)
• Returned as a claim in the token

Questions:

1. What is the recommended approach to implement such a flags in Azure AD B2C?
2. What is the best practice for controlling MFA in the custom policies, based on the configured flags in the Azure AD B2C

Expected Outcome:

Ability to conditionally execute MFA like:

• If flag = true → trigger MFA
• If flag = false → skip MFA

without modifying and redeploying the custom policy XML.

Note: I need the flexibility to enable MFA during the sign-in flow and disable it during step-up, and vice versa, based on the configured flag.

Any guidance or recommended patterns would be highly appreciated.

Answer 1

Hello viswanadham paila,

In Azure AD B2C custom policies, there is no built-in tenant-level or global configuration flag that can be defined in the portal and directly read inside a policy for orchestration logic.

Important clarifications:

• Policy Keys are only for secrets (certificates, client secrets, API keys). They cannot be read as claims and cannot be used in orchestration step preconditions, so they are not suitable for feature flags.
• Custom policies can evaluate only claims present in the claims bag. If a value is not a claim, it cannot control MFA execution. Recommended and supported approach

The recommended pattern is to externalize the flag and retrieve it dynamically via a REST API during policy execution:

1. Store your MFA flags (isMFARequiredForSignIn, isMFARequiredForStepUp) in an external system (for example: Azure App Configuration, database, or configuration service).
2. Call that service using a RESTful technical profile early in the user journey.
3. Return the flag values as Boolean output claims.
4. Use Orchestration Step Preconditions (ClaimEquals) to skip or execute the MFA step.
5. (Optional) Include the flag claims in the issued token.

This allows you to enable or disable MFA dynamically without modifying or redeploying the policy XML.

Example logic:

JSON

If isMFARequiredForSignIn = true → execute MFA orchestration step

If isMFARequiredForSignIn = false → skip MFA orchestration step

``

The same pattern applies independently to your step‑up flow using a separate flag (isMFARequiredForStepUp).

Why this is best practice

• No policy redeployment when flags change
• Full control via configuration outside B2C
• Clean separation of policy logic and runtime decisions
• Fully supported and commonly used for dynamic behavior in custom policies Alternatives (with limitations)
• Selecting different policies from the application (MFA vs non‑MFA) – requires app changes
• Using per‑user attributes – works for user‑specific MFA, not for global tenant flags

https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policies-series-call-rest-api

https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile

I kindly request you to please let me know and comment if this doesn’t fully address your question or if you need any additional information. I’ll be happy to assist you further.

Answer 2

Azure AD B2C custom policies do not expose a built‑in, tenant‑level “feature flag” that can be read directly in orchestration steps or emitted as a claim. The behavior of MFA and Conditional Access is controlled through:

• The custom policy XML (for custom policies), and
• User flows configuration (for built‑in flows), including MFA and Conditional Access settings.

From the provided information, the supported and recommended ways to control MFA are:

1. Configure MFA behavior in the policy or user flow
   For user flows, MFA is configured when creating or editing the flow:
   • In the Azure portal, under Azure AD B2C → User flows → [your flow], configure Multifactor authentication to control when MFA is enforced (for example, always, or for specific scenarios).
   • Conditional Access can also be enforced for the user flow by selecting Enforce conditional access policies when creating the user flow. This allows MFA to be driven by Conditional Access policies instead of hard‑coding it in the flow.

   “If you already created sign-up and sign-in user flows, you can still enable multifactor authentication.”
   “Under Multifactor authentication, if you want to require users to verify their identity with a second authentication method, choose the method type and when to enforce multi-factor authentication (MFA).”

2. Use Conditional Access policies to control MFA centrally
   For both user flows and custom policies, MFA can be controlled via Conditional Access, which is configured at the tenant level and applied to “All cloud apps” or specific apps. This is the closest supported pattern to a “global flag” for MFA:
   • Create Conditional Access policies under Azure AD B2C → Security → Conditional Access.
   • For sign‑in risk–based MFA (Template 1):
     • Include All users (excluding break‑glass accounts).
     • Include All cloud apps.
     • Under Conditions → Sign-in risk, enable and select Medium and High.
     • Under Access controls → Grant, select Grant access and Require multi-factor authentication.
   • For user risk–based policies (Template 2):
     • Include All users (excluding break‑glass accounts).
     • Include All cloud apps.
     • Under Conditions → User risk, enable and select Medium and High.
     • Under Access controls → Grant, select Grant access, Require password change (MFA is required by default).
   These policies can be enabled/disabled or adjusted without redeploying custom policy XML, and they apply across the tenant to the targeted apps and flows.

   “Configure Conditional Access through the Azure portal or Microsoft Graph APIs to enable a sign-in risk-based Conditional Access policy requiring MFA when the sign-in risk is medium or high.”
   “Configure Conditional Access through Azure portal or Microsoft Graph APIs to enable a user risk-based Conditional Access policy requiring multifactor authentication (MFA) and password change when user risk is medium OR high.”

3. Attach Conditional Access to user flows instead of embedding MFA logic
   When creating a sign‑in user flow, Conditional Access can be enforced without modifying the flow XML:
   • In the Create a user flow wizard:
     • Configure Multifactor authentication as needed.
     • Under Conditional access, select Enforce conditional access policies to allow tenant‑level Conditional Access policies to drive MFA.

   “Under Conditional access, if you've configured Conditional Access policies for your Azure AD B2C tenant and you want to enable them for this user flow, select the Enforce conditional access policies check box.”

4. Best practice for controlling MFA
   Based on the context, best practices are:
   • Use Microsoft Entra multifactor authentication integrated with Azure AD B2C for the second factor.
   • Prefer Conditional Access policies (sign‑in risk or user risk–based) to centrally control when MFA is required, rather than embedding many conditional branches in custom policy XML.
   • For user flows, configure MFA and Conditional Access at the flow level; for custom policies, rely on Conditional Access for dynamic, tenant‑level control.
   This approach allows enabling/disabling or tightening/loosening MFA requirements by changing Conditional Access policies or user flow settings, without redeploying custom policy XML. However, the Conditional Access decision itself is not emitted as a claim in the token in the material provided, and there is no documented mechanism here for a custom, arbitrary “global flag” claim that controls orchestration steps.

---

References:

• Enable multifactor authentication in Azure Active Directory B2C (b2c-user-flow)
• Enable multifactor authentication in Azure Active Directory B2C (b2c-custom-policy)
• Add Conditional Access to user flows in Azure Active Directory B2C (b2c-custom-policy)
• Add Conditional Access to user flows in Azure Active Directory B2C (b2c-user-flow)
• Set up a sign-in flow in Azure Active Directory B2C (b2c-user-flow)
• Technical and feature overview of Azure Active Directory B2C
• Azure AD B2C custom policy overview