SharePoint and OneDrive sharing defaults worth changing on day one

A new Microsoft 365 tenant is configured to make sharing easy. That is a reasonable product decision — friction in collaboration tools is why people email attachments instead — but it means the out-of-the-box position is more permissive than most organisations would choose if asked.

The gap matters because sharing settings are retroactive in one direction only. Tightening them later does not retract the links already created.

The threat: what the permissive position actually allows

Three specific exposures, in order of how often I find them.

Anonymous links that never expire. A link that requires no sign-in, works for anyone who has it, and is valid indefinitely. It gets pasted into an email, forwarded, included in a thread with a third party, and eventually sits in an archive somewhere outside your control. There is no audit of who used it, because there is no identity involved.

Unmanaged guest access accumulating. Every externally shared item can create a guest. Over a few years a tenant accumulates hundreds of guests from organisations that are no longer customers, suppliers or partners, each retaining access to whatever they were shared.

OneDrive as an exfiltration path. A departing employee shares their own OneDrive content to a personal address. Legitimate sharing capability, entirely ordinary user action, and it does not look like an incident in any log unless you are looking for it.

None of these require a compromise. They are the product working as configured.

Exposure: read your current position first

Before changing anything, establish what is currently true. The values differ by tenant age and by what previous administrators did, so read rather than assume.

Connect-SPOService -Url 'https://contoso-admin.sharepoint.com'

Get-SPOTenant | Select-Object SharingCapability, DefaultSharingLinkType,
    DefaultLinkPermission, FileAnonymousLinkType, FolderAnonymousLinkType,
    RequireAnonymousLinksExpireInDays, ExternalUserExpirationRequired,
    ExternalUserExpireInDays, SharingDomainRestrictionMode, PreventExternalUsersFromResharing

Then get the scale of what already exists: how many anonymous links are live, how many guests the tenant holds, and which sites carry the most external sharing. The sharing reports in the SharePoint admin centre and the audit log are the sources. That number is usually the thing that wins the argument for changing the settings.

Hardening: the six settings that matter

1. Tenant sharing capability

SharingCapability is the ceiling for the whole tenant. The options run from disabled, through existing guests only, to new and existing guests, to anyone — where “anyone” enables anonymous links.

For most organisations ExternalUserSharingOnly — new and existing guests, authenticated — is the right ceiling. It keeps external collaboration fully available while ensuring every external access has an identity behind it, which means it can be audited, reviewed and revoked.

Site-level settings can be more restrictive than the tenant, never less. Set the tenant ceiling deliberately, then relax specific sites that have a genuine anonymous-sharing need.

2. Default sharing link type

DefaultSharingLinkType decides what a user gets when they click Share without thinking — which is most of the time. The permissive default is an organisation-wide link.

Set it to Direct — specific people. This single change does more than any other, because it makes the thoughtless action the safe one. Users who genuinely want a broader link can still choose it; they just have to choose it.

3. Default link permission

DefaultLinkPermission set to View rather than Edit. Same reasoning: the default action should grant the least useful access that is likely to be sufficient, and edit rights should be a decision.

4. Anonymous link expiry and permission

If you do allow anonymous links, bound them:

• RequireAnonymousLinksExpireInDays — set an expiry. Thirty days is a reasonable starting point. An anonymous link with no expiry is a permanent, unauthenticated access grant.
• FileAnonymousLinkType and FolderAnonymousLinkType — set to View. An anonymous edit link on a folder allows an unauthenticated party to add content to your tenant.

5. Guest expiry and reauthentication

ExternalUserExpirationRequired with ExternalUserExpireInDays automatically expires guest access that has not been used. This is the control that stops the guest population growing without bound, and it requires no ongoing administrative effort.

Pair it with access reviews for guests, so that continued access is affirmed by someone who knows whether it is still needed.

6. Domain restrictions, where they fit

SharingDomainRestrictionMode allows an allowlist or a blocklist of external domains. An allowlist is a strong control for organisations that collaborate with a known, stable set of partners, and an administrative burden for everyone else.

Use it where the partner list is genuinely bounded. Do not adopt it because it sounds thorough — a list that has to be edited for every new relationship becomes a queue, and the queue becomes a reason people use email attachments instead.

Detection

Settings are the preventive half. The detective half is worth building at the same time.

• Alert on anonymous link creation for sites holding sensitive content. In a tenant where you have set the default to specific people, anonymous link creation is deliberate and rare, which makes it a high-quality signal.
• Alert on sharing to personal email domains, particularly from OneDrive. Combined with a leaver process this catches the common exfiltration pattern.
• Review the guest population quarterly, and the sites with the most external sharing.
• Watch for large download volumes from OneDrive, which is the other half of the same pattern.

The audit log records sharing operations with the actor, the resource and the target. Route the high-signal subset somewhere a person reads, rather than relying on a quarterly report.

Validation

Confirm behaviour rather than configuration:

• As a test user, share a file and confirm the default link offered is specific-people, view.
• Attempt to create an anonymous link and confirm the result matches your intent — either refused, or created with the expiry you configured.
• Confirm an existing guest can still reach what they legitimately need. Tightening the tenant ceiling can revoke access that a business process depends on, and finding that out from a client is worse than finding it in testing.
• Verify the alerts fire by performing the action yourself.

The links that already exist

This is the part people miss. Changing SharingCapability sets the ceiling for new sharing. Existing anonymous links generally continue to work, and existing guests retain their access.

Remediation is therefore a separate exercise from configuration:

1. Report on existing anonymous links, by site.
2. Decide, with the site owners, which are still needed.
3. Revoke the rest — which breaks them for whoever was using them, so it needs communication rather than a quiet cleanup.
4. Review the guest population and remove what has lapsed.

Do the configuration change first so the problem stops growing, then work through the backlog. Doing them in the other order means remediating a population that is still expanding.

Rollback

Every setting here is reversible by setting it back, and the effect on new sharing is immediate. What is not reversible is the sharing that was revoked during remediation: a revoked anonymous link cannot be un-revoked, only reissued as a new one.

That asymmetry argues for doing the remediation with site owners rather than centrally and silently, and for keeping a record of what was revoked so a reissue is possible when somebody asks.

Honest limits

These settings bound external sharing. They do not address internal oversharing — a site open to everyone in the organisation containing material that should be restricted — which is a permissions and information architecture problem, and usually a larger one.

They also do not classify or protect the content itself. Sensitivity labels and the wider governance layer are a separate programme, and one that depends on this permissions work being done first — labelling content that is already overshared changes what the label says, not who can reach it.

Verification and limits

The tenant sharing settings named above, their effect on new versus existing sharing, guest expiry, anonymous link expiry and the site-cannot-exceed-tenant relationship were checked against current Microsoft documentation on 20 September 2026. The recommended positions are my own, stated as recommendations.

No tenant was reconfigured for this article. These settings change what your users can do and can revoke access that a business process depends on — read your current values, pilot on a small number of sites, and communicate before remediating existing links. Defaults for new tenants change, so verify your own rather than relying on the description here.

References

• External sharing overview
• Manage sharing settings for SharePoint and OneDrive
• Set-SPOTenant
• Limit accidental exposure when sharing outside your organisation