On almost every tenant we examine, anonymous sharing links created years ago are still live, pointing at files nobody watches any more. This is not a vulnerability: it is a default nobody closed after the migration.
The question to ask is not "have we enabled external sharing". It is: how many links are live today, pointing at what, created by whom, and do they ever expire?
What an anonymous link actually is
An "anyone with the link" share is an access token. Not an invitation, not a right granted to a person: a string that opens the file for whoever presents it.
Three consequences the interface wording does not convey:
It travels. It goes into a thread, which gets forwarded, archived, exported. Every copy works as well as the original.
It does not authenticate. No record of who opened the file, only that it was opened. In the event of a leak, you cannot say by whom.
It follows the file. If the document is updated, the link serves the new version. A price list shared in 2022 exposes your 2026 pricing.
What we look at in an audit
Five measurements, in this order:
- The level allowed at tenant scope and, separately, at each site. A restrictive tenant with three permissive sites is not a restrictive tenant.
- Whether a default expiry exists on anonymous links, and how long it is.
- How many anonymous links are live, and how old they are. This is the number that lands in a board meeting: it often runs into the hundreds.
- The default permission — an anonymous edit link is not an anonymous view link.
- The sites that should never have been shareable: HR, executive, legal, production data.
Closing it without blocking anyone
This is where most projects stall, because fear of breaking a workflow wins. That fear is justified: cutting external sharing in one move, in a team that exchanges with customers daily, is an incident.
The order that works:
1. Set an expiry, cut nothing
A maximum lifetime on new anonymous links — thirty days is a good starting point — breaks no ongoing workflow. It simply changes the rule going forward: whoever needs a link for longer recreates it.
This is the highest-yield step of the lot. It stops the bleeding before you deal with what already exists.
2. Make view-only the default
Edit sharing stays possible, but becomes an explicit choice rather than the prefilled value. Most external shares never needed write access.
3. Handle the backlog by age, not by volume
Do not try to review everything. Take links older than twelve months: almost all are functionally dead, and they carry most of the risk. Revoking them generates very few support calls — nobody is using a year-old link.
4. Restrict sensitive sites, one at a time
HR, executive, legal: these move to internal sharing only. That is a per-site decision, not a global policy, and it is taken with the teams concerned.
Why it comes back
You can do this work perfectly and find the same situation eighteen months later. A new site is created for a project, with default settings. A team asks for a partner exception, and gets it. A migration imports data along with its original shares.
This is ordinary configuration drift: every event is legitimate, and their sum rebuilds the problem. What changes the outcome is not closing things better, it is measuring continuously.