Sharing Links That Outlive Their Purpose: Governing External File Access

Data protectionNovember 03, 2026

Sharing links beat email attachments, until they quietly outlive the project they were made for. Here is how to make external access authenticated, time-limited and reviewed, with a checklist for this week.

Abstract navy illustration of flowing teal and blue lines converging on a stack of outlined panels, a few lines fading out before they arrive, representing shared access that ends on time

A sharing link is one of the most useful tools in modern collaboration. Instead of emailing copies around, you grant access to the original file, keep a single version and can, in principle, take access back. The trouble is the "in principle". Links are created in seconds, almost never reviewed, and often outlive the project, the contract and sometimes the employee who made them.

The risk is not theoretical. In 2019, researchers at Adversis found that dozens of organisations had exposed hundreds of thousands of documents, including passport photos, bank details and VPN configurations, through public Box links that could be discovered by guessing paths, as CyberScoop reported. The platform was not breached; the sharing settings simply did what they were configured to do. This guide sets out how to keep the convenience of links while making sure access ends when the need does.

Why links drift out of control

Every collaboration platform offers roughly the same spectrum of link types. At one end is the "anyone with the link" share: no sign-in, and the link works for whoever holds it. In the middle are links scoped to your organisation. At the other end are links for named people who must authenticate.

Microsoft's own documentation is blunt about the trade-off. For "Anyone with the link", it notes that forwarded links work internally or externally, "but you can't track who has access to shared items or who has accessed shared items." Google describes its equivalent the same way in the file exposure report documentation: anyone inside or outside your domain who has the link can open the file.

Three things make unauthenticated links drift:

No identity at the point of use. You cannot revoke access for one person, only for the link as a whole, and logs cannot tell you who opened it.
No natural end date. Files are retained for years. A link made for a two-week due-diligence exercise keeps working until someone deletes it.
Defaults decide most outcomes. Users rarely change the link type the share dialog offers them, so the tenant default effectively becomes your sharing policy.

What a reasonable baseline looks like

You do not need to invent a policy from scratch. The US Cybersecurity and Infrastructure Security Agency publishes secure configuration baselines for Microsoft 365 and Google Workspace under its SCuBA project, and Binding Operational Directive 25-01 makes the mandatory ones compulsory for US federal civilian agencies. Even if you are not a US agency, they are a well-reasoned, openly published starting point.

For SharePoint and OneDrive, the SCuBA SharePoint baseline says the default sharing scope should be "Specific people", default permissions should be view only, "Anyone" links should expire in 30 days or less, and people who use a one-time verification code should reauthenticate within 30 days. Its rationale for expiry is worth quoting: without expiration, "access is indefinite."

For Google Drive, the SCuBA Drive and Docs baseline asks for external sharing restricted to allowlisted domains, warnings when users share outside them, "Private to owner" as the default for new items, and recommends disabling "anyone with the link" in organisational units that allow external sharing.

The US federal settings are strict, and many businesses will choose a looser position, for example allowing unauthenticated links for marketing material. The point is to make that a deliberate decision per type of content, not an accident of defaults.

Prefer identity over possession

The single most effective change is to move external sharing from "whoever holds the link" to "this named person, after signing in". Named, authenticated shares give you three properties that unauthenticated links cannot:

Per-person revocation. You can remove one partner without breaking access for the rest.
Accountability. Access logs show which identity opened or downloaded a file.
Lifecycle hooks. Guest accounts can expire. Microsoft lets administrators set guest access to expire automatically after a set number of days, and to limit external sharing to listed domains or to members of specific security groups.

Where you do keep unauthenticated links for low-sensitivity content, constrain them: view-only by default, a mandatory expiry, and preferably limited to specific sites or teams rather than the whole tenant.

A checklist for this week

These steps are platform-neutral; the settings exist in some form in every mainstream collaboration suite.

Measure current exposure. Export a report of files shared externally and by public link. In Google Workspace, the file exposure report shows sharing events by method for up to 180 days; other suites offer comparable reporting through their admin and audit tools. Note the top external domains and the most-viewed public files.
Change the default link type. Set the share dialog to offer "Specific people" or "Only people in your organisation" first, so that an unauthenticated link requires a conscious choice.
Make public links view-only and time-limited. Require an expiry, 30 days is a defensible ceiling, and restrict permissions to view. Check how your platform treats existing links when you shorten the limit; in SharePoint, existing links are shortened to the new limit, but lengthening it does not extend them.
Set guest expiry and reauthentication. Give guest access a lifetime that matches typical project length, and require verification-code users to reauthenticate regularly.
Restrict by domain or group where you can. Allowlist partner domains for sensitive sites, or allow only a trained group of users to share externally.
Tie sharing to classification. Use sensitivity labels or data loss prevention rules to block public links on content marked confidential or containing regulated data.
Clean up the backlog. Review the oldest and most-viewed public links with their owners, and remove those with no current purpose. Do this before tightening defaults causes a rush of support tickets, so you can explain the change.
Put it on the calendar. Add external sharing to your quarterly access review alongside user and admin accounts.

Plan for the cases that still need openness

Some workflows genuinely need frictionless sharing: press kits, public documentation, file requests from customers who have no account. Treat these as named exceptions. Put them in a dedicated site or folder with its own settings, keep anything sensitive out of it, and assign an owner who reviews its contents. File upload links deserve particular care, since they let unknown parties place content inside your environment; scan uploads for malware before anyone opens them.

Encryption also matters here. Content that is end-to-end or client-side encrypted reduces what a misconfigured link can expose, but it does not remove the need for expiry and review, because a recipient who is granted access can still decrypt and keep a copy.

Conclusion

Sharing links are not the problem; unmanaged ones are. Prefer authenticated, named shares, make the safe option the default, give every external link and guest an end date, and review what remains on a schedule. None of this requires new tools, only settings most organisations already own and a recurring hour on the calendar.

If you are evaluating storage built around controlled sharing, OXU Drive is Oten's offering for ultra-private storage and safe sharing; the checklist above applies whichever platform you use.