Oversharing in Microsoft 365: Anonymous Links and Org-Wide Access

Microsoft 365 is the environment where organizations accumulate the most data and understand access the least. A large share of the documents piling up in SharePoint sites, OneDrive folders and Teams channels sits under access nobody consciously granted: an “everyone in the organization” link created before a meeting, an anonymous link sent to a supplier, a payroll spreadsheet dropped into a channel folder open to the whole team. On this platform oversharing is not a configuration mistake; it is the natural outcome of default behaviour.

The layers of sharing: site, library, folder, file

In SharePoint Online, access is defined at four layers, and each inherits from the one above. At site level there are owner, member and visitor groups; at library, folder and file level that inheritance can be broken and unique permissions granted. Once inheritance is broken, every item below that point carries a permission structure independent of its parent, and that structure is not visible on the site administrator’s screen.

OneDrive for Business is each user’s personal site; by default it is open only to its owner, but it widens quickly through sharing links. Teams is not a separate storage layer: every team’s files live in a SharePoint site, every channel’s files in a folder of that site, and files shared in chats sit in the sender’s OneDrive. A user who “drags” a file into a Teams channel has in fact placed it in a SharePoint folder open to every member of the team, and does not experience that as a sharing decision.

The consequence of these layers is that “who can see this file” cannot be answered without looking at the groups of the site the file lives in, whether inheritance was broken, the unique permissions granted on the folder, and the file’s own sharing links. Without a read that combines all four, oversharing cannot be measured.

Three link types, three exposure levels

Sharing links in Microsoft 365 are created at three scopes, and each produces a different exposure level.

Specific people. The link works only for the people named. The access resembles a classic permission entry; it can be traced and revoked.

Everyone in the organization. Every user signed in to the tenant can open the link. It has two side effects: the file becomes visible to all users in internal search, and when the link is forwarded by email or chat, every recipient gains access. A link an HR specialist creates to send a file to a manager is open to everyone in the tenant besides that manager; the specialist remembers it as “I sent it to the manager”.

Anonymous (anyone). No sign-in is required; anyone holding the link reaches the file. This is the type with the highest risk of spreading outside the organization. A proposal sent once to a supplier stays open to everyone the supplier forwards it to, as long as the link has not expired or been revoked.

The first step in oversharing analysis is to collect these link types for every file in the tenant and join them with the content finding. “1,800 files shared by anonymous link” does not produce a priority on its own; “23 files shared by anonymous link that contain a TCKN” does. Seratus converts sharing links into exposure levels in exactly this way and combines them with content classification; details are on the Microsoft 365 integration page.

Where oversharing typically accumulates

Oversharing is not spread evenly across an organization; it concentrates in specific places. HR and payroll documents that accumulate in Teams channel folders are open to every member of the team; as the team grows, so does the access, while the document never moves. Customer lists and contracts travel out of the sales team’s OneDrive folders through “everyone in the organization” links; when the person who created the link leaves, the file stays and the link keeps working.

The third accumulation point is old sites. When a project ends, the site is not archived; members change but permissions remain. If the “Visitors” group of a project site closed four years ago still contains “All Staff”, every document on that site is open to the whole tenant. The fourth is “orphaned” files in OneDrive: a departed user’s OneDrive is deleted after a set period, but during that period the files remain reachable through the sharing links granted before departure.

The common problem at each of these points is the same: sharing was granted once and then forgotten. The special-category guide published by KVKK, Türkiye’s data protection authority, lists limiting the staff who access such data and logging access rights among the basic measures; in Microsoft 365 that measure requires knowing not only who was granted access but which links still work. This article is not legal advice.

Graph and read-only application permissions

The only reliable way to scan Microsoft 365 is Microsoft Graph. Graph exposes SharePoint, OneDrive and Teams files, item permissions and sharing links through a single API. The connection is made not on behalf of a user but with an application identity, which means the scan is not tied to an employee’s session and not limited by that employee’s permissions.

Seratus connects to Graph with read-only application permissions. File content is read, permissions and links are listed; no item is modified, no link is revoked, no file is moved. That distinction gives the security team a clear answer to the tenant administrator’s question “what can this tool do”: it can read, it cannot write. Remediation actions run under a separate right and a separate approval flow; the discovery permission and the action permission never mix.

No agent is needed. Nothing is installed on user computers, on servers or in the tenant. The scan runs from the Seratus server inside the organization towards Graph; data never leaves the Seratus server for any external service.

Delta scanning: following what changed

Even a mid-sized tenant can hold millions of items. Rescanning every library from scratch each day takes hours, consumes the Graph call budget and lets findings go stale. Delta scanning solves this: after the first full scan, Graph’s delta queries return only the items added, changed or deleted; Seratus processes those and updates the inventory, classification and sharing state.

What makes delta scanning matter for oversharing is that it catches link changes. An anonymous link added to a file today appears as a finding in the next delta cycle; a link revoked yesterday drops out. The “anonymous links in the tenant” list is therefore not a snapshot but a continuously updated state.

An interrupted scan resumes where it stopped. A network outage, a maintenance window or a temporary throttling response on the Graph side does not reset the scan state; the scan continues from the last processed item. This applies both to the first full scan and to the delta cycles.

Prioritization: where content, link and identity meet

The reliable way to rank oversharing findings is to intersect three pieces of information: what the file contains, which link type it was shared with, who created the link and whether that person is still with the organization. A file shared by anonymous link that contains special category data sits at the top. A file shared organization-wide that contains a TCKN or IBAN comes next. A link created by a departed user is a finding type of its own regardless of content, because the link’s owner can no longer be asked “is this still needed”.

Seratus builds that intersection on the access and exposure graph. Microsoft 365 links sit in the same graph, on the same exposure scale, as file server ACLs and database roles, so a payroll file sitting under broad access both on a file server and in SharePoint is visible at a glance. Findings land in the “gaps” list that lowers the KVKK readiness score and enter the remediation flow.

How Seratus closes these gaps

Gap: nobody knows which files are shared by anonymous or organization-wide link. Seratus collects the sharing links of SharePoint Online, OneDrive for Business and Teams files through Graph, converts anonymous and “everyone in the organization” links into exposure levels and joins them with the content finding.

Gap: scanning depends on a user account or an agent. The connection uses read-only application permissions; no agent, user session or write permission is required. Discovery permission and action permission are separate.

Gap: findings go stale. After the first full scan, delta scanning processes only changed items; newly added and revoked links are reflected in the next cycle. An interrupted scan resumes where it stopped.

Gap: nobody knows what the shared file contains. Data classification and Turkish-specific detection (TCKN, IBAN, phone, health data) tag each file with type, confidentiality level and business category; “special category data overshared” appears in the KVKK gaps list.

Gap: links created by departed users and stale site permissions. The access graph flags orphaned access and inherited broad permissions as separate findings; LDAP/directory synchronization keeps user status current.

Gap: links revoked without a record. Permission removal, link revocation and quarantine are assigned to an owner in the remediation and evidence flow, executed under a separate approval right and written to the audit log with who, when and why; reports export as PDF, Excel or CSV.

Takeaway

Oversharing in Microsoft 365 is the result of convenience, not malice: creating a link is one click, revoking it never comes to mind. The way to manage this environment is not to ban sharing but to see the type of every link in the tenant, the content of the file and the status of the person who created the link in one continuously updated graph, and to turn remediation into an approved, recorded action. A read-only Graph connection and delta scanning provide that visibility without touching the tenant and without going stale.