Microsoft is changing how external file sharing works in OneDrive and SharePoint. It is a sensible change. It also highlights something worth understanding about how SharePoint approaches external sharing.
SharePoint’s model is to grant carefully controlled access to content that lives inside your Microsoft 365 environment. This makes sense when you’re collaborating over weeks or months – those people become managed guests, subject to your own security policies and controls.
The retirement of SharePoint’s passcode sharing doesn’t change this model – it reinforces it. But it also makes visible the amount of identity infrastructure needed simply to let someone outside your organisation access something inside it.
This is worth five minutes of your attention. Not because it is a crisis, but because a quiet setting change has a loud consequence, and people tend to find out at the worst possible moment – e.g. when a client emails to say the link you sent has stopped working.
Here is the plain version.
Microsoft is retiring SharePoint’s own one-time passcode method, known as SPO OTP: the system that lets an external person open a shared file by typing a code sent to their inbox, with no account required. As of May, new external shares now route through Microsoft Entra B2B instead. The retirement of the old passcodes began this month and will be completed in most environments by the end of August 2026. You do not get to pick when it reaches you; the rollout chooses the date, tenant by tenant.
One thing to clear up, because a lot of the coverage gets it backwards: one-time passcodes are not disappearing. Entra B2B still emails a code to guests who do not have a work or Microsoft account. What changes is where the sign-in happens, and, more to the point, what gets created when you share.
From now on, sharing externally creates a guest account in your directory. It appears automatically the moment you share with someone who does not already have one, and it stays there until somebody removes it. A casual “here is the file you asked for” quietly becomes a permanent identity in your tenant.
For older “Specific People” links, the effect is blunt. Once retirement reaches your tenant, any recipient without a matching guest account gets an access-denied message. There is no warning to them and no warning to you. The first you hear of it is the follow-up email asking why the link is dead. Worth knowing what is not affected, too: “Anyone/Anonymous” links carry on as before. It is the “Specific People” shares, the ones tied to a named recipient, that break.
It would be easy to frame this as Microsoft making life harder. That would not be fair. For organisations that want external users to become managed identities, this is a sensible change. Guest users can now be brought under Conditional Access, multi-factor authentication, audit logging and access reviews in exactly the same way as other identities in the directory. As a governance decision, it holds up.
The trade-off is administrative. The number of guest accounts in your directory is now tied to how often your people share, and most people share constantly. That means directory clutter, guest lifecycle management, and access reviews you did not have to run before. You gain governance, and you pay for it in overhead.
Step back and the overhead makes sense, because the platform is doing something harder than it looks.
Collaborating with your own team and sending a file to someone outside it are two different jobs.
SharePoint is built for the first, so to do the second it has to work out what the external recipient is within your environment, and its answer is a guest: an identity it creates, secures and eventually tidies up. That is a fair amount of admin for getting one document to one person who does not work for you.
The two jobs have shared a coat for years. This change is the moment the seam shows.
Rather than extending your collaboration environment to external people, Hexiosec Transfer creates a separate environment specifically for exchanging information outside your organisation. Sensitive files never require the recipient to become part of your Microsoft 365 tenant, because they never access it.
In Hexiosec Transfer, the shared content lives inside that isolated environment rather than alongside your internal SharePoint libraries. The sender defines who may access it, and recipients prove they are the intended recipient when they collect the files through email verification and/or two-factor password. Once the exchange is complete, there is no guest identity left behind inside your directory because none was ever created.
That separation also reduces the blast radius. An error in external sharing cannot accidentally expose wider areas of your Microsoft 365 environment because the recipient was never granted access to it in the first place. The shared workspace exists outside your internal collaboration platform, rather than extending it.
Files are encrypted on the sender’s device before upload and remain unreadable to anyone without the keys, including us. Zero-knowledge isn’t simply a policy about how we handle your data; it’s a property of the system itself.
Start with Microsoft’s own guidance. Use the sharing reports to find older “Specific People” links, then either reshare the content or create guest accounts for the external people who need continued access. Because you do not control the timing, sooner beats later. Microsoft’s message centre post (MC1243549) and its external-sharing FAQ cover the detail. Tell your users what is coming, because the failure mode is silent and support tickets are not.
And if working through it leaves you wondering why sending one document to one person outside your organisation now requires directory governance at all, that is a fair question. For a lot of teams, the answer is that it doesn’t have to.
Sending sensitive files outside your organisation, without leaving anything behind in your directory, is what Hexiosec Transfer is for. See how it works or try it free.
