Microsoft Entra External ID customer tenant - Conditional Access step-up MFA, licensing and Security Defaults

Here's what I found.**

1. Does the Core offer support authentication contexts and step-up MFA?**

Yes. The workforce-versus-external comparison lists, for Conditional Access in external tenants:

• Target resources: all resources, selected apps, filter for applications, and authentication context
• Grant controls: block access, require multifactor authentication, require password reset
• Session controls: sign-in frequency and persistent browser session

So a policy such as "authentication context c1 → require MFA, sign-in frequency" is supported for your customer identities. One requirement for email OTP as the second factor: the local account method must be Email with password, as yours is. If customers sign in with Email with one-time passcode, they can't use email OTP again for MFA.

2. Extra licences or charges?

The External ID pricing page describes MAU-based billing plus a short list of premium add-ons: SMS phone authentication, M2M authentication, Go-Local, and two that apply to workforce tenants only. Conditional Access, authentication context, sign-in frequency and email OTP aren't listed as add-ons. SMS is the only MFA method that costs extra, and it needs the linked subscription you already have. The general Conditional Access docs mention Entra ID P1, but that refers to workforce tenants. Check the current pricing page for your region before you commit.

3. Do you need to disable Security Defaults?

Yes. The Security Defaults article says: "Organizations that choose to implement Conditional Access policies that replace security defaults must disable security defaults." They can't be used together.

4 and 5. Keeping protection during the switch

Security Defaults mainly protect your admin accounts: MFA for admin roles, MFA for Azure management, and blocking legacy authentication and device code flow. Microsoft documents equivalent Microsoft-managed Conditional Access policies that you can enable after you disable Security Defaults. A short window without protection between the two steps is unavoidable, so keep it to minutes:

• Before the change, write down every policy you'll create: your break-glass exclusions, MFA for admins, the c1 step-up policy and any app-wide policy.
• Create two cloud-only emergency access accounts first, as Microsoft recommends, and exclude them from every policy.
• In one maintenance window, disable Security Defaults, then immediately create and enable the policies, starting with MFA for admins.
• Sign in with a test customer and an admin account to confirm both behave as expected.

6. Verifying that the context was really protected

You're right that acrs alone isn't proof. Microsoft's authentication-context developer guide says that if no Conditional Access policy is assigned to an auth context value, "the claim might still be issued". Its table shows acrs being issued when a context is requested but no policy is configured. In the app, the guide's pattern is:

• Request the context explicitly in the claims parameter when the user starts the sensitive operation, and check that the token's acrs contains c1 before you allow it.
• Don't hard-code the meaning of c1 in the app. Read the available contexts through Microsoft Graph (authenticationContextClassReferences).

The token can only tell you that the context was satisfied. It can't tell you whether a policy behind c1 actually required MFA, so that has to be checked separately (point 7).

7. Failing closed if the policy is changed or removed

I couldn't find a built-in setting that makes an app fail closed when a policy is disabled. The practical approach is to verify the configuration outside the token:

• Run a scheduled check, for example a pipeline step or admin job with Policy.Read.All. It should confirm that an enabled Conditional Access policy targets authentication context c1 and requires MFA. In Graph, look for policies where conditions.applications.includeAuthenticationContextClassReferences contains c1, state is enabled, and grantControls.builtInControls contains mfa.
• If the check fails, have it switch off the sensitive operations (a feature flag your app reads), so ownership transfer and company closure are blocked until the policy is restored.
• Also alert on changes to Conditional Access policies in the audit logs. External tenants keep logs for seven days, so export them (Azure Monitor for external tenants is in preview) if you need them for longer.