This is the critical tier for the collaboration estate: the controls I will not hand a tenant over without, and the one dated obligation in the whole wave. External Trust leads, because sharing is what this product does and because the layer underneath it changed this year. Then the identity seam, then Teams, then the protection policy nobody knows exists.
A note on what critical means here, because collaboration invites a different kind of overreach than identity did. It does not mean locked down. A file estate nobody outside can reach is not a secure collaboration platform, it is a filing cabinet, and I have watched more value destroyed by reflexive lockdown than by anonymous links. Critical here means the cost of getting it wrong is either a breach or a business outage, and there is no reasonable environment where I would leave it undone.
External trust: the deadline first, then the design
Start with the thing that has a date. Under the old model, an external person could open a shared link by receiving a one-time passcode by email, with no account existing anywhere in your directory. That mechanism is being retired, and when it goes, anyone still relying on it loses access to everything they were ever sent. The retirement runs during October, having originally been announced for July.
The remediation is not what most write-ups say it is, and this is worth being precise about because the wrong version costs you weeks. You do not need to reshare anything. Microsoft’s own position is that previously shared links continue to work wherever a guest account exists in the directory for that person, and that creating the account is what restores access. So this is not a communications exercise aimed at users. It is an inventory: list the external people who were invited under the old mechanism, find the ones with no guest account, and create accounts for them. Resharing is the fallback for whatever the inventory misses, not the plan.
Two adjacent facts save time. Creating a guest account for someone who already has one does not produce a duplicate, so the operation is safe to run broadly. And anonymous links are entirely unaffected, because they never authenticated anyone in the first place. If your estate shares mostly by anonymous link, this deadline barely touches you, which is its own uncomfortable finding.
That work is the wave’s build sheet and I will not walk it here. What belongs in this article is the reason it is critical: it is the only item in the series where doing nothing produces an outage on a date somebody else chose.
Sharing tiers, and the argument the industry gets wrong
You will read everywhere that anonymous links are on by default and must be switched off. That is a layer confusion and correcting it makes the recommendation both smaller and easier to defend.
There are three levels. The organisation level sets the maximum any site may reach. Each site has its own level, which cannot exceed the organisation. And the default site level depends on the site type. Out of the box the organisation permits anonymous links, which is where the claim comes from. But a classic site, a communication site and a modern site with no group all default to organisation-only, and group-connected sites including Teams default to guest tiers depending on whether group owners may add outside people. The two exceptions are the ones that matter: OneDrive defaults to anonymous, and so does the tenant root site.
So the honest statement is that your tenant is capable of anonymous sharing and two surfaces can actually do it today. Which turns a frightening conversation into a precise one. You are closing OneDrive’s side door and the root site, then choosing deliberately per site type, rather than reversing a default the whole business depends on. In an estate where people genuinely need to send files to clients, that distinction is the difference between a change that ships and a change that gets refused.
My position: bring the organisation level down to new and existing guests, drop OneDrive and the root site to match, and permit anonymous links only where a named business process needs them, with expiry required. The federal baseline goes further and forbids even new guests, allowing only existing guests or organisation-only. That is a floor written for federal civilian agencies and it is tighter than I would impose on a professional services firm whose work is collaboration. Cite it, know it, and say which one you are recommending.
| Setting | Value | Why |
|---|---|---|
| Organisation-level external sharing | New and existing guests | The ceiling every site inherits; anonymous stays available only where deliberately granted |
| OneDrive external sharing | New and existing guests, or tighter | The one surface that ships anonymous and the one nobody audits |
| Tenant root site | Reduced from its anonymous default | Ships anonymous, is rarely used deliberately, and is the least visible exposure in the estate |
| Anonymous links, where permitted | Expiry required, view only | No expiry exists by default; an unexpiring anonymous link is a permanent credential in an email nobody can recall |
Domain restriction, which now lives somewhere else
Restrict who you will share with by domain, and do it in Entra rather than in SharePoint. Both surfaces still exist, and before this year they governed different things: the SharePoint list covered file and folder sharing, the Entra list covered invitations. Now that the integration is forced on, the Entra allow or deny list governs both, always. Maintaining the SharePoint list as well means maintaining two lists that can disagree, and one of them no longer decides anything a user experiences.
Choose allow or deny deliberately, because the two express opposite postures. An allow list is a statement that collaboration is bounded and enumerable, which suits regulated work and partner-heavy estates. A deny list is a statement that collaboration is open with named exceptions, which suits most commercial businesses and is honest about the fact that nobody can enumerate their partners in advance. Pick one, write down why, and do not run both.
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
# The three levels, read together
Get-SPOTenant | Format-List SharingCapability,OneDriveLoopSharingCapability,DefaultSharingLinkType,DefaultLinkPermission
Get-SPOSite -Identity https://<tenant>.sharepoint.com -Detailed | Format-List SharingCapability
# Which sites are more permissive than you think
Get-SPOSite -Limit All | Where-Object { $_.SharingCapability -ne 'Disabled' } |
Sort-Object SharingCapability | Format-Table Url,SharingCapability
# Domain restriction: read it, then manage it in Entra rather than here
Get-SPOTenant | Format-List SharingDomainRestrictionMode,SharingAllowedDomainList,SharingBlockedDomainListThe identity seam, and a decision the platform made for you
Guest identity was governed in the identity baseline: who may invite, whether guests need multifactor authentication, whether their access gets reviewed, and what a guest can see of your directory. None of that is restated here. What matters at this seam is that those controls now reach further than they did when they were written, because they govern file sharing too.
One consequence settles a question the identity wave left open. Email one-time passcode authentication in Entra is the fallback for guests who have no account Microsoft can federate with, and after the integration it is the mechanism that carries external file sharing for unmanaged recipients. So disabling it, which reads on the settings page like sensible hardening, breaks external sharing tenant-wide for exactly the population most likely to need it. Leave it enabled. If you were told to turn it off, that advice predates the change.
Note also that SharePoint’s own one-time passcode is not the same thing and is not being retired as a concept. What retires is SharePoint’s separate implementation of it. Entra’s continues, as the documented default fallback. Those two facts get conflated constantly and the conflation is what makes people think the whole mechanism is going away.
Teams: three doors, and only one of them is closed
Teams has three separate external doors and administrators routinely believe they have configured one when they have configured another. External access governs chat and calling with people in other organisations. Guest access governs whether outside people can be added to your teams as members. Business-to-business direct connect governs shared channels, where a person from another tenant participates using their own identity and never becomes a guest in yours.
Out of the box the first two are on and the third is blocked in both directions. That last one is the good default and it is why shared channels stay inert until somebody deliberately establishes a cross-tenant trust. It is also the one people most often open casually, because a partner asked for a shared channel and it seemed like a small favour. It is not small. It is a standing trust relationship between two directories.
Microsoft now offers a guided configuration with two named modes, one open and one controlled, and the controlled mode is described as matching what an enterprise tenant already has. Worth understanding the mechanism, because it surprises people: no mode is assigned to you. The experience reads your current settings and reports which mode they amount to, and adjusts if you change something by any other route. So an untouched enterprise tenant reads as controlled because its defaults happen to match, not because Microsoft applied anything.
The difference between the two modes that matters is the third door. Controlled blocks direct connect in both directions; open permits it. Everything else about who can reach you is the same in both, including guest access being on and external access permitting all domains.
Which brings us to the disagreement I flagged in the anchor. Controlled permits all external domains, and the federal baseline requires per-domain only. My position is that per-domain external access is the right call for regulated work, for anyone with a genuine adversary, and for any tenant where the partner list is short and stable. For a business whose staff need to chat with counterparties they met yesterday, a domain allow list becomes a service desk ticket per relationship and it will be abandoned within a quarter. Recommend it where it will survive contact, and where it will not, say so and spend the effort on guest lifecycle instead. An abandoned control is worse than an acknowledged gap.
Two smaller things in the same area. Anonymous meeting join is on by default, and who may start a meeting anonymously is a separate setting from who may join; check both, because the second is the one that lets an outsider open a meeting in your tenant unattended. And federation with trial tenants is blocked by default, which is correct and worth confirming rather than changing.
One operational note that catches delegated administrators. A Teams administrator cannot change direct connect or select the open mode. Those require a Global Administrator. If your managed-service model delegates Teams administration, the person who owns the setting is not the person who owns Teams.
The Teams protection policy nobody knows exists
The mail baseline argued for using Microsoft’s preset security policies rather than hand-building your own. Teams sits outside that entirely. There is exactly one Teams protection policy in a tenant, it is created for you, you cannot delete it, and no preset touches it. If you assigned the Standard preset to everyone and considered the messaging estate covered, Teams was never in scope.
What that policy governs is worth more than it used to be. Zero-hour auto purge for Teams messages, Teams messages held in quarantine, the message entity panel, user-reported Teams items, and Safe Links and Safe Attachments for Teams are all Defender for Office 365 Plan 1 capabilities. Plan 1 became part of E3 and Microsoft 365 E3 on the first of July 2026, and has been in Business Premium for years. So the population that can protect Teams messages is now most of the mid-market, and the guidance telling them they need an upgrade is a year out of date.
Two current limits to state honestly rather than discover later. Quarantined Teams messages are visible to administrators only and users receive no notification, because the policy governing them is administrator-access-only. And auto purge acts on internal messages, not external ones. So the control is real and worth enabling, and it is not the same guarantee you have for mail.
Below all of that, every tenant with any Teams licence already gets built-in malware scanning across SharePoint, OneDrive and Teams, plus near-real-time warnings on malicious links in Teams messages. Warnings, not blocks. It is a floor, not a baseline, and the distinction is the whole reason this section exists.
Connect-IPPSSession
# The singleton. There is one, and you did not create it.
Get-TeamsProtectionPolicy | Format-List Name,ZapEnabled,HighConfidencePhishQuarantineTag
Get-TeamsProtectionPolicyRule | Format-List Name,State,ExceptIfSentToMemberOf
# Confirm Safe Links and Safe Attachments actually reach Teams
Get-AtpPolicyForO365 | Format-List Name,EnableATPForSPOTeamsODB,AllowSafeDocsOpen
Get-SafeLinksPolicy | Format-Table Name,EnableSafeLinksForTeams,EnableForInternalSenders,AllowClickThroughThe critical settings, in brief
| Domain | Setting | Set it to |
|---|---|---|
| External Trust | Guest accounts for legacy external recipients | Created before the October cutoff; inventory complete by end of September |
| External Trust | Organisation-level external sharing | New and existing guests, as the ceiling every site inherits |
| External Trust | OneDrive external sharing | Reduced from its anonymous default |
| External Trust | Tenant root site | Reduced from its anonymous default |
| External Trust | Anonymous links, where permitted | Expiry required, view only, by exception rather than by default |
| External Trust | Domain restriction | One list, managed in Entra, allow or deny chosen deliberately |
| Identity and Access | Email one-time passcode in Entra | Enabled; disabling it now breaks external file sharing |
| External Trust | Teams business-to-business direct connect | Blocked both directions until a named partner justifies a trust |
| External Trust | Teams external access | Per-domain where it will survive contact; all-domains with guest lifecycle discipline where it will not |
| External Trust | Anonymous meeting join and anonymous start | Both checked; they are separate settings |
| External Trust | Trial-tenant federation | Blocked, which is the default; confirm rather than change |
| Data and Email | Teams protection policy | Auto purge on, Safe Links and Safe Attachments reaching Teams, quarantine limits understood |
The next article takes the recommended and optional tiers, where link defaults, guest resharing, container labels and group lifecycle live. The build sheet after it does the October work end to end.
Best Practices
‹ Previous: [BP 3] Collaboration: The Surface You Already Shared
Next: [BP 3.1.1] Build Sheet: The Guest Account Inventory Before October ›
