SharePoint's Default Links Are Public and Editable. Fix That Without Flooding Your Help Desk

Most of SharePoint Online's sharing settings are not secure by default, and the default sharing link is the clearest example: a public link, no authentication required, with edit rights. Securing SharePoint is a multi-layered job that gets genuinely complex because of how permissions work, so this post focuses on one layer: the default sharing policies for links generated across all documents in an organization, and the real end-user impact, internal and external, of tightening them. Other layers of the sharing permission stack deserve their own posts.

Why does the global setting not tell the whole story?#

SharePoint permissions nest. The global settings cascade down through each site, document repository, and individual document, and any of those layers can be configured more restrictively without inheriting the global policy. We will stay at the global and site layers here. The pattern that matters: a common setup is a more open global policy with specific sites restricted down, for example a site whose documents can never be shared externally regardless of what the tenant default allows.

What happens today when a user clicks Share?#

When a user copies a link or clicks share on a SharePoint or OneDrive document, the link inherits your global policy unless the site overrides it. By default that means Anyone links: public access, no authentication, and the document is editable.

Picture that default against users sharing sensitive documents, and the case for changing it makes itself.

The SharePoint admin center offers four options for external sharing:

• Anyone: public links, unauthenticated users can access
• New and existing guests: users specify the email addresses of recipients. A recipient who is not already a guest in the company directory goes through a workflow to consent to being added as an external user
• Existing guests: recipients must already be listed as external users. Depending on Entra settings, only certain users, such as admins or those holding the Guest Inviter role, can invite new ones
• Only people in your organization: no external sharing at all

Moving off public links as the global policy sounds like the obvious call. But Existing guests or organization-only as a global setting is not feasible in 99.9% of the organizations you manage, which leaves New and existing guests. Before flipping that switch, walk through what your external recipients will actually experience, because this is where the support tickets come from.

What does the guest experience look like under New and existing guests?#

With the global policy on this setting, the share dialog defaults to people in your organization only, users can still specify external individuals, and the Anyone option is grayed out:

So far so good. The friction starts on the receiving end. Say a CloudCapsule user shares with someone in the external Tminus365 tenant. The recipient is first prompted to sign in with their Microsoft 365 account, then sees this:

Two observations: the wording is mildly deceptive given what comes next, and Microsoft's copyright year on that screen could use an update.

If the recipient is not already an external user in the sharing organization, the next screen is a consent prompt:

This consent exists so the sharing tenant can log activity in this user's context for the shared document and any future ones. On acceptance, the recipient lands in the directory as an external user:

The consent flow is one-time: as long as the person remains an external user in Entra, future shares skip it.

Then comes the bigger catch. If a Conditional Access policy applies MFA to all users, which it should, the guest is now taken through MFA setup tied to their guest access. Two things to know:

• MFA in their own organization does not carry over. They will register a new MFA method in the guest context.
• Your policy wins. If they use SMS at home but you enforce Authenticator only, Authenticator is what they will set up.

We are all for enforcing more protection, but every one of these layers is a place the experience can break down and become a ticket asking what to do.

What about recipients without a Microsoft account?#

The experience degrades further for recipients with no Microsoft 365 account at all. Gmail is the most common case. The sore point: these users still land on a Microsoft login page when they click the link:

For many of them, that page is a full stop. Intuition says "I don't have a Microsoft account, what now?" The answer, which the page does not advertise, is that they can proceed without one: enter the email address the document was shared to and hit next, and they are offered a one-time code instead:

The code arrives by email:

The same MFA consideration applies after that. The odds of a breakdown run even higher with consumer mailboxes, since those users may have no MFA anywhere and are less likely to have something like Authenticator installed.

How do you tighten defaults without the support nightmare?#

If the previous two sections read like a help desk incident forecast, that is the point, and it is why we recommend a staged progression instead of flipping the global policy on day one:

1. Leave the default external sharing setting at Anyone
2. Change the default file and folder link settings (detailed below)
3. Train users up before moving the default to New and existing guests
4. Apply granular site-level restrictions while the global Anyone setting remains, for example setting a Finance site full of sensitive internal documents to block sharing outside the organization

Change the default link, keep the capability#

In the file and folder link settings, modify the defaults to the following:

These settings change what the generated link is by default, not what users are allowed to do. Users can still manually broaden a link when they share, but the proliferation of Anyone-links-with-edit drops sharply. The model is least privilege with an escape hatch.

One trap to train around: the default View permission bites users who want to co-author but never adjust the link. The recipient ends up either reaching back out because they cannot edit, while the sender contacts you because they do not know how to change it, or saving a local copy so two diverging versions of the document now exist. Brief users on changing the link type when co-authoring is the goal.

Restrict specific sites below the global policy#

Every site inherits the global settings until you individually change it, which makes site-level overrides the precision tool: more protection on the sites that need it, zero impact on everyone else. In this example, the global external sharing policy is still Anyone, but the Communication site has been moved to New and existing guests:

Two housekeeping settings#

• Guest users accumulate. Periodically review external users in the directory and delete the ones with no sign-in for 30+ days.
• A couple of additional sharing settings let you expire Anyone links and guest access automatically:

How do you see these settings across every customer?#

CloudCapsule lets you explore this configuration across your customers, with the policy definitions mapped to the CIS Controls. Specifically, it identifies:

• Your default sharing policy settings
• All of your existing SharePoint sites
• Dormant guest users

SharePoint administration gets complex and confusing, but that is not a reason to skip data protection in the environments you manage. Plan the rollout, understand the customer's basic data flows with external parties, and stage the changes so the security improvement does not arrive wrapped in a ticket queue.