DigitalSolveWorks

Insights

· SharePoint & Entra ID

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.

Sources and limitations

We publish this analysis with its sources and its known gaps intact, including the parts we couldn't nail down, so you can weigh the argument on the same evidence we had rather than on our say-so.

Primary Microsoft sources

  • Microsoft 365 Message Center archive, MC1243549 — third-party archive of the official Message Center post "Retirement of SharePoint One-Time Passcode (SPO OTP) and transition to Microsoft Entra B2B." Source for the phased timeline: Phase 1 (May–June 2026, new sharing moves to Entra B2B) and Phase 2 (October 1–31, 2026, SPO OTP retirement completes). Contains the July 17, 2026 update confirming Phase 1 complete for Production and Phase 2 rescheduled to Oct 1–31. Also source for: GCC/GCCH/DoD exclusion, Guest Inviter role recommendation, and admin action list. This is a mirror/archive of Microsoft's message, not the Microsoft 365 admin center itself — we could not view the admin center directly, so treat the mirror as high-confidence but not the literal primary document.
  • Microsoft Learn — "Microsoft Entra B2B integration for SharePoint & OneDrive" — official Microsoft documentation, updated 2026-07-01. Primary source for: the exact PowerShell parameter Set-SPOTenant -EnableAzureADB2BIntegration $true/$false, confirmation that this setting stops controlling behavior once the May 2026 tenant-wide rollout reaches a tenant, the "This organization updated its guest access settings" error text, the note that tenants provisioned after June 2023 already default to B2B integration, and the FAQ stating resharing was required for opted-in tenants starting July 1, 2025 (a separate, earlier change from the 2026 mandatory retirement — see below).
  • Microsoft Learn — "Frequently Asked Questions: Improvements to external sharing in OneDrive and SharePoint" — official Microsoft FAQ, dated 2026-05-08, updated 2026-05-09. Primary source for: confirmation that OTP as an auth method is not retiring (only the SharePoint-native version of it is), that the change cannot be opted out of or scheduled by admins ("selected automatically by our rollout systems"), that manual early opt-in was possible until end of April 2026, how guest accounts get created (three trigger conditions), and — critically — explicit confirmation that Anyone/Anonymous links are not impacted by this change (FAQ #10). Also the source of a now-superseded "access denied starting July 2026" date (FAQ #8) that conflicts with the later Message Center reschedule to October — see below.
  • Microsoft Learn — "Integrating with Office apps and Microsoft 365" (Business Central dev docs) — official BC developer documentation. Source for the existence and description of the SharePoint System Application module (AL wrapper over SharePoint REST API) and the OneDrive integration surface ("Open in OneDrive" / "Share" actions).
  • Microsoft Learn — "Extending Document Sharing and OneDrive for Business" (Business Central dev docs) — official BC developer documentation. Primary source for the mechanics of BC's native Share action: table/codeunit 9560 "Document Sharing" (system application), codeunit 9510 "Document Service Management" (base application), procedures OpenInOneDrive/ShareWithOneDrive/ShareWithOneDriveFromMedia, and confirmation that the Share action was introduced in Business Central 2022 release wave 1 and hands off to the standard OneDrive sharing experience rather than implementing its own link logic.
  • Microsoft Learn — "Store document attachments in external file storage" (Business Central) — official BC documentation, dated 2026-03-20. Primary source for the External File Storage feature: setup via External File Accounts, SharePoint storage account configuration requiring Tenant ID / Client ID / Client Secret (app registration, app-only auth), and confirmation this is a backend storage integration with no end-user sharing link or guest-identity component.
  • Microsoft Learn — "Microsoft Entra External ID pricing and billing overview" — official pricing documentation, dated 2026-06-22. Primary source for the MAU billing model: first 50,000 monthly active users free under the basic tier; guest B2B collaboration users (UserType = Guest) counted under this model; ID Governance add-on has no free tier and bills separately for guest access reviews/entitlement management.
  • Microsoft Graph documentation — driveItem: createLink — confirms scope parameter values (anonymous vs users/specific-people) and that createLink does not itself require recipient authentication at call time — authentication happens later when the recipient opens the link.

Secondary / practitioner sources

Used for corroboration and phrasing only — never as the sole basis for a factual claim.

What we could not verify

  • The planning document's claim of "October 31, 2026" as the retirement date. This is now confirmed, not just plausible — Microsoft's own Message Center post (MC1243549, updated July 17, 2026) states Phase 2 runs October 1–31, 2026, for Production environments. The planning doc's premise was correct. The nuance we add: this is an outer bound for a staggered, automatic, per-tenant rollout, not a single simultaneous cutover date, and it is itself a reschedule from an earlier plan — so we recommend readers verify their own tenant's Message Center rather than treating October 31 as a hard universal date. We did not find a way to independently query "has tenant X been migrated" outside of Get-SPOTenant / Message Center, so we could not verify a method for a partner to check a specific client tenant's live phase beyond what's in the article.
  • Conflicting dates across Microsoft's own properties. The FAQ page (dated 2026-05-08) states external collaborators without a B2B guest account see access denied "starting July 2026" (FAQ #8), which conflicts with the Message Center's July 17, 2026 update rescheduling that to October 1–31, 2026. We treated the Message Center update as authoritative (it's dated later and is explicitly a revision), but we could not confirm the FAQ page has since been corrected — as of this research it still shows the July 2026 date. The article flags this discrepancy explicitly rather than silently picking one. We recommend a partner cross-check both pages at time of publication/reading, since either could have been updated again.
  • Whether there is a genuinely separate, earlier 2025 "reshare" requirement. The B2B integration doc's FAQ #3 states tenants that already had EnableAzureADB2BIntegration enabled required resharing starting July 1, 2025 — this appears to be a distinct, earlier event from the 2026 mandatory-for-all-tenants retirement, not the same deadline restated. We could not fully disentangle whether some of the "July 2026" references floating around the practitioner blogs are echoes of this 2025 event, confusion with the FAQ's stale July 2026 date, or something else. We did not assert a causal link between the two in the article; we only mention the 2025 date is a separate item where relevant.
  • Whether BC's native Share action / Graph createLink calls in AL specifically default to "specific people" scope vs "anonymous" scope out of the box. We could not find Microsoft documentation stating the default link type BC's Share action requests — this depends on the tenant's SharePoint/OneDrive default link type setting (a standard, pre-existing tenant setting unrelated to this migration), not on BC-specific code. The article is careful to say this action "inherits whatever your tenant's sharing behavior is" rather than asserting a specific default, since we could not verify one.
  • No source discusses Business Central specifically in connection with this SharePoint change. We searched directly for "Business Central" + OTP/Entra B2B retirement and found zero hits connecting the two topics. This means the BC-specific analysis in the article (which flows are affected, which aren't) is our own synthesis of two independently-documented things — the SharePoint/Entra change and BC's documented SharePoint/OneDrive integration surfaces — not something we found already stated by Microsoft or any practitioner. We're confident in the mechanics (verified against the official BC dev docs and the official SharePoint/Graph docs separately), but flagging that the connection itself is original analysis, not a corroborated claim.
  • Graph invite action's precise interaction with Entra B2B redemption post-migration. We confirmed invite sends a sharing invitation and optionally an email, and that createLink with scope: users restricts access to named recipients, but we did not find a Microsoft source walking through exactly how invite-created shares behave differently (if at all) from createLink-with-scope-users shares under the new B2B-mandatory regime. The article treats them as functionally equivalent for this purpose (both are "specific people" patterns that hinge on guest identity), which we believe is defensible from the general mechanics but did not find explicitly confirmed side-by-side in one source.
  • MAU cost impact for a real BC/VAR customer. We found the general billing model (50,000 free MAU) but no worked example or benchmark for what a typical mid-market Dynamics customer's external guest count looks like. The article's claim that this "is very unlikely to be a real cost" is a reasonable inference from the free-tier size, not a verified benchmark — flagged as inference in the article's own wording ("almost never going to approach that").
  • Conditional Access specifics. We confirmed generically that CA policies scoped to guest/external users now apply to these accounts where they may not have applied to ephemeral SPO OTP sessions before, corroborated by Microsoft's own framing ("Conditional Access coverage across Microsoft 365" as a stated benefit of the change). We did not find a Microsoft source walking through a concrete before/after CA policy example, so the "vendor gets an MFA challenge they can't satisfy" scenario in the article is a plausible, mechanically-sound illustration, not a documented case study — worded as an illustrative risk, not a reported incident.