SharePoint OTP Retires: 4 Checks Before Links Break

SharePoint One-Time Passcode authentication retires through October 2026. Phase 2 of the rollout starts on 1 October and is expected to complete by 31 October, and the practical result is that some external users who could open a shared file yesterday will get access denied tomorrow, with no change made on your side.

The name of this change causes more confusion than the change itself, so that needs clearing up before anything else. Then there are four things to check in your tenant, two of which can break external sharing on their own if somebody tightened them at some point for good reasons.

In this post: Prerequisites · What is actually retiring · What breaks, and for whom · You probably do not need to reshare · Check 1: email OTP is still on in Entra · Check 2: Conditional Access now applies · Check 3: find the guests who will break · Check 4: who is allowed to invite · What is not affected · Who actually needs to act? · Related reading

Prerequisites

SharePoint Administrator for the tenant level settings, and site admin rights on any site where you want to run the sharing report, because that report is run per site rather than centrally.
Microsoft Graph PowerShell if you want to enumerate guest accounts across the directory. Connect-MgGraph with a scope that permits reading users.
Access to Microsoft Entra External ID settings, since one of the checks below lives there, not in the SharePoint admin centre.
Commercial tenant. GCC, GCC High and DoD are excluded from this rollout, with dates still to be announced.

What is actually retiring

Reading “one-time passcode retirement” naturally suggests that passcode emails are going away and external users will need real accounts. That is not what is happening, and Microsoft’s own FAQ leads with the correction because so many people arrive at it with exactly that assumption.

One-time passcode is not being retired as an authentication method. Microsoft Entra B2B uses OTP as the default method for guests. What retires is SharePoint’s own separate passcode system, not the passcode itself.

SharePoint historically ran its own lightweight identity path for external recipients. Share a file with someone outside the tenant, they receive a code by email, they type it in, they get access, and no account exists in your directory afterwards. That mechanism is what retires. External authentication moves to Microsoft Entra B2B, which handles guests as real directory objects and which, by default, still authenticates them with an emailed one-time passcode.

From the external user’s point of view the sign-in experience is broadly the same. From your point of view it is quite different, because those people now exist as guest accounts in your directory and are therefore subject to everything that applies to guest accounts.

What breaks, and for whom

The affected population is narrower than the announcement makes it sound. It is external people who hold a specific people link from before the transition and who have no Entra B2B guest account in your directory. After the October retirement those users see access denied until a matching guest account exists.

Phase 1 moved new external sharing invitations and authentication onto Entra B2B and completed for production tenants in July 2026. So anything shared since roughly May 2026 already created a guest account along the way and is fine. The exposure is older sharing: links issued while SharePoint OTP was still handling the invitation, to people nobody has shared anything with since.

One point of confusion if you researched this earlier in the year. The Microsoft Learn FAQ, last revised in May 2026, states that affected users see access denied starting July 2026. The Message Center notice now puts Phase 2 in October. The schedule moved, and October is the operative date, so a note in your own documentation citing July is out of date, not wrong at the time.

You probably do not need to reshare

The instinctive response to “old links stop working” is a project to reshare everything, and that is unnecessary. Microsoft is explicit that previously shared links do not need to be reshared. What matters is whether a guest account exists for that person. Once it does, all of their previously shared links work again.

A guest account comes into existence through any of three routes: at least one file, folder or site is shared or reshared with them, a site was shared with them at any point in the past, or somebody creates the account directly in Entra. Note that creating the account directly is a single action per person that restores every link they ever received, which is a very different amount of work from auditing and reissuing links.

Duplicate accounts are not a risk here either. If a guest account already exists for that collaborator, sharing again does not create a second one.

Check 1: email OTP is still on in Entra

This is the one most likely to cause a self-inflicted outage. Email one-time passcode is a setting in Microsoft Entra External ID, and plenty of tenants disabled it at some point as a hardening measure, back when SharePoint had its own passcode path and the Entra setting looked like an unused attack surface.

After the transition, that Entra setting is the mechanism guests authenticate with. If it is disabled, external sharing to anyone without an existing Microsoft account or federated identity stops working, and the failure will look like it was caused by the retirement rather than by a switch somebody flipped two years ago. Confirm it is enabled before 1 October, not after the tickets start.

Check 2: Conditional Access now applies

This follows directly from guests becoming real directory objects. Any Conditional Access policy scoped to guest or external users now applies to people who were previously outside that system entirely.

That is mostly a good thing and is a large part of why Microsoft is consolidating on one identity provider. It is also a way to lock out collaborators without meaning to. A policy requiring a compliant or hybrid joined device, or requiring MFA registration that an external user cannot complete, will now catch guests who used to bypass all of it. Review what your guest scoped policies actually require, and check whether the requirement is satisfiable by somebody at another company using their own laptop.

Check 3: find the guests who will break

Microsoft’s recommended method is the per site external sharing report. On the site, open Settings, choose Site usage, find Shared with external users and select Run report, then pick a save location. It produces a CSV and emails you when it finishes, and on a large site it can take a while.

The columns that matter are User E-mail, User or Group Type where external people show as Guest, and Link Type where the value to look for is Specific People. Cross reference those addresses against the guest accounts that exist in your directory.

Be aware of the practical ceiling here, because it shapes how you approach this: the report is run by a site admin, on one site at a time, from the interface. There is no tenant wide equivalent, so for an estate of any size this becomes a sampling exercise on your highest risk sites rather than a complete audit. Pulling the existing guest list from the directory side is the faster half of the comparison:

Connect-MgGraph -Scopes "User.Read.All"

# Every guest account that already exists in the directory
Get-MgUser -All -Filter "userType eq 'Guest'" -ConsistencyLevel eventual |
    Select-Object DisplayName, Mail, UserPrincipalName |
    Export-Csv "C:\GuestAudit\existing-guests.csv" -NoTypeInformation

# Guests invited but never accepted, useful to review at the same time
Get-MgUser -All -Filter "userType eq 'Guest' and externalUserState eq 'PendingAcceptance'" `
    -ConsistencyLevel eventual |
    Select-Object DisplayName, Mail, CreatedDateTime

The -ConsistencyLevel eventual parameter is not optional on these filters. Leave it off and the cmdlet errors instead of returning an incomplete list, which is at least a loud failure.

Anyone in the sharing report who does not appear in that guest export is someone who loses access. Creating the guest account for them in advance is the cleanest fix, since it restores every link they hold in one action.

Check 4: who is allowed to invite

Because sharing externally now means creating a directory object, the ability to invite guests becomes a gating factor on ordinary sharing. Confirm Entra is configured to permit guest invitations and that the Guest Inviter role is assigned where people genuinely need it.

Pair that with a decision instead of leaving it at defaults. Restrictive guest invitation settings are a reasonable governance posture, but combined with this change they mean end users can no longer share externally without help. Either widen the permission deliberately or tell people where to send requests, because the failure mode otherwise is silent: sharing simply does not work and nobody raises it as a policy question.

What is not affected

Anyone links, sometimes called anonymous links, are untouched. The retirement and the move to Entra B2B do not affect them at all.
Internal sharing is irrelevant to this change.
Existing guests who already have a B2B account keep access to everything previously shared with them, with nothing to do.
Opting out is not available. The change applies to all tenants, the rollout schedule is chosen automatically, and EnableAzureADB2BIntegration stopped governing this behaviour in May 2026. The option to disable the integration has been removed.

Who actually needs to act?

You share externally with people you rarely share with twice. Auditors, contractors on finished engagements, counterparties on a closed deal. These are exactly the accounts that were never recreated, and exactly the people who resurface asking for a document six months later.
Somebody hardened Entra External ID at some point. Check 1 applies to you, and it is the difference between a smooth transition and external sharing failing outright.
You have guest scoped Conditional Access policies. They now reach a population they never reached before. Check what they demand.
You restrict guest invitations. Ordinary external sharing now depends on that permission, so the restriction is stricter in practice than it was when you set it.
You share almost entirely through Anyone links, or barely share externally. There is nothing here for you, though confirm that instead of assuming it.

SharePoint File Sharing: Best Practices and Approaches covers the link types referenced throughout this post, including where Anyone links sit relative to specific people links.
How to Remove SharePoint File Shared Links is the other half of this job, since an audit of who holds old links usually turns up some that should be revoked rather than restored.
Multi-Factor Authentication (MFA) Options for Microsoft covers the ground to review before you touch the guest scoped Conditional Access policies in Check 2.

Most tenants will get through this without noticing. The ones that will not are the ones where somebody sensibly tightened a setting years ago, in a world where that setting governed something else. That is the genuine risk in this change, and twenty minutes before 1 October beats a diagnosis afterwards.

Compare notes in the comments once October is behind you, especially on how many guest accounts you ended up creating and whether Check 1 caught anyone out.