Microsoft is retiring SharePoint's legacy one-time-passcode sharing — the flow that let you share a file with an external person who had no Microsoft or work account. New external invitations have moved to Entra B2B since May 2026, and the old passcode path is fully retired by 31 October 2026. That timeline is Microsoft's, not ours. When it goes, the shares built on it do something worth understanding: the access they granted ends, and the record of it doesn't.
What's actually retiring
For years, sharing a SharePoint file with someone outside your tenant who had no Microsoft or work account ran on a one-time passcode: they'd get an email, request a code, and open the file with it — no directory account required. Microsoft is replacing that with Entra B2B guest accounts, a proper directory identity in place of a per-file passcode. New external invitations already work the new way; the legacy passcode flow is fully retired by 31 October 2026. The date is Microsoft's schedule, and this post treats it as such.
What it leaves behind
Retirement changes what those old shares can do — not what your tenant records about them. An external recipient who was invited through the passcode flow and didn't move onto a B2B guest account has no durable identity behind that access: it rests on a mechanism Microsoft is retiring, and once that mechanism is gone the link stops opening for them. What doesn't go anywhere is the permission entry that granted it. It stays in SharePoint's access-control list — a urn:spo:guest entry that still reads like an external grant.
Those entries are the residue, and it's worth being precise about what they are: auditable stale exposure, not a live grant — a permission record whose backing mechanism is being retired out from under it. This isn't your data springing a new leak; the access these entries describe is the very thing Microsoft is winding down. What's off is subtler, and still worth fixing: your tenant carries records that read like durable external access and aren't.
Why a permission report still shows them as access
Ask SharePoint — a native permission report, or a raw PowerShell read of the ACL — what has access, and these entries come back as external grants. That isn't a bug; it's what the access-control list literally says. A report reads the entry as it stands; it can't tell that the mechanism behind that entry retired. So in an access review, stale residue and live external access look the same on the page.
A reviewer who takes the export at face value either raises a false alarm over stale residue, or — worse — files the whole line under "known external sharing" and moves on. Either way the review is working from a record that misrepresents itself. That's the real cost of the residue: not exposure, but an access picture you can't trust to be current — exactly the kind of thing that reads badly in an audit.
What an admin can do about it
The fix is hygiene, not incident response. A residue entry should be removed so the record matches reality — the grant is doing nothing for its recipient, and clearing it takes one stale line out of future reviews. If the share is still wanted, re-create it the current way: re-share to a B2B guest, and you're left with a live grant and a directory identity you can review later. TRACER365 is read-only here: it surfaces these external grants for a decision, and removing them stays with your admins.
To tell residue from live access, it helps to know the shapes it takes. The old passcode shares surface as specific-people external sharing links and direct external grants — the two finding types the residue lands in. A close cousin is the unredeemed guest invitation: an invite that wasn't accepted — exposure that was decided but not activated. Each of those explainers goes deeper than this post has room to.
The residue is the point, not the deadline
The residue is the durable part; the deadline just clarifies it. In older tenants, legacy passcode shares that were left in place are records sitting in the ACL today, deadline or no deadline. What 31 October marks is the end of the mechanism itself — after which one of these entries is a paper trail and nothing more. The entry reads the same the day before and the day after; the date just settles what it is. An access review is where that paper trail shows up — and the useful move is the same before the date and after it: find the external grants you're still carrying, and decide which ones describe access you meant to keep.