Most Digital Evidence Fails Authentication. FRE 901(b)(9) Explains Why.
A Cliffe Dekker Hofmeyr article this week addresses AI, deepfakes, and the burden of proof for digital evidence in litigation. Worth reading for anyone who submits evidence in court or advises clients who do.
The piece surfaced something that's been building quietly: courts can no longer treat a digital file as self-authenticating. AI has made that impossible. And the evidentiary rules that govern authentication were always more demanding than most practitioners applied them.
This matters to anyone in insurance, construction claims, or forensic consulting. Not someday. Now.
What FRE 901(b)(9) Is Actually Asking
Federal Rule of Evidence 901 covers authentication and identification. Most people know 901(b)(1) (someone who knows the item recognizes it) or 901(b)(4) (distinctive characteristics). 901(b)(9) is the one that governs digital evidence.
It authenticates "evidence describing a process or system and showing that it produces an accurate result."
Read that carefully. It doesn't authenticate the file. It authenticates the process that produced the file. The question isn't "does this look real" or "does the metadata say it's from Tuesday." The question is: can you demonstrate that the system generating this output is reliable and hasn't been altered?
EXIF metadata doesn't answer that. EXIF is a field inside a file. Anyone with basic editing software can change it. It describes what the file currently claims about itself. It doesn't describe a process.
That's why evidence relying on EXIF timestamps keeps losing authentication challenges. Not because the evidence isn't genuine, but because the authentication method doesn't satisfy what the rule requires.
What AI Changed About This
A few years ago, "the video looks authentic" carried weight. That's gone now. AI-generated video is convincing enough that courts can no longer assume visual inspection settles the question.
What deepfakes changed isn't the rule. They changed how seriously defense counsel invokes it. Authentication challenges that used to be rare in routine civil litigation are becoming standard practice. If the opposing party knows your video documentation relies on metadata and filename timestamps, they know where to push.
The Daubert standard adds another layer in federal court. Daubert requires that expert methodology be testable, peer-reviewed, and accepted in the relevant field. Expert testimony authenticating digital evidence based on metadata analysis that any competent technician can manipulate is Daubert-vulnerable. The methodology doesn't hold.
Why Blockchain Anchoring Satisfies the Standard
I built ProofLedger specifically for this evidentiary gap.
The mechanism is straightforward. ProofLedger takes the SHA-256 hash of a file and anchors it to both Polygon and Bitcoin. The file stays on the submitting party's machine. Only the hash goes on-chain. The result is a public, immutable record that a specific file existed at a specific block timestamp.
That record exists independent of the file itself. No metadata inside the file. No platform that can strip it during upload. No transfer that corrupts it. The blockchain entry is permanent and independently verifiable by anyone with the hash and a public explorer.
Under 901(b)(9), this describes a process that produces an accurate result. The process is cryptographic hashing plus blockchain immutability. Both are testable, widely understood, and don't require trust in any single party. Verification is public. Opposing counsel can run it themselves.
For video evidence specifically, the anchor and the file are separate. Even if a video gets re-compressed, re-uploaded, or converted to a different format, the original hash can be compared against the proof record. Match means unchanged. Mismatch is documented.
That's a different evidentiary posture than "the EXIF says it was captured at 10:43 AM."
The Timing Problem That Can't Be Fixed After the Fact
None of this helps if the anchoring happens after the loss.
Consider a construction company managing a portfolio of commercial properties. They photograph everything: rooflines, drainage, HVAC units, parking structures. Organized, detailed, high-resolution. Then a storm hits, a claim is filed, and the defense challenges whether the photos were taken before or after the damage. Not whether the photos are genuine. Just when.
If the only timestamp is in the filename or the EXIF field, the challenge has legs. Pre-loss documentation that can't independently verify its timing isn't worth much less than post-loss documentation. Courts have to weigh it accordingly.
The difference in claim value between evidence that can establish pre-loss timing and evidence that can't is substantial. I'd argue it's the most underestimated gap in how claims-related documentation gets managed.
What to Do Before the Next Loss
The Cliffe Dekker Hofmeyr article is a useful signal. Legal professionals are paying closer attention to digital evidence authentication. If courts are tightening scrutiny, the time to fix your process is before a challenge, not after you've lost one.
Three things worth reviewing with your team:
First, what authentication method are you relying on for digital evidence timing? If the answer is file metadata or filename timestamps, that's a gap. It's fixable, but it needs to be acknowledged first.
Second, when does documentation get anchored? Pre-loss anchoring has a fundamentally different evidentiary value than post-loss. The workflow for capturing and anchoring evidence before a claim exists needs to be built into standard procedure, not treated as optional.
Third, can timing be verified by someone who wasn't involved in creating the evidence? That's the practical test courts are increasingly applying. Independent verification that doesn't run through the submitting party's own systems is more durable than metadata that does.
Blockchain-anchored timestamps are one way to build that independence into your process. They're not the only tool in evidence management, but for the timing question specifically, they provide a record that doesn't depend on trusting the file.
(Link in first comment.)
Has your team had evidence challenged on timing specifically, where the integrity of the documentation wasn't the issue but when it was created couldn't be independently verified?