Machine-Generated Records Are Getting a Dedicated Authentication Rule
Courts have been applying FRE 901(b)(9) to machine-generated evidence for decades. It works. But it was written before smartphones, IoT sensors, dashcams, and blockchain-anchored timestamps became standard components of a claims file. The rule is being stretched to cover technology that didn't exist in its original framing, and the legal community has been aware of the tension for years.
A new federal rule, FRE 707, is now under Supreme Court review. The Judicial Conference approved it in June 2025. The public comment period closed in February 2026. If the Court acts on its standard timeline, the rule takes effect in December 2026 or early 2027. For claims departments and litigation teams, that's a short runway to understand what's changing and what it requires.
The Authentication Framework Claims Teams Are Using Today
Three rules govern digital evidence authentication in federal court right now.
FRE 901(b)(9) authenticates evidence produced by a process or system that generates an accurate result. It's the default pathway for most digital artifacts: timestamped files, GPS logs, surveillance footage, automated sensor readings, and any record generated by a system rather than a human. Using it requires laying a foundation, typically through an expert who can explain how the process works, why it's reliable, and what safeguards prevent inaccurate output. That's a live witness, preparation time, deposition exposure, and cross-examination risk.
FRE 902(13) allows self-authentication of machine-generated records through a written certification. The proponent certifies that the record was generated by an electronic process that produces an accurate result. No live testimony required. The opposing party can still object, but the challenge moves to motion practice rather than cross-examination. For litigation teams handling volume, the difference in cost and preparation time is real.
FRE 902(14) does the same for copies of records produced by electronic processes, using the same written certification mechanism.
Both 902(13) and 902(14) were added in 2017. Both are underused. The reason is largely institutional inertia. Practitioners defaulted to 901(b)(9) foundation arguments because that's what they knew. The 2017 additions were an improvement to the framework, but they didn't come with guidance on when to use them, so most teams continued building the same foundation they'd always built.
What FRE 707 Actually Addresses
The existing framework handles authentication but doesn't speak directly to evaluating the reliability of AI outputs, automated systems, complex IoT records, or modern blockchain-anchored files. As these records became more common in claims files and litigation, courts applied 901(b)(9) by analogy, with results that varied across jurisdictions and judges.
FRE 707 would create an explicit authentication standard for machine-generated evidence as its own category. The goal is a consistent framework rather than requiring courts to extend a rule written for a different era to technology the original drafters couldn't have anticipated. Machine-generated records that previously required a stretched 901(b)(9) argument would have a rule written specifically for them.
For blockchain timestamps, the practical effect is a cleaner foundation. The argument that a public ledger constitutes a process that generates an accurate result has always fit within 901(b)(9). But "fit within" and "written for" are different arguments at authentication.
Where Dual-Chain Verification Fits
Under the existing framework, a blockchain timestamp is authenticated the same way any machine-generated record is. Under 901(b)(9), by establishing that the anchoring process reliably produced an accurate result. Under 902(13), through written certification.
The dual-chain structure matters in this argument. ProofLedger anchors a SHA-256 hash to both Polygon and Bitcoin. Two independent public ledgers, neither operated by a single party. A foundation argument for a single-chain timestamp asks the court to trust one system and one operator. A dual-chain argument asks the court to trust two independent systems that produced the same result through separate processes. That's a different conversation, and it lands differently when the opposing party challenges the reliability of the anchoring process.
No file leaves the submitter's machine. Only the hash is anchored. The underlying document and the on-chain record exist independently, which means the chain of custody argument doesn't require producing a database custodian or blockchain operator. The ledger is public. Opposing counsel, auditors, and third-party experts can verify it directly.
What to Do Before December
The rule isn't in effect yet. But the existing framework already supports blockchain authentication through 901(b)(9) and 902(13)/(14). Teams don't need to wait for FRE 707.
What does change when the rule arrives is the argument structure. Practitioners who've built blockchain verification into their evidence workflow ahead of the rule will have a cleaner foundation when they need it. Those who haven't will be building it in response to a rule, not ahead of one.
Anchor before the loss, not after. Risk documentation, not claim documentation.
The question worth asking before December: which digital evidence types in your current workflow are you authenticating under a 901(b)(9) foundation argument, and which already qualify for a 902(13)/(14) written certification? Mapping that gap before FRE 707 takes effect gives you time to build the workflow rather than scramble to defend it.