External ID customer email-OTP sign-in: Authenticator TOTP enabled, but no MFA enrollment offered

Question

External ID customer email-OTP sign-in: Authenticator TOTP enabled, but no MFA enrollment offered

Nicolai Schmidt Nygaard - Work Being 0

In a Microsoft Entra External ID external customer tenant, an existing application's user flow uses Email One Time Passcode. An app-only Conditional Access policy requires MFA for all users.

Microsoft Authenticator is enabled for all users, with Allow use of Microsoft Authenticator OTP = Yes. Software OATH is also enabled. SMS is intentionally limited to a separate pilot group.

After signing out and starting a fresh browser sign-in, the existing customer reaches the email-code page, then receives “An additional verification method is required to access this site or app.” No Authenticator registration or TOTP challenge is offered.

The current Microsoft customer MFA documentation describes TOTP as a second factor for email-OTP customers. Is there a rollout prerequisite or additional customer-registration setting needed for this combination? What is the supported diagnostic path when the browser correlation ID does not yet appear in the tenant's sign-in logs?

This concerns an external customer user flow, not workforce guest/B2B authentication. We want to preserve MFA and avoid expanding SMS or recreating accounts. Tenant, account and diagnostic identifiers can be provided through a verified private Microsoft support channel if needed.

Nicolai Schmidt Nygaard - Work Being 0 Reputation points

2026-11-05T06:12:09.6+00:00

Update: the matching sign-in event is now visible. It records AADSTS1002015, “Unable to complete the authentication flow,” with “MFA required in Azure AD.” The app-only Require MFA policy failed; the separate SMS pilot policy did not apply. Authentication details record Email verification code as unsuccessful (“Other”), followed by the MFA-required failure.

The affected existing account has no registered usable authentication methods. Its sign-in identifier is stored as federated with issuer mail. The event labels cross-tenant access as B2B collaboration, and the user overview says the account is external, despite the application using our external tenant's ciamlogin.com endpoint.

This qualifies my original statement excluding B2B: the observed identity classification needs clarification. Is this representation expected for email-OTP customer accounts, and what is the supported TOTP enrollment route for this existing identity? We have kept MFA enabled and made no exclusions, account conversions, SMS expansion or further sign-in attempts.

1 answer

Your answer

Nicolai Schmidt Nygaard - Work Being 0 Reputation points

2026-11-05T06:12:09.6+00:00

Update: the matching sign-in event is now visible. It records AADSTS1002015, “Unable to complete the authentication flow,” with “MFA required in Azure AD.” The app-only Require MFA policy failed; the separate SMS pilot policy did not apply. Authentication details record Email verification code as unsuccessful (“Other”), followed by the MFA-required failure.

The affected existing account has no registered usable authentication methods. Its sign-in identifier is stored as federated with issuer mail. The event labels cross-tenant access as B2B collaboration, and the user overview says the account is external, despite the application using our external tenant's ciamlogin.com endpoint.

This qualifies my original statement excluding B2B: the observed identity classification needs clarification. Is this representation expected for email-OTP customer accounts, and what is the supported TOTP enrollment route for this existing identity? We have kept MFA enabled and made no exclusions, account conversions, SMS expansion or further sign-in attempts.

Answer 1

No separate customer-registration switch or documented existing-user rollout prerequisite is required: with Microsoft Authenticator enabled for the customer and Allow use of Microsoft Authenticator OTP = Yes, an email-OTP customer should be offered QR-code TOTP registration when Conditional Access requires MFA.^1^

Validate the supported configuration

In the external tenant, using an account with at least Authentication Policy Administrator:

Go to Entra ID → Authentication methods → Microsoft Authenticator.
Under Enable and Target:
- Confirm the policy is enabled.
- Confirm the affected customer is included by its effective target.
Under Configure, retain Allow use of Microsoft Authenticator OTP = Yes.
Save the policy.

That is the documented configuration for Microsoft Authenticator TOTP. Third-party software OATH tokens is a separate policy for supported third-party authenticator apps; it isn't an additional prerequisite for Microsoft Authenticator.^1^

Email OTP as the primary factor is explicitly compatible with TOTP as the second factor. When MFA is required and TOTP is enabled, first-time users should scan a QR code; subsequent challenges request the temporary code. The restriction is only that primary email OTP cannot also be reused as the email-OTP second factor.^2^

Your fresh browser test already covers the documented test procedure, so recreating the account, enabling SMS more broadly, or changing to workforce/B2B trust settings is not indicated.

Determine where the transaction stops

Sign-in logging can take longer for MFA transactions because related records are aggregated. Microsoft states that aggregation can take up to two hours, although it rarely takes that long.^3^

After allowing for that interval:

In the external tenant, open Entra ID → Monitoring & health → Sign-in logs.
Filter separately by:
- customer email or user object,
- application,
- Status = Failure,
- the exact test interval.
Also inspect entries whose username is an object ID or GUID. Interrupted authentication can appear this way before sign-in completes.
Open the event and record:
- correlation ID,
- sign-in error code,
- failure reason and additional details,
- user ID/sign-in identifier,
- Authentication Details,
- Conditional Access results.

Access requires at least Reports Reader.^4^

If an event appears, launch Sign-in diagnostic from its Activity Details. In particular, look for an MFA proofup interruption, which identifies a first-time MFA setup that was initiated but not completed.^5^

When no event or correlation ID appears in the logs

The diagnostic does not require a correlation ID:

Open Diagnose & solve problems in the external tenant.
On Sign-in Diagnostic, select Troubleshoot.
Select All Sign-In Events.
Supply:
- the customer email,
- application display name or application ID,
- exact date and time,
- time zone.
Search within 48 hours of the reproduction.

The diagnostic accepts user, application, and date/time as search keys; correlationId or requestId is optional.^5^

If it still finds nothing, open a Microsoft support request under:

Service type: Microsoft Entra Sign-in and multifactor authentication
Problem type: Multifactor authentication
Problem subtype: Unable to sign in to an application due to MFA

Provide privately:

external tenant ID and application ID,
affected user object ID,
UTC timestamp and time zone,
browser correlation ID, trace ID, and complete error text if displayed,
user-flow name and primary method,
Conditional Access policy ID,
screenshots/export of both TOTP method-policy configurations,
browser/network trace if support requests one.

A browser correlation ID remains useful even before the event is visible in tenant logs because Microsoft support can use it to correlate telemetry across the authentication flow.^6^

References