Inconsistent Microsoft Entra ID Authentication for B2B Guest Users Using Gmail or Personal Microsoft Accounts

Idit Nevo 0 Reputation points
2026-11-04T09:16:48.9266667+00:00

Hello Microsoft Support,

We are experiencing an issue with the authentication process for external users accessing our application through Microsoft Entra ID.

Our application is intended for external contractors, who are registered in our CRM and invited as external/guest users to our Microsoft Entra ID tenant.

We have identified that the authentication experience is not consistent for all users, particularly in the following scenarios:

  1. Users with Gmail or other non-organizational email addresses.
  2. Users whose email address is already associated with an existing personal Microsoft account.
  3. Users who do not have a Microsoft organizational/work account.

Our original authentication flow was designed to require Microsoft Authenticator / MFA. However, for some external users, especially those using Gmail or an email address associated with a personal Microsoft account, we are unable to apply the same authentication flow consistently.

We would like Microsoft’s guidance on the recommended and supported authentication configuration for this scenario.

Specifically, we would appreciate clarification on the following:

  • What is the recommended authentication method for external users with Gmail or other non-Microsoft organizational accounts?
  • How should users whose email address is already associated with a personal Microsoft account be handled?
  • Can all these users be onboarded as Microsoft Entra B2B guest users while maintaining a consistent authentication experience?
  • Can Microsoft Authenticator / MFA be enforced consistently for these different account types?
  • If Email One-Time Passcode (Email OTP) is used, can Require MFA be applied to these users, and what authentication method will satisfy the MFA requirement?
  • Are there any limitations regarding Authentication Strength policies when external users authenticate using Email OTP?
  • What Microsoft-recommended configuration would allow us to provide a secure and consistent authentication flow for all external contractors, regardless of their email provider or existing Microsoft account association?

Our objective is to implement a solution that is both secure and officially supported by Microsoft, while avoiding different or confusing login flows for different groups of external users.

We would appreciate your recommendation for the appropriate Microsoft Entra External ID / B2B configuration, including any relevant Conditional Access and MFA settings.

Thank you.

Best regards,

Idit Nevo

Microsoft Security | Microsoft Entra | Microsoft Entra ID

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Paul Thomas 80 Reputation points
    2026-11-04T11:55:15.4133333+00:00

    Adding to the earlier replies on your two follow-up questions,

    1. Matching the Entra identity to the CRM user: use the guest's object ID, not the email

    Since your CRM is the source of authorization and you invite every contractor, create the invitation from your onboarding process with Microsoft Graph (POST /invitations, permission User.Invite.All). The response returns the guest user object that was created in your tenant:

    "invitedUser": {
  "id": "cbb896f9-8306-49d0-b56b-b8e39cd28825",
  "userPrincipalName": "contractor_gmail.com#EXT#@yourtenant.onmicrosoft.com"
}

    Store invitedUser.id on the CRM record. When the contractor signs in to your app, the token issued by your tenant carries that same value in the oid claim, whichever way they signed in: Gmail through Google federation, Email OTP, or a personal Microsoft account. So match on oid (plus tid for your tenant).

    Don't match on the email or UPN claims. The address can differ from what's in the CRM, and the UPN of a guest is a generated #EXT# value.

    The same API also handles the "wrong account type" cases. If a contractor redeemed with the wrong identity, for example a personal Microsoft account instead of Email OTP, you can reset their redemption with "resetRedemption": true and the existing invitedUser.id. The object ID, and therefore your CRM link, stays the same.

    2. Which second factor does an Email OTP guest use?

    For guests who don't sign in with a Microsoft Entra work account (Email OTP, Google, and personal Microsoft accounts), MFA always happens in your tenant. With a Conditional Access policy that uses the Require multifactor authentication grant, the guest registers MFA in your tenant on first sign-in. Your tenant then challenges them on later sign-ins, using whichever of your enabled methods they register: Microsoft Authenticator push notifications, SMS, voice call or an OATH software token. The email code is their first factor and doesn't count as MFA.

    Two limits to plan for:

    • Authentication strength only applies to external users who sign in with Microsoft Entra ID. For Email OTP, SAML/WS-Fed and Google federation users, Microsoft says to use the MFA grant control instead.
    • Even for Entra guests completing MFA in your tenant, methods such as FIDO2 keys, Windows Hello and phone sign-in only count in their home tenant. So "Microsoft Authenticator (push) for everyone" is the method you can rely on across all contractor types.

    That gives you one consistent flow: CRM-approved contractor → Graph invitation (store invitedUser.id) → any supported sign-in → MFA registered in your tenant → app authorizes on oid against the CRM.

    Was this answer helpful?

    0 comments
  2. Idit Nevo 0 Reputation points
    2026-11-04T09:30:13.75+00:00

    Thank you for the detailed response.

    We would like to clarify one important point: all contractors who are allowed to access our application are already registered and approved in our CRM. There is no open registration or self-sign-up process. The CRM determines which users are authorized to access the portal.

    Given this setup, can you please confirm whether the recommended solution is still:

    CRM-authorized user → Entra B2B Guest → Email OTP as fallback → Conditional Access with “Require multifactor authentication”

    In particular, we would appreciate clarification on:

    For a user who is already registered in our CRM but authenticates using Email OTP, Gmail/Google, or a personal Microsoft account, what is the recommended way to ensure that the authenticated Entra identity is reliably matched to the existing CRM user?

    For an Email OTP guest, when Conditional Access requires MFA, what exact second-factor authentication method will the user be required to use, especially if they do not have an Entra organizational account?

    Our goal is for the CRM to remain the source of authorization, while Microsoft Entra provides the secure authentication and MFA layer.

    Can you please confirm that this is the correct and Microsoft-supported architecture for our scenario?

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-11-04T09:17:52.8966667+00:00

    A supported Microsoft Entra B2B design is to keep Email OTP as the fallback primary authentication method and apply a Conditional Access Require multifactor authentication grant to all B2B guests; the primary sign-in screen cannot be identical across Gmail, personal Microsoft, and organizational accounts because Entra routes each guest to the identity provider discovered during invitation redemption.

    This recommendation assumes the contractors are invited as B2B guests into a regular Microsoft Entra workforce tenant, rather than signing up as customers in an External ID external tenant.

    1. Continue inviting contractors as B2B collaboration guests.
      • The guest object contains no local credential; authentication is performed by the identity provider selected during redemption.
      • After redemption, the guest’s identity reflects Microsoft Account, Google, another external provider, or ExternalAzureAD for another Entra tenant.^1^
    2. Enable Email OTP as the fallback.
      • Go to Entra admin center → Entra ID → External Identities → All identity providers.
      • On Built-in, select Email one-time passcode → Configured.
      • Set Email one-time passcode for guests to Yes, then save.
      • Email OTP is used when the guest has no Entra account, personal Microsoft account, federated social identity, or other usable authentication method.^2^
    3. Create a Conditional Access policy for the application.
      • This requires Microsoft Entra ID P1 or P2.^3^
      • Go to Entra ID → Conditional Access → Policies → New policy.
      • Under Users or workload identities, include Guest or external users → B2B collaboration guest users.
      • Exclude emergency-access accounts.
      • Under Target resources, select the contractor application.
      • Under Grant, select Grant access → Require multifactor authentication.
      • Initially set the policy to Report-only, validate sign-ins, and then change it to On.^4^

    Do not select Require authentication strength for a policy intended to cover every contractor identity. Authentication-strength policies currently apply only to external users authenticating with Microsoft Entra ID. Email OTP, Google federation, SAML/WS-Fed, and personal Microsoft accounts must use the general Require multifactor authentication grant.^5^

    Expected sign-in behavior by account type

    Entra uses a documented redemption sequence, so these users can all be B2B guests but will not have the same primary sign-in journey:

    • External Entra work account: signs in through its home Entra tenant.
    • Personal Microsoft account: signs in using that existing Microsoft account.
    • Gmail account with Google federation enabled: redirects to Google.
    • Gmail or another address without a usable account or configured federation: receives Email OTP.
    • If an address matches both an Entra account and a personal Microsoft account, the user is prompted to choose which account to use.^6^

    Email OTP is therefore the first-factor identity proof for an Email OTP guest. When Conditional Access subsequently requires MFA, the resource tenant evaluates and issues the additional MFA challenge; completing the email code alone does not remove the Conditional Access requirement.^7^

    Microsoft Authenticator can be used for MFA events, including notifications and verification codes.^8^ However, this design cannot use an authentication-strength policy to force Authenticator specifically for Email OTP, Google, or MSA guests. The supported cross-account control is Require multifactor authentication, with the actual available challenge determined by the guest’s identity and applicable authentication-method configuration.

    Consequently, an Email OTP guest can see two verification steps:

    1. Email OTP to perform primary authentication.
    2. A separate MFA challenge required by Conditional Access.

    That is expected rather than duplicate MFA. Disabling Email OTP would avoid that particular first-factor flow, but users without another identity would instead be required to create a personal Microsoft account; existing OTP guests might also need their redemption status reset before they can sign in another way.^2^

    Improve consistency where possible

    • Use tenant-specific application links so users enter the correct resource-tenant context.
    • Enable Google federation if redirecting Gmail users to Google is preferable to Email OTP. It changes the primary sign-in journey but does not remove the need for the MFA grant.
    • Configure redemption order under Entra ID → External Identities → Cross-tenant access settings → Default settings → Inbound access settings → B2B collaboration → Redemption order. This requires at least Security Administrator.^9^
    • For trusted partner organizations with Entra tenants, optionally accept their home-tenant MFA claims through inbound cross-tenant trust. If trust is disabled, B2B collaboration users satisfy MFA in the resource tenant instead.^5^
    • Pilot with test identities representing Entra, MSA, Gmail, and Email OTP before enabling the policy. Review Conditional Access results and registration behavior in report-only mode.

    If the requirement is not merely consistent policy but an identical branded sign-up/sign-in journey with tenant-controlled local identities, evaluate an External ID external tenant separately. Its customer-user-flow MFA methods and behavior differ from workforce B2B and should not be mixed into this guest configuration.

    References

    1. Understand and manage the properties of B2B guest users
    2. Email one-time passcode authentication for B2B guest users
    3. Tutorial: Enforce multifactor authentication for B2B guest users
    4. Require multifactor authentication for guest access
    5. Require multifactor authentication strength for external users
    6. B2B collaboration invitation redemption
    7. Authentication and Conditional Access for External ID
    8. Authentication methods in Microsoft Entra ID - Microsoft Authenticator app
    9. Manage cross-tenant access settings for B2B collaboration
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.