Table of Contents
Change Applies on July 1 to Tenants that Integrated SharePoint with Entra ID B2B Collaboration
The announcement in message center notification MC1089315 (6 June 2025) that Microsoft is dumping the old one-time passcode (OTP) authentication mechanism for SharePoint Online and OneDrive for Business sharing is unexpected, but only because it took Microsoft so long to make the change.
After July 1, 2025, external users who have received a sharing link from a user in a tenant that uses OTP authentication will discover that they have lost access to the shared content (files, folders, or sites). Microsoft says that they’re making the change to “enhance security.” I think this is correct, and the change delivers an additional benefit to Microsoft because it gets rid of an old feature.
A History of One-time Passcodes in SharePoint Online
OTP-based sharing links (aka, the “Secure external sharing recipient experience”) predates the support of Entra ID B2B Collaboration (guest accounts) within SharePoint Online. That support arrived as a result of guest access to Office 365 groups (now Microsoft 365 groups) in September 2016. Guest accounts took a while to catch on, and Office 365 groups only became really popular after the advent of Teams in early 2017. Indeed, Teams didn’t surpass 20 million active users in November 2019 before massive growth occurred in Teams usage during the Covid-19 pandemic.
Although Teams growth propelled similar growth in groups and SharePoint usage, there was no great push to move tenants off OTP authentication to SharePoint and OneDrive integration with Azure AD (now Entra ID). External sharing worked, so why bother?
Microsoft began the process to get off OTP by integrating OTP with Entra ID B2B Collaboration in October 2021. Essentially, the change ensured that external users who received OTP sharing links had guest accounts created for them in the tenant directory. The next step made sure that new tenants created after March 31, 2023, could only use B2B collaboration.
The plan now revealed “only impacts organizations that have already enabled or plan to enable SharePoint and OneDrive integration with Microsoft Entra B2B.” In other words, nothing changes for tenants that did not link SharePoint Online and OneDrive for Business to Entra ID B2B Collaboration. I wonder what proportion of the SharePoint community still use one-time passcodes exclusively for sharing.
The Result of the Change
MC1089315 rates this change to be “highly relevant.” In other words, it will affect how users work because:
- After July 1, all new sharing links generated for external people will use Entra ID B2B Collaboration and the sharees will receive email containing the sharing link generated by the Entra ID Invitation Manager service. This shouldn’t cause too much upheaval because the process is reasonably painless. I use it all the time to share documents with several other Microsoft 365 tenants and haven’t had any issues with sharing links that I can remember.
- After July 1, all previously issued sharing links based on one-time passcodes generated by SharePoint Online and OneDrive for Business will stop working. Obviously, this aspect of the change could cause confusion when a link sent to users doesn’t work. July 1 is a Tuesday, and it’s entirely possible that many sharing links with one-time passcodes arrive in user mailboxes on Monday, June 30. If the recipients action the links immediately, they can access the shared content. If they delay, the links stop working. It’s as simple as that.
Microsoft says that users will be told “Sorry, something went wrong. This organization has updated its guest access settings. To access this item, please contact the person who shared it with you and ask them to reshare it with you.” What’s gone wrong is that Microsoft decommissioned one-time passcodes. However, the statement is accurate that the only way to resume access to the shared content is to receive a new sharing link generated based on B2B collaboration. The potential for impact on users and the knock-on effect on help desks is clear.
MC1089315 notes that users will be required to complete multi-factor authentication (MFA) registration as part of the Entra ID B2B onboarding process. That’s strictly only true if the tenant that hosts the content requires MFA, most likely with a conditional access policy to block access unless an MFA challenge is satisfied. Even if your tenant doesn’t use MFA today (which it should), it is the hosting tenant that gets to choose whether MFA is required.
A Good Change
I bet this change will cause confusion and some upheaval in the weeks after July 1. After that, everything should calm down as the old OTP-based sharing links work their way out of the system. It’s good to have consistency and security and having one method to secure sharing links seems like a good change to make. At least, it is in my book.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.
Almost had a heart attack reading your post, but thankfully “This change only impacts organizations that have already enabled or plan to enable SharePoint and OneDrive integration with Microsoft Entra B2B.” which is not my case 🥵
This makes me think that Microsoft will someday force all tenants to move to Entra ID B2B for Sharepoint and OneDrive sharing… Thus forcing tenants to allow users to invite Entra ID guests whenever they want to share some OneDrive file ?
That’s actually annoying for my org. We disabled anonymous OneDrive sharing (thus making the email OTP mandatory), and disabled the ability of any user to create guests users (we have a custom process in Coreview for that, that user have to request separately, when they want to invite some external user to a specific team or Sharepoint site). I guess if we want to move Sharepoint Online external access to Entra ID B2B we’ll have to allow all users to invite guests (at least for OneDrive sharing) ? Then they’ll be able to invite anybody in their teams, without using our custom process, right ?
I don’t think so… It’s easy to test, but there’s something in the back of my mind that says that SharePoint and OneDrive use a different process to the one where Teams invites users.
I think you’ve misunderstood this change – Microsoft is not dumping the old process at all. This change is only for tenants who have enabled the B2B OTP setting (Set-SPOTenant -EnableAzureADB2BIntegration $true) or will do in the future.
The change is that once a tenant optionally enables SharePoint/OneDrive B2B OTP integration, all previous SharePoint OTP links will immediately stop working.
If a tenant does not enable the integration, then nothing changes, and the old SharePoint OTP method will still work.
Well, I might be taking a certain liberty with the title to drive awareness of an important change that is being implemented in 3 weeks time, but I’ll take that on the chin.
The text clearly says that the change only applies to tenants that have implemented the B2B integration with SPO. I just wonder how many tenants use “pure” OTP…
But because I’m a nice guy, I changed the opening H2 to emphasize the point.
Would anybody happen to know how to check if a tenant has enabled SPO/OD B2B OTP integration? I honestly haven’t the slightest idea whether my two tenants have this enabled or not, and while I’ve found the cmdlet to enable/disable it, can’t seem to figure out how to determine whether or not it’s enabled in the first place.
Hi Joseph,
You can check with the “Get” version of the Cmdlet that allows you do enable/disable the feature.
PS> Get-SPOTenant | Select-Object EnableAzureADB2BIntegration
EnableAzureADB2BIntegration
—————————
False
Connect-SPOService -Url https://-admin.sharepoint.com
Get-SPOTenant | Select *B2B*
Thank you both! I was on the right track but somehow managed to fat-finger it.
Regarding my previous question, here’s what I found in Microsoft’s documentation :
Advantages of Microsoft Entra B2B include: […] SharePoint and OneDrive sharing is subject to the Microsoft Entra organizational relationships settings, such as Members can invite and Guests can invite. […]
Source : https://learn.microsoft.com/en-gb/sharepoint/sharepoint-azureb2b-integration
I guess that’s the tenant wide “Guest invite settings”, and that would be problematic in the scenario I described (forced to allow anyone to invite guests, including in Teams, to allow external (but not anonymous) sharing in OneDrive), but it’s not very clear…
The easy way to control guests is:
1. Implement a B2B Collaboration policy to limit the domains guests can come from: https://office365itpros.com/2021/05/10/entra-id-b2b-collaboration-policy/
2. Block guest access to specific teams/groups https://office365itpros.com/2018/11/04/block-guest-access-to-teams/
3. Use sensitivity labels to block guest access to confidential files shared in Teams.
Sadly first one is not an option (many guests with hotmail or Gmail email adresses, also nominative OneDrive external file sharing could/should be less restricted than guest access in my opinion), neither is last one (currently my org does not have the required license for all its users + we’re not at that stage of deployment (currently deploying Teams teams, yet we could discuss which one’s the prerequisite for the other one 😅)).
But second one is an interesting path, I’ll check that, tank you very much for your post and answers ! 🙂
Hello Tomi
few more details, hope these assumptions are correct what we found, can you please confirm?
in case organizations use Azure B2B invitation manager (tenant SharePoint admin sharing settings – existing guests only) then these links are not impacted
only links which are created by SharePoint / ONB via old b2b invitation manger is impacted (tenant sharing settings – New and Existing guests)..
Entra ID integration with SharePoint Online and OneDrive for Busines operates OTP for sharees that don’t have an existing guest account “Authentication happens via one-time passcode when they don’t already have a work or school account or a Microsoft account.” : https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration. “Azure B2B Invitation Manager one-time passcode feature allows users who don’t have existing Work or School accounts or Microsoft Accounts to not have to create accounts to authenticate, but can instead use the one time passcode to verify their identity.”
If a file is shared with a guest account that’s able to authenticate, then OTP isn’t used and the links aren’t affected. If you’re using guest accounts to share files etc. with other Microsoft 365 tenant accounts, they aren’t affected.
The MC1089315 has been updated on 13th and there’ no mention of OTP anymore? It just say “Your external users will lose access to all the files, folders and sites shared before enabling this integration.” What happened to automatic conversion of guests/shares, which was previously mentioned in the learn doc, but now not mentioned at all (doc updated on 13th as well).
https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration
Microsoft is truly an interesting and bewildering organization sometime…
Reading MC1089315 (revised version), it seems like they have broadened the description so that ALL sharing links created prior to enabling B2B collaboration for SharePoint Online are invalidated. That’s the way I read the text.
Hi, What will happen to the links shown under ‘Manage Access’? The emails of previously shared users still appear, even though the links are no longer accessible, which may confuse users
I believe that new sharing links will be required. However, as I don’t have any of the old links around in my tenant (I switched years ago), I cannot test to verify.
In our tenant, we enabled B2B integration about two months ago, and we can still see all the previously shared links under Manage Access.
Scenario:
An external user asks an internal user for access to a file. The internal user checks and replies, “You already have access — your email appears under the sharing links.”
However, in reality, the link is no longer functional, and the external user cannot open the file.
This situation creates confusion, as the sharing links and emails are still visible even though the access is not valid anymore.
Yep. That could be confusing… but I don’t think the old links work anymore. Easy to test, though. And if the situation is as I think it is, it’s time for some user education.
In my org we’ve managed to recreate the retired one-time passcode (OTP) authentication mechanism for SharePoint Online and OneDrive into the new Microsoft Entra B2B requirement (yes, we have SharePoint and OneDrive integration with Microsoft Entra B2B enabled long ago prior the change). The following is an AI summary of the steps we took in order to recreate it – they are a lot and was easier to use AI (sorry!) to compile them. I’ve read it before posting, so it seems adequate. Also I found this site via AI (haha). So brace yourselves for the long post (hope will help someone):
Preserving the Email OTP Experience After SharePoint OTP Retirement
When Microsoft announced MC1243549 — the retirement of SharePoint One-Time Passcode (SPO OTP) in favour of Entra B2B integration — the immediate concern for many IT admins was not the architecture change itself, but the user experience. The old SPO OTP flow was simple: share a link, the recipient gets a code to their inbox, done. No accounts, no MFA registration, no friction.
With the forced B2B migration rolling out from May 2026 and full retirement scheduled for July 2026, we went through the process of reconfiguring our tenant to get as close to that original experience as possible. This post documents what we changed, what broke, and what the final working configuration looks like.
What Actually Changed
The old SharePoint OTP flow was a standalone identity mechanism that bypassed Entra ID entirely. When you shared a file with an external person, SharePoint generated a time-limited passcode and emailed it to them. The recipient never appeared in your Entra directory — no guest account, no governance, no Conditional Access.
The new model is fundamentally different. Every external share now triggers the Entra B2B Invitation Manager, which:
Creates a guest account in your Entra directory (user_domain.com#EXT#@yourtenant.onmicrosoft.com)
Sends the sharing notification
Routes authentication through your tenant’s identity provider stack and Conditional Access policies
The good news: Entra B2B does support Email OTP as an authentication method for guests — it’s built in. The challenge is that several default or pre-existing settings in most tenants will block, intercept, or complicate that flow before the guest ever gets a code.
The Errors We Hit
The first thing we encountered when testing external sharing after the migration kicked in was this:
At least one invitation failed. Error: ResponseStatusNotOK, message: Guest invitations not allowed for your company.
This was not a SharePoint setting problem — the external sharing sliders in the SharePoint admin center were correctly configured. The error originated from Entra ID, specifically from the Guest Invite Settings in External collaboration settings being set to “Only users assigned to specific admin roles can invite guest users”. Under the old SPO OTP model, this setting was irrelevant — SharePoint never called the Entra Invitation Manager. Under B2B, every external share is an invitation, so this policy now blocks regular users from sharing externally entirely.
The second issue appeared when we fixed the invite settings and successfully shared a test link to a Gmail account. The guest received the sharing email, clicked the link, entered their email — and then hit:
More information required — Your organisation needs more information to keep your account secure.
Followed shortly by:
Sign-in couldn’t be completed. Please contact your administrator for help.
This was a Conditional Access policy requiring MFA via Authentication Strength targeting all users, including guests. The guest could not register an MFA method because the CA policy blocked access before registration could complete — a classic catch-22.
The Configuration Changes
Here is what we changed, in the order we changed it, along with the reasoning behind each decision.
1. Guest Invite Settings
Location: Entra admin center → External Identities → External collaboration settings → Guest invite settings
Changed from: Only users assigned to specific admin roles can invite guest users
Changed to: Member users and users assigned to specific admin roles can invite guest users
Why: Every OneDrive/SharePoint external share now calls the Entra B2B Invitation Manager. Restricting invitations to admin roles effectively blocks all external sharing for regular users. Note: we deliberately chose the option without the “including guests with member permissions” tail — that variant modifies the authorizationPolicy object in ways that can have unintended side effects on other authentication policies in the tenant.
2. Redemption Order — Disable Social Providers and MSA
Location: Entra admin center → External Identities → Cross-tenant access settings → Default settings → B2B collaboration → Redemption order
Changes made:
Social providers (Google, Facebook): Disabled
Microsoft Account (MSA): Disabled
Email one-time passcode: Confirmed enabled (fallback)
Why: When Social providers is enabled without Google federation being properly configured, a Gmail address triggers the Google identity provider path — which then fails, and the guest never reaches the Email OTP fallback. By disabling Social providers, Gmail and other personal email guests fall through cleanly to Email OTP.
MSA was disabled for a similar reason: a personal email address that happens to be linked to a Microsoft Account (even without the guest knowing) would be routed through MSA authentication, which then collides with the MFA CA policy requiring a second factor that the guest cannot register. Disabling MSA forces those guests to Email OTP instead.
Importantly, disabling both of these does not affect work/school account guests from other Entra tenants — they match the Microsoft Entra ID primary identity provider, which sits above both MSA and Social in the redemption order and cannot be disabled.
3. Email OTP — Verify Both Locations
Email OTP needs to be enabled in two separate places, for two separate purposes:
Location 1: Entra admin center → External Identities → All identity providers → Email one-time passcode → Yes
This enables Email OTP as an identity provider in the B2B redemption flow — i.e., the mechanism that lets guests authenticate by receiving a code to their external inbox.
Location 2: Entra admin center → Authentication methods → Policies → Email OTP → Enabled, targeting guest users group
This enables Email OTP as a registered authentication method for guests within the tenant. Both need to be on.
4. Trust MFA from Microsoft Entra Tenants
Location: Entra admin center → External Identities → Cross-tenant access settings → Default settings → Trust settings
Change: Enable Trust multifactor authentication from Microsoft Entra tenants
Why: For guests who come from other Entra tenants (work/school accounts), their organisation may have already challenged them for MFA before they clicked your sharing link. Without this trust setting, your tenant ignores that and demands MFA registration again — causing the same catch-22 as above. With it enabled, a satisfied MFA claim from the guest’s home tenant is accepted by your Conditional Access policy.
This setting has no effect on Email OTP guests (Gmail, personal email) — there is no Entra tenant on their side to issue an MFA claim.
5. Conditional Access — Exclude Guests from Existing MFA Policies
Location: Entra admin center → Conditional Access → [existing MFA policies]
Any CA policy that targets All users with an Authentication Strength requirement (Multifactor authentication, Phishing-resistant MFA, etc.) will block Email OTP guests. Authentication Strength policies explicitly do not support Email OTP — guests authenticated via Email OTP cannot satisfy an Authentication Strength grant, and will be prompted to register Authenticator instead.
We excluded B2B collaboration guest users from our existing MFA policies:
Users → Exclude → Guest or external users → B2B collaboration guest users selected
This is the subtype created by OneDrive/SharePoint external sharing — the other five subtypes (B2B direct connect, local guest, service provider, etc.) are not relevant to this use case and were left as-is.
6. Conditional Access — New Guest-Specific Policy
Location: Entra admin center → Conditional Access → New policy
Target: Guest or external users → B2B collaboration guest users — we targeted only this subtype since it is the one created by OneDrive/SharePoint external sharing. We used the built-in user type selector rather than a dynamic group, to avoid group membership lag for newly created guest accounts.
Grant: Grant access — no MFA requirement
Why no MFA? This is the part that requires the most explanation. Email OTP is used as the sign-in method (first factor) for guests without a work/school account. If a CA policy then requires MFA as a second factor on top of that, Entra cannot use Email OTP again for the second factor — it has already been consumed as factor 1. The result is that Entra falls back to prompting Authenticator installation, which is exactly what we were trying to avoid.
The pragmatic decision here is that Email OTP sign-in already verifies possession of the recipient’s inbox — this is functionally equivalent to email-based OTP MFA. For the use case of accessing a shared OneDrive folder or SharePoint site, this is an acceptable authentication posture. The access is scoped to specific shared resources, not broad tenant access.
For work/school account guests from other Entra tenants, the Trust MFA from Microsoft Entra tenants setting (step 4 above) handles MFA enforcement at the home tenant level, so those guests are not left without MFA protection.
The Final Guest Authentication Flow
After all changes, the flow for different guest types is:
Gmail or other personal email (no Microsoft account):
Receives sharing link → clicks it
Enters email address
Receives 6-digit OTP to their inbox
Enters OTP → access granted ✅
Work/school account from another Entra tenant:
Receives sharing link → clicks it
Signs in with their corporate credentials at their home tenant
If home tenant has MFA, they complete it there
Your tenant accepts the MFA claim (Trust MFA setting)
Access granted ✅
Personal outlook.com / hotmail account:
Same as Gmail path → MSA disabled → falls through to Email OTP ✅
What This Does Not Solve
This configuration recreates the authentication experience of the old SPO OTP flow, but the underlying model is fundamentally different. There are implications to be aware of:
Guest accounts are now created in your directory. Every external share creates a #EXT# guest object in Entra. These need lifecycle management — without access reviews or expiration policies, your directory will accumulate stale guest accounts over time.
Previously shared links may need resharing. Guests who accessed content via old SPO OTP links and do not yet have an Entra B2B guest account will encounter access denied errors. Microsoft’s FAQ notes that if a guest already has a B2B guest account, existing links continue to work — but guests who only ever authenticated via SPO OTP will need a fresh share.
The no-MFA grant for guests is a policy decision, not a technical limitation. Some organisations will prefer to require guests to register Authenticator once as a recurring partner onboarding step, accepting the initial friction in exchange for stronger assurance. The configuration above prioritises frictionless access for one-time or infrequent external collaborators.
References
MC1243549 — Retirement of SharePoint One-Time Passcode
Microsoft Entra B2B integration for SharePoint & OneDrive
FAQ on improvements to external sharing in OneDrive & SharePoint
Configure external collaboration settings
Authentication and Conditional Access for B2B users
Require MFA for guest access
One-time passcode authentication
SharePoint Online Dumps OTP for Entra ID B2B Collaboration — Office 365 for IT Pros
Thanks for taking the time to research the OTP issue!
Thanks for posting this. Alas, it being AI generated, not every bit was quite correct. I followed it in my tenant and would like to make a couple of corrections/clarifications for anyone that might benefit in the future
First, in Step 2 there is a menu level missing. It’s Redemption Order — Disable Social Providers and MSA
Location: Entra admin center → External Identities → Cross-tenant access settings → Default settings → (ADDING Inbound Access Settings) ->B2B collaboration → Redemption order
Second, under final authentication flow for a personal e-mail, it’s actually an 8-digit PIN, not 6 digits. Also and perhaps more importantly, after entering the OTP, the first time the external user connects to the tenant they must accept a Permissions request allowing the tenant to receive profile data and collect and log activity. It will be interesting to see how our external recipients handle this because some might be confused by the request or perhaps even object to accepting it, in which case I guess they’re not going to receive their file.
You’re absolutely right in your observations, thanks for mentioning them.
Also some additions that i noticed afterwards:
– when a guest opens a link for a first time (the guest doesn’t exist as an user in Entra before that) the flow asks them to sign in (meaning just to enter their e-mail) before getting the notification to accept the Permissions and the next one that they need to place the 8-digit PIN. Don’t remember if it was the same in the legacy experience. The sign-in part is a bit confusing, but at least now it doesn’t trigger the flow of creating an MSA account and/or registering through Microsoft Authenticator.
– In step 3 for Location 2: Entra admin center → Authentication methods → Policies → Email OTP → Enabled – there is no need to target the dynamic All Guest user group – it could be all users instead. The text above says the following: “For members of a tenant, email OTP is usable only for Self-Service Password Recovery. It may also be configured to be used for sign-in by guest users.” and there are 2 tabs here: Enable and Target and Configure. As I understand it all users can use Email OTP for SSPR so on Enable and Target I’ve enabled the policy via the radio-button and in Include i targeted All users. On the second tab Configure in the same policy there is the setting Allow external users to use email OTP which should be Enabled in order Email OTP to be used from guest users as a sign-in method. So it seems that the configuration of the Email OTP settings serves two separate purposes. Could be even possible to keep the guest sign-in functionality without even targeting a specific user group, just to enable the guest sign-in in the Configure tab – I’m not sure.