SharePoint is retiring its one-time-passcode guest auth. Here's what that actually does to your Business Central integrations.
Microsoft is shutting off SharePoint Online's native one-time-passcode (OTP) guest authentication and routing every external sharing interaction through Microsoft Entra B2B instead. It's framed as a SharePoint admin-center change, and most of the coverage of it has been written for M365 admins. But if you've built anything that shares Business Central-generated documents with people outside the tenant — vendor remittance PDFs, customer statements, auditor packages, AP portals — some of that plumbing sits directly underneath this change. Some of it doesn't. This article is about telling the two apart.
What's actually changing
OTP as an authentication method is not being retired. A one-time emailed code is still how a guest without a work/school or Microsoft account proves who they are. What's being retired is SharePoint's own, SharePoint-only version of it — the ephemeral "email-verified visitor" session that never created a durable object in your directory. Going forward, that OTP challenge is issued by Entra B2B, and completing it provisions (or reuses) a real guest user object (UserType = Guest) in your tenant's directory.
That's the substantive change: external collaborators go from an ephemeral, SharePoint-scoped session to a persistent, governed Entra directory object — subject to Conditional Access, guest lifecycle policies, and cross-tenant access settings. The tenant setting that used to control this (Set-SPOTenant -EnableAzureADB2BIntegration) becomes non-optional in this rollout — no opt-out, no admin-picked migration date.
Timeline, per the Microsoft 365 Message Center post MC1243549 (updated July 17, 2026):
- Phase 1 — May to June 2026: new sharing invitations and authentications begin using Entra B2B instead of SPO OTP. Microsoft's July 17 update states this is complete for Production (GCC/GCCH/DoD excluded, pending separate communication).
- Phase 2 — October 1 to October 31, 2026: SPO OTP retirement itself. External users without an Entra B2B guest account start seeing "This organization updated its guest access settings" on links shared before the transition.
Worth flagging: this Oct 1–31 window is itself a reschedule — Microsoft's own FAQ page (dated May 8, 2026) still references an earlier July 2026 cutover for the "reshare or lose access" trigger, which the July 17 update superseded. Rollout is also automatic and staggered per tenant ("selected automatically by our rollout systems," per the FAQ) — check Get-SPOTenant and your own Message Center rather than treating October 31 as a simultaneous date across every tenant.
Explicitly not affected: Anyone/anonymous links (scope: anonymous). Microsoft's FAQ states this directly — there was never a guest identity involved. If your integration only ever generates anonymous links, this is a non-event. Don't let anyone sell you remediation work for that.
Legacy flow: SharePoint's own OTP challenge, scoped entirely to that session.
New flow: the OTP challenge is issued by Entra B2B, and completing it provisions a persistent, governed directory object.
What breaks in a Business Central context — and what doesn't
We went through this looking specifically for BC-shaped failure modes, and it splits cleanly into three buckets.
Affected: the native "Share" action and anything built on the Document Sharing module
BC's built-in Open in OneDrive / Share actions — on the Report Inbox, posted document pages, any record with attachments — are built on the Document Sharing system application module (table/codeunit 9560) and base-application codeunit 9510 Document Service Management (ShareWithOneDrive, ShareWithOneDriveFromMedia). This action uploads the document into the user's OneDrive/Business Central folder and hands off to the standard OneDrive/SharePoint sharing surface — it has no BC-specific link logic of its own. It inherits whatever your tenant's sharing behavior is, exactly like a user manually sharing a file from OneDrive. If a user shares a posted invoice with an external accountant using a "specific people" link, that recipient now goes through Entra B2B, and if the link predates your tenant's transition and the recipient never got a persistent guest object, it's subject to the same access-denied failure as any other stale SharePoint share. Same logic applies to anything custom-built on the same module (page extensions calling DocumentServiceManagement.ShareWithOneDrive, or a codeunit subscribing to OnUploadDocument).
Affected, and the one worth actually auditing: custom AL/Power Automate flows that generate "specific people" links or Graph invitations
This is the pattern we'd expect most VAR-built integrations to actually use: AL code calling the SharePoint System Application module, or a Power Automate flow triggered off a posted BC document, that pushes a PDF to a SharePoint library and then either calls Graph driveItem: createLink with scope: "users" (as opposed to scope: "anonymous"), or calls the Graph invite action, which emails an invitation and grants permission to named external recipients. Both are "specific people" patterns that route the recipient through guest authentication.
The API call itself doesn't start throwing errors because of this migration — createLink/invite still succeed. What changes is what happens when the external party opens the link: they now go through Entra B2B redemption rather than a bare SPO OTP challenge, landing as a directory guest object subject to Conditional Access. If the link predates your tenant's transition and nobody has re-triggered a share since, they may hit "this organization updated its guest access settings" instead of the document. If you've built recurring vendor- or customer-facing document exchange this way — AP invoice delivery, statement distribution, audit evidence packages — that's the integration to pull up and check: what scope are you requesting, and do the regular external counterparties already have persistent guest accounts?
Not affected: External File Storage (BC 2026 release wave 1 / BC28)
BC's newer external file storage feature — offloading attachments to Azure Blob, Azure File Share, or a SharePoint document library, configured via External File Accounts — authenticates using an Entra ID app registration (Tenant ID, Client ID, Client Secret) with app-only permissions on the SharePoint site. There is no end-user sharing link involved; BC talks to SharePoint as an application, not as a delegated user sharing content with a named external person. This is unaffected by the OTP retirement — different auth path entirely (client-credentials, not delegated guest auth). Worth stating plainly since it's easy to conflate: BC talking to SharePoint as a backend storage target, and BC users sharing a document with an external person, are two unrelated mechanisms. Only the second touches guest identity.
How to actually detect exposure
Start with Get-SPOTenant's EnableAzureADB2BIntegration property to establish current state (it stops mattering once the tenant-wide rollout reaches you, but tells you where you stand today). Then pull the site-level external sharing report for any SharePoint site/library BC processes touch — a Share-action target, a Power-Automate-managed vendor library, an audit evidence library — and check the User E-mail column for guests invited via SPO OTP with no matching Entra B2B guest object. That's your at-risk population. In parallel, grep the AL codebase and Power Automate flows for the SharePoint System Application module, Graph createLink, and Graph invite, and note the scope/link-type on each hit: anonymous needs nothing, specific-people/invite goes on the inventory. Cross-reference that inventory against the recipients — if a regular external counterparty already has a persistent guest object, they're fine; if not, they're the ones who'll hit access denied the first time they open a pre-existing link post-Phase-2. The full checklist below turns this into something you can actually run against a client tenant.
The gotchas
- Existing OTP guests without a persistent account are the actual failure mode, not new sharing. New shares self-heal: a guest account is created automatically the moment someone (re)shares a file, folder, or site with an external email address, or if that site was ever shared with them in the past, or if an admin manually provisioned them. The risk is entirely in static, unrenewed links — a PDF link emailed once, six months ago, that nobody has touched since.
- Conditional Access now actually applies to guests. This is the sleeper issue. If your customer has (or adds, post-migration) a CA policy requiring MFA for guest/external users, and their AP vendor's inbox doesn't support MFA cleanly, that vendor's document access breaks for reasons that have nothing to do with SharePoint sharing settings.
- Cross-tenant access settings now matter for SharePoint sharing in a way they possibly didn't before, since Entra B2B collaboration defaults (Entra ID → External Identities → Cross-tenant access settings) govern the guest authentication and redemption flow. If a customer's default inbound/outbound B2B settings are locked down for security reasons unrelated to SharePoint, that lockdown can now unexpectedly block SharePoint external sharing too.
- MAU billing is very unlikely to be a real cost for a typical BC customer. Microsoft Entra External ID's basic billing model covers the first 50,000 monthly active users free, and it counts unique external guests who authenticate in a given month — a mid-market company's vendor/customer guest population is almost never going to approach that. The one exception: if the customer already uses (or plans to use) Entra ID Governance features — access reviews or entitlement management — against guest users, that add-on has no free tier and bills separately regardless of guest count. Worth a five-minute check, not worth losing sleep over otherwise.
- This isn't a scheduled-maintenance-window problem. Admins cannot pick a migration date or defer it — Microsoft's FAQ is explicit that tenant selection for rollout is automatic. The only lever available is proactive: get ahead of it with an inventory and pre-provisioned guest accounts, not a change-freeze.
Diagnostic tree for a single share/link — run it per SharePoint site or library that Business Central touches.
Pre-flight checklist for a partner reviewing a client's tenant
Anything on that list you can't answer with a document or a command output — not a guess — is the actual open risk. Everything else is noise.
DigitalSolveWorks does integration re-architecture work for Dynamics partners — moving legacy NAV on-premises integration patterns (direct SQL access, .NET interop, file-drop exchanges) onto Business Central SaaS-compatible patterns (AL HttpClient, OAuth 2.0, Azure Functions/Logic Apps middleware) — on a fixed-fee, asynchronous basis. If this is the kind of audit or remediation work you'd rather hand off than do in-house, reach out at contact@digitalsolveworks.com.