Modern Attachments in eDiscovery

No — not by default. Every US federal court to rule squarely on the question since 2021 has held that a hyperlink to a cloud-stored file is not a traditional attachment, and that linked files do not inherit the parent message’s document-family relationship. That default holds because bulk link resolution has been found infeasible or disproportionate, not because linked files are irrelevant. They remain discoverable on a targeted request, and the default flips entirely the moment you stipulate otherwise in an ESI protocol. Two producing parties have already learned that the expensive way.

A modern attachment (also called a cloud attachment, linked attachment, or pointer) is a URL inside an email, Teams post, or Slack message that resolves to a file living in SharePoint, OneDrive, Google Drive, or Box. The bytes never travel with the message. What the recipient received was a pointer and a permission, and because the target file stays live and editable after the link is sent, the document the sender actually shared may no longer exist by the time anyone collects it.

What it is not

A modern attachment is not a traditional attachment. A traditional attachment is a copy — frozen at send time, carried inside the message, and bound to it by a parent-child relationship that every review platform understands. A modern attachment is a reference with no frozen copy and no inherent family relationship, which is precisely the gap the case law has spent five years arguing about.

It is also not the same thing as a link to a public web page. A link to a news article or a vendor’s pricing page is outside your possession, custody, or control, so it raises no production obligation. The test that makes a link a modern attachment is whether the linked file sits in a system the producing party controls. And it is not short-message data — although the two travel together, because the same ESI protocols now govern both, and Slack and Teams messages are where modern attachments are densest.

Finally, it is not solved by collecting the whole Drive. Custodial file-store collection gets you the files; it does not tell you which message pointed at which file, which is the association the requesting party is actually asking for.

What the courts have held

The through-line is not that linked files do not matter. It is that courts have consistently refused to impose bulk family reconstruction on producing parties while the tooling cannot deliver it, and have pushed the parties toward a targeted exchange instead. Meta Pixel is the clearest statement of the split: the protocol says no families, and separately the parties handle reasonable specific requests as they arise.

StubHub is the case to read before you sign anything. StubHub stipulated to a protocol defining child files to include hyperlinks to internal documents, then discovered it could not comply and violated the order from its first production onward. The court modified the protocol and denied sanctions, but was blunt about where the damage came from: the harm “was caused by StubHub’s foolish decision to stipulate to the hyperlink requirement in the first place.” A stipulation converts a technical limit into a court order you are already breaching.

The Cerebras template

James v. Cerebras Systems (N.D. Cal., 7 July 2026) is the first stipulated ESI protocol to handle modern attachments and generative-AI review governance in one order, and its hyperlink provisions are the most copyable thing currently on the record:

• Hyperlinked documents are not document-family members for attachment production.
• The requesting party identifies specific produced documents containing relevant links and asks for those files — capped at 100 responsive, non-privileged hyperlinks for targeted collection.
• The producing party has 14 days to produce the version as it existed at collection, or the version as it existed when the hyperlink was sent where that is possible.

That allocation is the point. The requester carries the cost of deciding what matters; the producer carries the cost of retrieving it. Neither side is asked for the default-to-everything collection that made this issue intractable. The same order also sets AI-review validation at a 95% confidence level for null-set sampling with elusion not exceeding 3%, and requires short-message data in at least 24-hour conversation batches — covered in the eDiscovery entry.

What the tools can actually do

The legal answer is settled enough. The operational answer is where teams still get hurt, because both major suites collect modern attachments and both do it with limits that are easy to miss.

Microsoft Purview eDiscovery collects cloud attachments at eDiscovery Premium, which requires Microsoft 365 E5 or the E5 Compliance add-on and is licensed per custodian whose data you collect. It can collect the live version, the version at the time of sharing, or all versions, and it groups the linked file with its parent through a shared GroupID plus an Is modern attachment property.

The catch is that the shared version only exists if you configured it in advance. By default the workflow collects the current live version. Recovering the version that was actually sent requires a retention label set to auto-apply to cloud attachments, which snapshots a copy at share time. If that label was not running before the sharing happened, the sent version was never preserved and no collection setting will bring it back.

Purview’s documented limits, current as of its 11 June 2026 revision:

Custodian attribution also runs backwards: the linked file is attributed to the message custodian, not to the person who owns the file. If User A shares a file from User C’s OneDrive with User B, and you collect from User B’s mailbox, the file lands under User B.

Google Vault exports linked Drive files through an Export linked Drive files option on Gmail exports. It returns the current version only — Vault has no version-at-time-of-send equivalent to Purview’s retention-label snapshot. Public hyperlinks such as published Google Sites pages and submittable Forms links cannot be exported, nor can some legacy Drive link formats, nor links inside encrypted messages. The exported files arrive separated from their parent messages, so the association has to be rebuilt downstream from the exported drive-links mapping before review.

How to negotiate it before collection

Do this in the ESI protocol, before a single custodian is collected:

1. State the family rule explicitly. Write that hyperlinked files are not document-family members, in the Meta Pixel / Cerebras formulation. Silence is worse than either answer, because it leaves the fight for a moment when you have already produced.
2. Set the targeted-request mechanism with a number and a clock. Cerebras gives you 100 hyperlinks and 14 days. Pick figures matched to the matter, but pick figures — “reasonable requests” with no cap reproduces the bulk-collection problem under a different name.
3. Name which version is owed. Collection-date or send-date. Do not promise send-date unless cloud-attachment retention labelling was already running across the in-scope sites when the messages were sent. Check the configuration date, not the policy document.
4. Carve the exclusions you actually have. Copy your platform’s real limits into the protocol — the 50-link ceiling, encrypted messages, quoted portions of forwards, Teams shared channels. “To the extent technically feasible” is a phrase you will have to litigate; an enumerated list is one you can point at.
5. Make the cap reciprocal. The requesting party in a matter with two document-heavy sides becomes the producing party on the counterclaim.
6. Run the feasibility test before you sign. Pull a sample of a few hundred in-scope messages, run them through the platform you will actually use, and count how many links resolve to a file you can produce. That number, not a vendor datasheet, is what you negotiate against.

Common pitfalls

• Stipulating to hyperlink-as-attachment without testing it. This is the StubHub failure exactly, and the court’s sympathy did not extend to the stipulation itself. Guard: treat any hyperlink provision as a technical commitment requiring a sample collection before signature, on the same footing as agreeing to a production format.
• Assuming the sent version is recoverable. Both Purview and Vault default to the current live version, and Purview’s send-time snapshot only exists where a retention label was applied prospectively. Guard: turn on cloud-attachment retention labelling as a standing hold-readiness control, not as a collection-time step — by collection time the question is already decided.
• Reading a clean collection report as a complete one. The 50-link ceiling, the 2,048-character URL cut-off, and the quoted-portion exclusion all drop links without erroring. Guard: flag messages containing more than 50 links during processing and route them to manual review; reconcile link counts in message bodies against links actually resolved.
• Holding the mailbox but not the file. A hold on a custodian’s mailbox does not freeze a linked file sitting in a different person’s OneDrive, and Purview’s custodian attribution will not tell you whose it really was. Guard: scope the legal hold to file locations as well as custodians, and preserve the site collections the in-scope teams actually share from.
• Producing linked files that were never privilege-screened. A linked file gets pulled in because its parent matched a search term — including, per Purview’s documentation, when the file itself would not have matched and even when it sits outside the compliance boundary. Guard: run the linked-file corpus through privilege review as its own population with its own search terms, before it joins the production set.

Related

• eDiscovery — the surrounding process, EDRM stages, and the rest of the Cerebras protocol
• Legal hold process — where cloud-attachment preservation has to be decided
• Privilege review — the screen that linked files bypass by default
• Microsoft Purview eDiscovery — the collection side for Microsoft 365 tenants
• Relativity — where the reconstructed families land for review