Every “Copy link” click in Microsoft 365 is an access-control decision made in half a second by someone thinking about a deadline — and the tenant’s defaults decide what that half-second grants. Out of the box, those defaults favor frictionless collaboration, which is why mature tenants accumulate a sediment of exposure: “anyone” links to sensitive files forwarded who-knows-where, guests from finished projects still holding access, and nobody able to say what’s reachable from outside. The fix isn’t banning sharing — external collaboration is the point of the platform — it’s making the defaults deliberate. Here’s the working configuration.

The link types, translated

Understanding one menu explains most of the risk. “Anyone with the link” — a bearer key: no sign-in, forwards infinitely, works for whoever holds it, forever unless expired. Legitimately useful for genuinely public material; catastrophic as a default habit for anything else, because its whole nature is that you lose track of it at the first forward. “People in [your organization]” — internal-only; safe-by-construction for everyday work, and the right default. “Specific people” — named recipients, sign-in verified (external recipients prove control of their email); the correct tool for real external collaboration, because access is attributable and revocable per person. The entire sharing-hygiene project is nudging the organization from the first type toward the last two — mostly via settings, not memos.

The tenant settings worth an afternoon

Five decisions, made once at the admin level, alongside the rest of the tenant review:

  1. Default link type = internal. The single highest-leverage change: the hurried half-second now grants the safe thing, and external sharing becomes a chosen act rather than an accident of the default.
  2. Expiration on every “anyone” link — 30 days is a sane ceiling. The bearer key stops being immortal; the genuinely needed share gets re-issued consciously.
  3. Sharing scoped by site sensitivity. The classification map cashes in again: the Restricted-tier sites (finance, HR, client records) get external sharing disabled at the site level — not policed, structurally impossible — while project and collaboration sites stay open for business. Tiered beats uniform in both directions.
  4. Guest access allowed, but governed: guests arrive by invitation to specific Teams and sites, and access reviews put an expiration question on their existence — because the guest from the 2023 project is the stale vendor access problem wearing a collaboration badge.
  5. Reporting turned on and read occasionally: the admin reports listing what’s shared externally — the same who-can-reach-what audit that Copilot readiness demands anyway — reviewed annually, with the surprising finds (there are always surprising finds) cleaned as they surface.

The human half: make the right way the easy way

Settings shape behavior; a little enablement finishes the job. Teach the two-sentence version in the awareness rotation: internal links for colleagues, “specific people” for outsiders, and Restricted data travels by portal or governed link — never a plain attachment. Give the recurring external-collaboration cases a sanctioned home — a properly configured shared site or Team with guests beats fifty ad-hoc file links, and it’s what people invent worse versions of when no official answer exists. And when DLP arrives, sharing policy is where it plugs in: the warn-prompt on the SSN-laden attachment is this article’s settings, enforced at the moment of the mistake.

The bottom line

External sharing risk is mostly a defaults problem: set internal as the default link, expire the bearer keys, disable sharing structurally on the sensitive sites, govern guests with end dates, and read the external-sharing report once a year. An afternoon of tenant settings plus two sentences of training — and the half-second sharing decision, made a thousand times a month across the company, starts landing safe by design instead of exposed by default.