C2PA Solves Provenance. It Doesn't Solve Chain of Custody.

The Samsung Galaxy S25 signs photos at the moment of capture. Google Pixel 10 does the same. The credential is baked into the file before you lower the camera.

C2PA, backed by Adobe, Google, Microsoft, Meta, and OpenAI, is the emerging standard for content provenance. The EU AI Act mandates machine-readable content marking by August 2, 2026. C2PA is how most organizations are planning to comply.

For media authenticity, it's genuinely useful. A claims photo taken on a C2PA-capable device carries a signed record of when it was captured, what device took it, whether edits were applied. Real provenance.

But I've been thinking about where this breaks in a legal or insurance context. And it breaks in a place that's easy to miss.

The credential lives in the file.

When you upload a C2PA-signed photo to a claims portal, that portal may or may not preserve the credential. When a law firm converts a TIFF to PDF for discovery, the C2PA metadata may not survive the conversion. When a file passes through six hands over two years of litigation, there's no guarantee the credential baked in at capture is still there when someone needs to verify it.

This isn't theoretical. Platform re-uploads strip C2PA data regularly. Format conversions drop it. Anyone who's tracked a piece of evidence through a multi-year dispute knows how many format changes happen between capture and court.

The C2PA credential proves what happened at the moment of capture. It doesn't guarantee it survives the journey.

Chain of custody is about the journey, not just the origin.

A chain of custody has to hold across time and across hands. With physical evidence, we solve this through documentation that travels with the evidence but also exists independently of it. The tag on a bagged item isn't the only record. There's also the log, the transfer receipts, the storage documentation.

Digital evidence has the same problem. The provenance metadata inside a file is one layer. But it's entirely dependent on the file's integrity.

A blockchain anchor isn't. Hash a file and anchor it to a public ledger, and that record exists on the ledger regardless of what happens to the file afterward. No platform strips it. No conversion touches it. Two years into litigation, it's exactly where it was the day the file was created.

What this looks like in a legal context

FRE 901(b)(9) allows authentication of records produced by a process that generates an accurate result. It requires laying a foundation, typically through expert testimony or certification about how the system works.

FRE 902(13) allows self-authentication of machine-generated records through written certification, without live testimony. But self-authentication depends on the record itself being intact and verifiable.

A C2PA credential embedded in a file that may have been stripped during transit is not a reliable foundation under either rule. A blockchain anchor on an immutable public ledger is a different kind of record entirely. It doesn't ask whether the file made the journey intact. It just exists, independent of the file's condition.

I built ProofLedger around this gap. A blockchain anchor is independent of file integrity. Attorneys and adjusters get a verifiable, court-ready record that doesn't depend on what happened to the file between capture and courtroom.

Two records, two different things.

C2PA gives you capture-level provenance: who took it, when, with what device, what edits were applied.

A blockchain anchor answers a different question: did this file exist at this point in time, and can that fact be independently verified on a ledger nobody controls.

For insurance documentation and litigation, these aren't competing approaches. They document different aspects of the same question.

The August 2026 compliance window

Enterprise compliance teams are evaluating C2PA now. If you handle documentation that ends up in claims or litigation, the chain-of-custody gap in file-bound credentials is worth building around before it becomes a problem.

C2PA without a parallel anchoring strategy means your provenance documentation is only as reliable as your file's integrity across every system it touches. For documentation that needs to hold in a dispute, that's a meaningful constraint.