Imagine somebody proposed a new form of access to your organisation's data with the following properties.
It grants access to whoever holds it. It doesn't identify the person using it. It never expires unless someone remembers to set an expiry. It's created by ordinary employees, thousands of times, without approval. It gets forwarded, pasted into chats, copied into tickets and archived in mailboxes you don't control. It keeps working after the account that created it is disabled. And there's no record anywhere of who has used it.
You'd reject that outright. It's a bearer credential with no identity, no lifecycle and no audit trail.
That's an "anyone with the link" URL, and a typical Microsoft 365 tenant has thousands of them.
Why nobody treats it like one
Sharing links don't feel like credentials, for reasons that are entirely understandable.
They're created by the sharing dialog, which is a collaboration feature rather than a security screen. They're expressed as URLs, and URLs feel ephemeral, like something you paste and forget. They're granted by employees rather than by administrators, so they never pass through an approval process. And they're individually tiny: one link to one document, which is obviously fine.
The problem is entirely one of accumulation and time. Any single link is a reasonable decision. Ten thousand links, created over eight years, by people who have since left, pointing at documents that have since become sensitive, is a completely different object, and no single decision along the way was wrong.
Consider also what a link's scope actually means.
| Scope | Who can use it |
|---|---|
| Anyone | Anybody holding the URL. No sign-in. No identity recorded. |
| People in your organisation | Any employee with the URL, including people the sharer never considered. |
| Specific people | Named recipients, authenticated. The one that behaves like a permission. |
Only the third has an identity attached. The first two grant access to a population rather than to a person, and the first grants it to a population you can't enumerate.
The property that matters most in an incident
Here's the part that turns this from a hygiene topic into an identity-attack topic.
An account gets compromised. The attacker reads what they came for, and before the session ends they create sharing links on the folders they're interested in. Anyone-scope links.
You detect the compromise. You do everything right: disable the account, revoke every session, reset the credential, review the sign-ins.
The links keep working.
A link is a grant that lives on the item, not a permission held by the account. Disabling the creator doesn't revoke it. Revoking sessions doesn't touch it. The attacker no longer needs the credential they stole, because they left themselves a set of URLs that don't require one.
This is the most common way an identity incident quietly continues after being declared closed, and it's usually missed because containment checklists are written around the account. The account is the thing that got compromised, so the account is the thing that gets remediated, and the artefacts the session created are left behind, looking like ordinary sharing.
If your incident process doesn't include "enumerate links created during the compromise window", you have this gap. It costs nothing to add and it's the single highest-value item in this entire post.
The same reasoning applies to the other artefacts a session leaves: forwarding rules, delegate access, and application consents. All of them outlive the account.
Why links accumulate faster than anyone thinks
Three mechanisms, none of which anybody controls.
The default is doing most of the work. Whatever your tenant's default link type is, that's what most links are, because most people accept the default. If the default is organisation-wide, then most sharing in your organisation is organisation-wide, regardless of what your policy document says. This one setting probably determines the shape of your entire link inventory.
Links propagate beyond the sharing event. The link gets sent to three people. One forwards it to a partner. Someone pastes it into a channel with two hundred members. It ends up in a ticket, a wiki, an archived mailbox at another company. The original sharing decision covered three people. The actual reach is unbounded and unknowable, and none of that propagation is visible in your tenant, because it happens outside it.
The document changes after the link is made. A link is created to a folder holding a draft. Over the following two years the folder accumulates contracts, financial models and personal data. The link was appropriate when it was created and nobody re-evaluated it, because there's no event that would prompt anyone to.
That third one is the quiet killer, and it's an argument for expiry over review. Reviewing every link is impossible at scale. Expiring them means the mismatch between what a link was for and what it now reaches has a bounded lifetime.
What to actually do
A sequence that works on a real tenant, ordered by value against disruption.
Fix the default first. Change the default link type so new sharing is scoped narrowly, and set a default expiry on anonymous links. This doesn't touch a single existing link and it stops the inventory growing in the wrong direction. It's the highest-leverage change available and it takes minutes.
Find the intersection, not the total. The total link count is a scary number that doesn't help. The list that helps is anyone-scope links on content that carries sensitive data. That's a short list, it's unambiguous, and nobody argues about it in a review meeting.
Then the second intersection. Organisation-wide links on sensitive content. Larger, still tractable, and this is usually the biggest single contributor to what Copilot surfaces during a rollout, because organisation-wide is how people make things easy for colleagues.
Then links created by departed users. Nobody owns them, nobody will miss them, and the person who could explain them has gone.
Then dormant links. Created long ago, never used. Removing access nobody exercises is the safest cleanup there is.
Do it with a review window, not a script. Removing links at scale is the kind of change that breaks somebody's Monday. Staging the removals as proposals with a countdown, so owners can object and anything urgent can be approved immediately, is the difference between a cleanup that runs and a cleanup that gets rolled back after the first complaint.
The measurement worth keeping
One number, tracked over time, tells you whether this is under control: the count of anyone-scope links on sensitive content.
It's better than total link count because it's actionable. It's better than a policy statement because it's observed. And it's the right thing to show a board, because the trend line answers the question they're actually asking, which is whether the situation is improving rather than what the absolute number is.
If it only ever goes down after a cleanup and then climbs back, your defaults are wrong and no amount of remediation will fix that.
How 1Security does it
Sharing links are a first-class resource rather than a property buried inside file permissions. They're inventoried, filterable by scope, by expiration, by whether they carry a password, by creator and by creation date, so "everything created during this window" is a filter rather than an investigation.
They're also part of the permission graph. Access to a file arrives through five paths, and a link is one of them, so a link's contribution shows up in effective access and in blast radius rather than being counted separately. When a user's access to a set of files is revoked, the links are resolved as one of the paths that access arrives through, which is what stops "we removed their access" from being a sentence nobody can verify.
The intersections are policies with live counts against your live graph: files with organisation-wide links and sensitive content, sites containing sensitive information and shared with anyone. Each shows how many resources match right now, before you enable anything, so the size of the problem is visible without committing to a fix.
Remediation covers removing links by scope, removing a user from a link, restricting sharing capability, setting anonymous-link expiry and expiring external access, executed natively as SharePoint operations so everything is visible and reversible in the Microsoft admin centres. All of it stages behind a review window, seventy-two hours by default, with approve, reject-and-snooze, or let the clock run.
Frequently asked questions
Is anonymous sharing always bad? No. It's the right tool for genuinely public material and for sharing with people who can't authenticate to your tenant. What makes it dangerous is that it's also the path of least resistance for everything else, so it gets used far outside its intended case.
Can I see who used a link? For anonymous links, not in a way that identifies a person, which is the point. That's the property that makes them a bearer credential rather than a permission, and it's why they need expiry rather than review.
Won't expiry break things? Some things, briefly, and the person affected re-shares. Weigh that against a link created in 2019 to a folder that now holds contracts. A default expiry on new links breaks nothing at all, which is why it's the first change to make.
What about links created before we had a policy? They're the bulk of the problem and the reason the intersection cuts matter. Start with anyone-scope links on sensitive content, which is short and uncontroversial, rather than trying to review everything.
