If you administer a SharePoint Online tenant, the EnableAzureADB2BIntegration setting is the thing you used to flip to choose between the legacy SharePoint One-Time Passcode (SPO OTP) experience for external guests and the modern Entra B2B Invitation Manager flow. The cmdlet has been around for years. Compliance scripts read it. Tenant baselines assert on it. Some org policies still document it as the toggle.

Starting May 2026, that setting no longer does anything.

Microsoft is rolling Entra B2B integration out to every SharePoint tenant automatically. The rollout windows are not announced per-tenant — "tenants are selected automatically by our rollout systems. You cannot choose a specific date." Once your tenant flips, Set-SPOTenant -EnableAzureADB2BIntegration $false becomes a no-op. The cmdlet returns without error. The next Get-SPOTenant may still show a value. External sharing has already moved to B2B regardless.

And in July 2026, the other shoe drops. Every external guest who was authenticated through SPO OTP — and never got upgraded to a real Entra B2B guest account in your directory — silently loses access to every link you ever shared with them. The link doesn't 404. The user gets a flat "This organization updated its guest access settings" page. Your audit log says the sharing event was successful months ago. Your sharing reports still list the file as shared. The recipient just can't open it anymore.

That's two stacked silent surfaces with a hard July cliff in between. Here's what each one actually does, and how to find what's affected before the cliff.

1. The setting is gone but the cmdlet still answers

Read the Microsoft docs carefully:

Starting May 2026, Microsoft enables SharePoint and OneDrive integration with Microsoft Entra B2B for all tenants, regardless of the tenant's setting for EnableAzureADB2BIntegration. Once rolled out, this setting has no effect on sharing behavior, and the ability to disable the integration is removed.

The phrase that gets glossed over is "regardless of the tenant's setting." The setting field is not being deleted. The PowerShell cmdlet is not being removed. The property still exists, still returns a value, and Set-SPOTenant -EnableAzureADB2BIntegration $false still parses and executes. It just no longer controls the behavior it used to control.

This is the textbook silent surface: an API endpoint that continues to accept the same request and return the same response, but the underlying behavior changed. Anything in your environment that reads the setting to infer sharing behavior is now wrong.

Concrete examples of what breaks in the dark:

• Compliance baselines. If your CIS / NIST / internal policy baseline asserts that EnableAzureADB2BIntegration is $true, that check still passes after rollout, but it's measuring nothing — the answer is True for everyone whether they configured it or not. If your baseline asserts it's $false (some orgs deliberately kept legacy OTP), the check passes and the assertion is a lie. External sharing is using B2B regardless.
• Tenant-state monitors. Scripts that snapshot tenant settings nightly and diff against a known-good baseline see no diff. The setting didn't change. The world around the setting did.
• Pre-rollout audits. If you ran a "we'll handle this when we're ready" plan and used the setting as your gate, you can't gate on it anymore. The rollout flips your tenant when the rollout flips your tenant.
• Idempotent provisioning. Terraform, Azure Bicep, DSC, or whatever provisions tenant settings continues to "successfully" set the value. The plan and apply both succeed. The value the next plan sees is unchanged. Nothing in the tooling reports that you provisioned a setting that does nothing.

If you've ever depended on this setting to reason about whether sharing goes through OTP or B2B, you can't anymore. The only reliable source of truth after May is "the rollout has happened to this tenant" — which Microsoft does not surface as a single boolean. You have to look at the actual share events.

2. Auto-rollout means you can't time your migration

When a Microsoft 365 change has an admin-controlled flag, you can plan: turn it on in a test tenant, run validation, schedule the production flip. When the change is forced on by central rollout, you lose that.

The FAQ is explicit:

Can I choose when this integration is enabled for my tenant? No. Tenants are selected automatically by our rollout systems. You cannot choose a specific date.

And:

Can I opt out of this change? No. This change applies to all tenants and aligns with Microsoft's strategy of using one centralized identity provider across all Microsoft 365 applications.

So between May and the end of the rollout, your tenant flips one day with no notice on your end. The day it flips, every new external share creates an Entra B2B guest in your directory instead of an SPO OTP entry. Existing OTP guests are not auto-upgraded. The two populations now coexist in your tenant.

That coexistence is the trap. Until July, both populations can still open files. B2B guests authenticate via Entra; OTP guests authenticate via the SPO OTP code flow. Everything looks fine. Sharing reports still light up green. Your helpdesk doesn't see tickets, because nobody's actually broken yet.

So you assume the rollout was a non-event. You move on. Then in July, the OTP cohort starts hitting access-denied, and you have no list of who they are because nobody told you the cohort even existed.

The only way to get ahead of this is to enumerate, before July, every external user who is authenticated through OTP and does not yet have a corresponding B2B guest account in your directory. Microsoft surfaces this at site level via the external sharing report — pull the report, look at the User E-mail column, cross-reference against Entra B2B guests. The mismatch is your at-risk cohort. The tenant-level admin center does not give you this list.

3. July's access-denied is silent from the admin side

Here's the precise behavior Microsoft documents:

Do my guest users retain access to files shared before the integration? Yes, but only if they have a Microsoft Entra B2B guest account in your directory. If they do not have a Microsoft Entra B2B guest account, external collaborators see access denied starting July 2026.

What the external user sees, after rollout: a page that says "This organization updated its guest access settings." Not "link expired." Not "file not found." Not 404. A specific, generic-sounding error that most users will read as "the link broke" and either re-ping the sender or quietly give up.

What the admin sees: nothing, until someone files a ticket. The audit log entry for the original share is still there, intact, months old. The file is still shared — Get-SPOUser still lists the guest. The sharing report still shows the link. The only thing different is that the guest's authentication path no longer works because the OTP authentication backend isn't where SharePoint looks anymore.

This is the asymmetric failure that makes it hard to test: the share-side state stays valid, the auth-side state stops being honored. Anything you build to monitor "is this share still active" by inspecting share state returns "yes" all the way through the cliff.

The Microsoft-recommended fix is to either pre-create B2B guest accounts for at-risk users (so July is uneventful), or rely on a workflow where an internal user reshares one file — that creates the B2B guest, which then retroactively grants access to every link previously shared with that email. The second option works but requires a user to notice access is broken and request a reshare, which means the broken-access state is part of the user experience.

If your SharePoint estate has guests from any tenant provisioned before June 2023, assume you have OTP-only guests. Tenants provisioned after June 2023 have B2B integration on by default and aren't impacted by this specific population, but they still get the setting-no-op behavior from section 1.

4. Anyone-links and Anonymous-links are unaffected — which matters because people will assume otherwise

One thing that's explicitly not changing is anonymous/Anyone links:

Is there any impact on Anyone/Anonymous links? No. SPO OTP retirement and use of Entra B2B for external sharing does not impact Anyone/Anonymous links.

Surface this in your internal comms. The natural reaction to "external sharing is changing in July" is to assume every external link is at risk and to either re-share everything or panic-disable external sharing. Anonymous links never used OTP — they use the link's own access controls — so they sail through this entirely.

The cohort that's at risk is the narrow one: links shared with a specific person's email address, where that recipient authenticated via SPO OTP, and where that recipient has not yet been promoted to a B2B guest in your directory.

5. Audit-log event types: the sharing event itself looks different post-rollout

The other piece nobody is talking about is that the audit-log shape of an external share event changes once your tenant is on Entra B2B integration. SPO OTP shares emitted SharePoint-namespaced events with the OTP authentication flow. Entra B2B Invitation Manager emits Microsoft Entra audit events (Add user, Invite external user) followed by the SharePoint share event.

If you have SIEM filters keyed on the SPO OTP event signature — for example, alerting on "external share to a high-risk domain via OTP" — those filters quietly stop matching the new shares. The new shares still happen; they just no longer trip your old query. Same kind of silent surface as the setting in section 1: the data is there, your filter just doesn't see it.

For Microsoft Sentinel, Defender, Purview Audit, or any third-party SIEM ingesting Microsoft 365 audit data, audit the queries that depend on share-event shape and make sure they also match the Entra B2B Invitation Manager flow. Microsoft Graph Data Connect (MGDC) is the higher-fidelity source if you need both populations.

Timeline summary

• End of April 2026 — Last window to manually run Set-SPOTenant -EnableAzureADB2BIntegration $true on your own schedule and validate in a controlled way.
• May 2026 — Auto-rollout begins. Tenants flip on Microsoft's schedule, not yours. The setting becomes a no-op. New external shares use Entra B2B.
• July 2026 — OTP-only guests start seeing access-denied on previously shared links. The hard cliff.
• August 31, 2026 — Full SPO OTP retirement complete.

What this looks like on a monitoring dashboard

The whole point of writing this up is that none of these surfaces are visible in a normal "is my API working" check. The PowerShell endpoint answers. The audit log writes events. The sharing report renders. The compliance baseline reports green. The user sees a generic error page. The admin sees nothing.

This is the same shape as the schema-drift incidents we've been tracking elsewhere — Twilio dropping transit_callerid, Stripe flipping unit_amount_decimal from string to Decimal, GitHub silently removing payload.commits from PushEvent: the endpoint stays alive, the response stays parseable, and the meaning of what it returns has changed under the integration. The tooling that doesn't notice is the tooling that asserts on shape, not on semantics.

For SharePoint specifically, the assertions that actually catch this are:

1. Setting + behavior coherence: read EnableAzureADB2BIntegration and also sample a recent external share event; assert the auth path in the event matches the setting. After rollout, the setting can claim $false and the share will be via B2B — that mismatch is your signal that the rollout flipped you.
2. Guest population audit: weekly diff of "external email addresses with active shares" vs. "Entra B2B guest accounts." Any email in the first set not in the second is at risk in July.
3. Share-event shape monitoring: alert on a change in the dominant audit event type for external shares — when SPO-OTP-shaped events drop to zero and B2B-Invitation-Manager-shaped events become the norm, your tenant has been flipped, and your SIEM filters need re-tuning.

If you maintain any of those today, this rollout is manageable. If you don't, July is going to be a helpdesk surprise rather than a planned change.

References

• Microsoft Entra B2B integration for SharePoint & OneDrive — the canonical doc, updated May 2026.
• FAQ: Improvements to external sharing in OneDrive and SharePoint — the source of the "no opt-out, no scheduling, July access-denied" specifics.
• Sharing reports in SharePoint — site-level external sharing report, the only place to enumerate OTP-only guests.