SharePoint OTP Retirement: Simple Entra B2B Guide

• MC 1243549 retires legacy SharePoint OTP, but Entra B2B email OTP still exists as fallback.
• From May 2026 rollout onward, EnableAzureB2BIntegration no longer controls behavior in migrated tenants.
• Gmail users should use Google sign-in only after Google is configured as an Entra identity provider.
• Different tenants may show different sign-in behavior during phased rollout.
• Custom Google Workspace domains usually need SAML or WS-Fed federation, not built-in Google IdP.
• Run pilot testing before August 31, 2026 to prevent external access disruption.

Microsoft 365 Message Center notification MC 1243549 has made one topic suddenly urgent for SharePoint and OneDrive administrators: external user sign-in behavior is changing. Many teams read the headline and assume one thing only: "OTP is being removed." That is incomplete, and in some cases misleading. What Microsoft is retiring is the legacy SharePoint Online One-Time Passcode (OTP) experience. What remains available is Microsoft Entra B2B email one-time passcode, which can still appear as a fallback in the Entra B2B invitation redemption flow when no supported identity provider matches the invited user.

This guide explains the change in plain language, with practical examples and no jargon-heavy assumptions. If you are the person who gets escalation tickets that begin with "External user cannot open the file we shared," this article is for you. If you are a solution architect preparing governance standards for multiple tenants, this article is also for you. The goal is simple: help you understand exactly what changed, what action is needed, and how to prevent avoidable disruption as we move through 2026.

One-minute summary in plain English

For years, some external users accessed SharePoint and OneDrive links through a legacy OTP flow tied to SharePoint itself. Microsoft is now standardizing this experience under Microsoft Entra B2B collaboration. That means external users are expected to redeem invitations through Entra's identity routing process instead of the old SharePoint-specific mechanism.

The practical effect is not "everyone loses OTP." Instead, the sign-in experience becomes more identity-aware. A user from another organization may sign in with their work account. A personal Microsoft account user may sign in with MSA. A Gmail user may sign in through Google if you configure Google federation. If none of those paths apply and your tenant allows it, Entra B2B email OTP can still be used as the fallback method.

Chronology: what happened and when

The timeline matters because many organizations compare behavior across tenants and conclude something is wrong when outcomes differ. In reality, phased rollout means one tenant can look modern while another still appears "old" for a short period.

What exactly changes for external sharing

At a high level, the change is a move from a SharePoint-owned authentication experience to an Entra-owned collaboration identity experience. This sounds abstract, so here is the operational version: when an external user clicks a sharing link, Entra B2B now decides how that user authenticates based on available identity options and tenant configuration.

Common authentication outcomes after the transition

• Home organization account: external users from another Entra tenant generally use their work or school account.
• Microsoft account: Outlook.com/Hotmail/Live users sign in with Microsoft account credentials.
• Google sign-in: Gmail/Googlemail users can be redirected to Google if Google is configured in Entra External Identities.
• Email OTP fallback: if no supported identity provider applies and tenant policy allows it, Entra B2B email OTP can be presented.

The end-user experience therefore becomes more predictable when identity provider configuration is done correctly. If it is not configured, behavior can still work, but often through fallback paths you did not intend, which can make troubleshooting and user guidance harder.

The setting everyone asks about: EnableAzureB2BIntegration

One of the biggest points of confusion is the historical tenant setting EnableAzureB2BIntegration. In earlier phases of the platform journey, this setting was often discussed as the switch that influenced external auth behavior. With the 2026 rollout, Microsoft has indicated that once integration is applied to a tenant, this old control no longer acts as the main behavior gate it used to be.

This is a pattern we see often in Microsoft 365 modernization: old controls remain visible for a period while underlying architecture moves forward. For support teams, this means checking both configuration and live behavior, not configuration alone. The most reliable source of truth is still a controlled test invite with known user identities.

Why Google identity provider setup is now urgent

One task that often gets deferred is configuring Google as an identity provider in Entra External ID, and right now it deserves priority. For many organizations, the largest group of external collaborators is still Gmail-based consultants, vendors, and partner staff. Without Google federation configured, those users can fall into alternate paths, including Entra email OTP fallback, depending on tenant setup and user account profile.

That fallback may technically work, but it is not always the smoothest or most consistent user experience, especially when your help desk scripts tell users to "sign in with Google" while the user sees a passcode prompt instead. Aligning configuration with expected user behavior reduces confusion dramatically.

What changes after Google IdP is configured

• Invited users at @gmail.com and @googlemail.com are typically redirected to Google sign-in during redemption.
• Users should redeem with the same account that received the invite; mismatched accounts cause common failures.
• If a user redeemed previously with another method, you may need to reset redemption state before retesting policy behavior.

Step-by-step: configure Google federation in Entra External ID

The process has two sides: Google Developer configuration and Entra identity provider configuration. The order matters. Build the Google OAuth app first, then enter its values in Entra.

Part A: create and configure Google OAuth app

1. Open the Google Cloud Console and create a new project dedicated to Entra B2B federation.
2. Configure the OAuth consent screen and include the authorized domain microsoftonline.com.
3. Create OAuth credentials with application type Web application.
4. Add authorized redirect URIs:
   • https://login.microsoftonline.com
   • https://login.microsoftonline.com/te/<tenant-id>/oauth2/authresp
   • https://login.microsoftonline.com/te/<tenant-name>.onmicrosoft.com/oauth2/authresp
5. Copy the generated Client ID and Client Secret securely.

Part B: configure Google provider in Entra admin center

1. In Entra admin center, go to External Identities then All identity providers.
2. Select Google, enable it, and paste the Client ID and Client Secret from the Google Cloud Console.
3. Save and validate configuration by sending a controlled invite to a test @gmail.com account.
4. Document the setup date, owner, and credential rotation plan in your tenant runbook.

Custom Google Workspace domains: common trap

One of the biggest real-world confusion points is this: "We configured Google, why is [email protected] not redirected to Google?" If that custom domain is hosted in Google Workspace, the built-in Google identity provider in Entra does not always handle it the same way as @gmail.com and @googlemail.com. Microsoft documentation typically points to SAML/WS-Fed identity provider federation for custom domains.

In other words, built-in Google federation is not a universal "all Google-hosted mail" switch. It is focused on consumer Google identities. For enterprise-like custom domains on Google Workspace, plan dedicated federation architecture and testing.

Testing strategy before production communication

Do not announce "all external access updated" until you run controlled invitations against identity personas that represent your actual partner ecosystem. The right test matrix is simple and usually catches hidden issues in under one hour.

Redemption reset when testing new behavior

If a user already redeemed a guest invitation using an older path, you may not see the new expected sign-in route immediately. In those situations, administrators commonly reset invitation redemption state (or remove and re-invite the guest) to test the updated authentication experience cleanly. Always perform this in a controlled test cycle first, not on active client accounts during business hours.

PowerShell quick checks for admin teams

For teams that prefer the command line, here are practical snippets to use for pre-checks and audit context. These are not the only commands you need, but they are useful sanity checks before and after rollout windows.

Connect-SPOService -Url https://<tenant>-admin.sharepoint.com

Get-SPOTenant | Select-Object `
  SharingCapability, `
  DefaultSharingLinkType, `
  RequireAnonymousLinksExpireInDays, `
  EnableAzureB2BIntegration

This output helps you understand your external sharing baseline and record state during change windows. Remember, in migrated tenants, the legacy integration setting may no longer fully control behavior. Use it as context, not as your only decision source.

Get-SPOSite -Limit ALL |
  Select-Object Url, SharingCapability |
  Sort-Object Url

This lets you identify sites that are more permissive than expected. If your organization plans to tighten collaboration models during the Entra transition, this report is often your fastest cleanup starting point.

Get-SPOSite -Limit ALL |
  Select-Object Url, Owner, SharingCapability, LastContentModifiedDate |
  Export-Csv .\spo-sharing-review.csv -NoTypeInformation -Encoding UTF8

Operational plan you can use immediately

Most organizations do better with a short, staged plan than a large migration project. The change itself is platform-driven by Microsoft, so your job is readiness, communication, and exception handling.

Stage 1: tenant readiness (week 1)

• Confirm external sharing policy and high-risk site exceptions.
• Configure Google identity provider if Gmail/Googlemail collaboration is common.
• Create or refresh test identities for Entra, MSA, Gmail, and fallback domains.
• Document expected sign-in path per identity type for service desk reference.

Stage 2: pilot and support prep (week 2)

• Run invitation and redemption tests using real sharing scenarios (file link, folder link, site access).
• Capture screenshots for support runbook: what users should see at each step.
• Update help desk templates to distinguish legacy OTP from Entra B2B fallback OTP.
• Define escalation path for guest redemption reset requests.

Stage 3: broad communication (week 3)

• Send concise internal message to site owners and project leads.
• Share external-facing "what to expect" note for vendors and client contacts.
• Provide one support mailbox and one fallback owner for urgent collaboration outages.

Stage 4: post-change observation (week 4 and onward)

• Track ticket volume related to "cannot access shared content" by domain type.
• Review redemption failures and identify recurring user behavior issues.
• Tune documentation and templates, especially for users who redeem with wrong account identities.

Troubleshooting playbook: fastest path to root cause

When external sharing breaks, teams often jump straight into tenant-wide setting changes. That usually makes things worse because the failure is commonly user-level identity mismatch, not a platform outage. A better approach is a short triage sequence that isolates what failed: invitation routing, identity redemption, or post-redemption authorization.

First five checks for service desk

1. Verify invited email address: confirm the user is attempting sign-in with the exact invited address, not an alternate personal or corporate identity.
2. Check expected auth path by domain: for example, Gmail should usually route to Google sign-in if Google IdP is configured.
3. Use clean browser session: stale sessions are one of the top causes of wrong-identity redemption prompts.
4. Validate invitation state: was the guest already redeemed previously with a different method?
5. Confirm content permission: successful redemption does not guarantee file or site authorization.

These checks resolve a large portion of incidents without tenant-wide policy changes. If they fail, escalate with concrete facts: invited email, observed sign-in prompt, timestamp, target URL, and expected identity path. Escalations with those five data points are much faster to resolve than generic "external user cannot access" tickets.

Tenant rollout worksheet for consulting teams

If you manage multiple client tenants, consistency matters more than speed. Use a lightweight worksheet so each tenant is assessed using the same logic. This avoids "hero admin" decisions that work once and fail at scale.

Recommended worksheet fields

• Tenant name and primary admin contact
• Top external domains by volume (last 90 days)
• Expected identity path per domain (Entra, MSA, Google, fallback)
• Google IdP status (Not required, Pending, Configured, Validated)
• Custom domain federation required (Yes/No + owner)
• Pilot test completion date and issue summary
• Business communication sent date
• Support readiness owner and escalation path

With this worksheet, you can run weekly reviews and quickly identify which tenants are at risk before the retirement deadline. It also helps leadership teams understand that this is not just a technical task. It is a coordination task between identity admins, SharePoint admins, support teams, and business stakeholders who frequently share with external contacts.

A useful maturity checkpoint is simple: if your service desk can correctly explain why one user sees Google sign-in and another sees email OTP fallback without escalating to engineering, your rollout documentation is strong. If they cannot, keep refining the domain-path matrix and troubleshooting guide until they can.

Direct answers to common admin questions

1) Do we need to do this for every client?

The platform transition is Microsoft-led across tenants, but Google identity provider setup is tenant-specific. So the answer is: the rollout happens everywhere, but your configuration actions still happen per tenant. If a tenant expects Gmail users to authenticate via Google sign-in, that tenant must configure Google in Entra External Identities.

2) Is Google identity provider setup one-time?

Usually yes. It is generally a one-time tenant-level setup that then supports future B2B invitation redemption flows. Operationally, treat it as one-time foundation plus ongoing maintenance: secret rotation, periodic test redemption, and documentation review.

3) Why do other tenants still look like OTP is active?

Because rollout is phased and identity resolution is contextual. One tenant may already be moved to new behavior, another may still be in transition. Also, seeing an OTP prompt does not always mean old SharePoint OTP is still in control; it may be Entra B2B email OTP fallback for a user with no matching supported identity path.

4) What about Yahoo and similar domains?

If users do not have Entra, Microsoft account, Google federation match, or another configured IdP, Entra B2B email OTP can be used as fallback if enabled in your tenant. This is why your support playbook should include a domain-to-expected-auth map rather than a one-line rule.

5) What about corporate custom domains hosted on Google Workspace?

Do not assume built-in Google provider automatically covers them. Microsoft guidance generally points to SAML/WS-Fed federation for custom domains. Plan this separately from Gmail consumer identity handling.

Simple explanation for business stakeholders

If you need to explain this to non-technical leaders, use this version:

That short message avoids unnecessary technical details while still preparing people for visible sign-in changes.

Communication template you can send internally

Subject: External sharing sign-in update for SharePoint and OneDrive

Microsoft is updating external access authentication for SharePoint and OneDrive.

What changes:
- Legacy SharePoint one-time passcode flow is being retired.
- External access now uses Microsoft Entra B2B invitation redemption.

What this means for users:
- Some external users may see a different sign-in prompt than before.
- Users must redeem invitations with the same email account that was invited.

For Gmail users:
- We are enabling Google sign-in support in Entra External Identities.

Support:
If an external collaborator cannot access a shared file or site, contact
<support mailbox> with the invitee email address and URL.

Mistakes to avoid during this transition

• Treating all OTP prompts as legacy behavior: some OTP prompts are valid Entra fallback, not rollback failures.
• Testing with previously redeemed guests only: old redemption state can mask new expected behavior.
• Skipping Google setup while expecting Google UX: without tenant configuration, Gmail flows may not route as expected.
• Communicating too late: even technical changes need user guidance to avoid avoidable access tickets.
• Assuming one tenant experience equals all tenants: phased rollout means temporary variation is normal.

Final checklist before August 31, 2026

1. Review external sharing policy and high-risk sites.
2. Configure Google IdP if Gmail collaboration is required.
3. Test invitation redemption for all major identity personas.
4. Update help desk script with expected auth path by domain type.
5. Prepare fallback process for redemption reset and re-invite.
6. Publish short communication for internal owners and external partners.

If you complete these six items, you are in a strong position for a smooth transition. Most post-change incidents then become user guidance issues instead of platform incidents.

Reference links

• Microsoft Learn: Microsoft Entra B2B integration for SharePoint and OneDrive
• Microsoft Learn: Improvements to external sharing in OneDrive and SharePoint
• Microsoft Learn: B2B collaboration invitation redemption
• Microsoft Learn: Email one-time passcode authentication
• Microsoft Learn: Google federation with Microsoft Entra B2B