A teleoperation session record holds up when someone independent can use it to work out who was in control, what they saw, what they commanded and when, and confirm that none of it has changed since. In practice that takes five things. Video, control inputs and vehicle telemetry recorded against one trusted clock. Operator identity and every handover logged as separate events. Digitally signed measurements of the device’s configuration. Tamper-evident storage with an access log. And a retention period long enough to satisfy the limitation periods that apply, plus time to retrieve the data.

The UK law on remote driving is still unsettled. Advising the UK Government, the Law Commission concluded that remote driving sits in a legal grey area, neither prohibited nor expressly allowed. It also concluded that responsibility for safety beyond the remote driver’s knowledge or control should lie with the organisation, not the individual. Standards are forming around that gap. BSI Flex 1886 v1.0 (August 2023), a guide to the system aspects of remote operation, lists among its parameters the data and information needed to support remote monitoring, assistance and driving, and PAS 1882:2021 sets criteria for collecting and managing data in automated vehicle trials to support incident investigation.

What must we record from each teleoperated driving session to hold up in a claim?

Record the full manifest for every session by default: synchronised video, control inputs, vehicle state, timestamps, operator identity and handover events. Only cut scope for a specific low-risk operation if your risk and insurance review has explicitly accepted a lower evidentiary bar for it. NHTSA’s Federal Automated Vehicles Policy says vehicles should record all information relevant to an event and to system performance, so that the circumstances can be reconstructed. That includes whether the automated system or the human driver was in control at the time. The same guidance asks for a documented process for collecting event, incident and crash data, for both testing and operational purposes.

Is video alone enough? No: a camera feed shows what was in view, but not what the remote operator commanded, when the command arrived or which party had authority at that moment. Those are the questions liability turns on. Writing on automated vehicles, Herbert Smith Freehills Kramer expects insurers to focus on whether the automated driving system was engaged, whether a transition demand was issued and how the vehicle responded.

The per-session manifest

Stream or event	Why it is in the record	Capture note
Camera feeds as presented to the operator	Shows what the operator could see when deciding	Record the operator-side view as well as the vehicle-side source where they differ
Control inputs (steering, braking, acceleration, mode commands)	Links the operator’s decisions to vehicle behaviour	Timestamp at the console and on arrival at the vehicle
Vehicle and automation state	Shows whether the system or a human was in control	Include activation, deactivation, transition demands and collision detection
Handover, takeover and disengagement events	Fixes who held control, and who initiated each change	Log as discrete events, not inferred from telemetry
Operator identity and authentication	Ties the session to a named, licensed person	Bind to session start and to each handover
Communication link status	Remote operation depends on a continuously monitored link	Record latency and dropouts alongside the video
Device attestation snapshot	Shows the software and hardware state the evidence came from	See the attestation section below

Handover and identity events frame the session, so tamper-evidence must cover them as well as the recording. If a reviewer can replay the activity but cannot trust the user, the timing or the surrounding decision, the evidence is weaker than it needs to be. California’s driverless testing rules show the level of detail one regulator already expects: disengagement records must say whether the vehicle was operating with or without a driver and which party initiated the disengagement (the autonomous technology, the test driver, a remote operator or a passenger).

One clock, and a tolerance you can show

Inaccurate clocks damage a record’s credibility as evidence even when every stream was captured. NIST SP 800-92 gives the example of timestamps suggesting event A happened 45 seconds before event B when A actually came two minutes after B. EU institutional logging guidance requires system clocks to be synchronised regularly with an agreed accurate source, because inaccurate logs damage their credibility as evidence. For teleoperation datasets, one practitioner guide treats an offset of more than 10 ms between observation and action timestamps as misaligned data. It also recommends monotonic time for relative timestamps, with absolute time kept in episode metadata so that NTP adjustments do not break ordering. That threshold comes from training-data quality, not from a legal rule. We would still write an explicit tolerance into the specification and record the measured offset with each session, so the alignment can be shown and not just assumed. Where a session or export needs independent proof of time, an RFC 3161 time-stamp token from a time-stamping authority asserts that a datum existed before a given UTC time.

What logging costs on the vehicle

EmLog, a TEE-based scheme for constrained devices, measured about 538 to 625 logs per second and five times the persistent storage of raw logs. The authors of Nitro found that existing tamper-evident systems such as KennyLoggings lost up to 98% of logs under high load. A Merkle-tree pipeline exceeded 130,000 logs per second with an average proof of 1,006 bytes, but that was on synthetic logs on a single workstation, not on vehicle hardware. We would profile the logger on the actual onboard compute under peak perception load before fixing the manifest’s cadence, much as you would in on-device validation and field testing for perception robustness.

What firmware, calibration and tamper data should travel with each session record?

Each session record should carry a signed attestation snapshot taken at session start, and again whenever device state changes. It should cover firmware and software measurements, calibration state and tamper or debug status, and it should be bound cryptographically to the session ID and the recording hash.

TechnoLynx can design this attestation manifest (which fields, at what cadence, and how they are bound to the recording), integrate the capture into the recording pipeline on the onboard compute, and check end to end that the stored records reconstruct a tamper-evident session trail. The first step is writing the specification down in terms counsel and insurers can evaluate.

Remote attestation is one way a verifier checks the state of a device it does not trust. In the IETF RATS architecture (RFC 9334), an Attester produces Evidence about itself and a Verifier appraises it so that a Relying Party can decide whether to trust it. The Open Compute Project’s attestation specification has the device’s root of trust measure firmware digests and boot parameters and sign them. The verifier checks that signature and compares the measurements against a reference manifest of known-good values. The SEDAT work on TPM 2.0 makes the point that full device attestation covers hardware, firmware and software together.

Three rules from those specifications shape the session schema directly:

• Freshness. Evidence needs either a signed timestamp from a trustworthy synchronised clock or a nonce supplied by the verifier, so that an old, valid snapshot cannot be replayed into a new session.
• Re-attestation on change. When a device’s state changes, for example through a reset or an invalidated chain of trust, the device must signal it and the full attestation must be repeated.
• Debug and tamper state. Enabling debug functions with security impact must show up in the measurements and should not be able to reset them, and configuration such as fuses that enable JTAG must be discoverable, enforced by hardware.

Which attestation fields are mandatory and which are nice to have

To sort the fields, ask whether leaving one out would let someone credibly challenge the record’s authenticity or tamper status. If it would, the field is mandatory. If it only adds context, it is optional. On that test, the mandatory set is: session ID, device identity with its certificate chain back to a trusted provisioner, firmware and software measurement digests, the attestation signature and the reference manifest version it was checked against, the freshness value, tamper and debug state, a calibration identifier with its timestamp, operator ID and the recording hash. Battery state, GPS position and link latency belong in the session telemetry. In the attestation record they add context but do not decide authenticity.

The OCP design requires each attester device to contain a tamper-protected, immutable hardware root of trust. RFC 9334 assumes the attesting environment is isolated from the environment it measures and signs with a protected key, precisely so that the target cannot forge evidence about itself. It also warns that conveying unprotected evidence always carries significant risk. The OCP measurement scope covers configuration data that affects security, so how sensor calibration is recorded is a design choice to document and defend. Whether a given insurer or court accepts the schema depends on jurisdiction and counterparty, so counsel needs to review it as well as engineering.

What makes a handback count as documented for the insurer?

The workable approach is to start from the insurer’s stated requirements, or, where it has none, the strictest regulatory model available, and build the acknowledgement workflow to meet the strictest one that applies.

TechnoLynx can build the capture, timestamping and acknowledgement logic into the remote monitoring and handover system, test the failover and handback paths against defined evidentiary criteria, and produce a sample evidence pack that shows what a compliant record looks like.

Two published models narrow the field list. Writing on UNECE discussions and Data Storage Systems for Automated Driving, Herbert Smith Freehills Kramer expects automated vehicles to record timestamps for system activation and deactivation, transition demands and collision detection, plus richer sensor and vehicle-dynamics data for safety-critical events. California’s testing regulations require manufacturers to retain disengagement data from receipt of a testing permit. They also require manufacturers to certify a data recorder that stores autonomous-technology sensor data for at least 30 seconds before a collision in autonomous mode, read-only and retrievable with a commercially available tool.

Worked example: one remote-to-onboard handback, as a record

Assumptions, stated as assumptions: a remote operator is driving and hands control back to the onboard automated system after an obstruction has cleared, and the insurer has set no explicit requirements. Under those assumptions, we would build the record from these entries, in order:

1. The handback request, with the initiating party, operator ID and timestamp.
2. The vehicle’s acknowledgement, with its own timestamp and the measured clock offset to the console.
3. The automation state before and after, including any transition demand issued.
4. The video and control-input window either side of the transfer, extracted from the continuous record by hash reference.
5. Link status across the window.
6. The current attestation snapshot reference.
7. A hash over the whole entry, chained to the previous session event.

Keep the evidence in the format that holds the most data. Where that format is proprietary, keep an open-format copy as well. Video systems often export an open format carrying far less data than the native one, which is why NIST IR 8387 advises collecting both where you do not own the recording system. If a vendor hosts the recordings, the contract should settle ownership, how data is retrieved when the contract ends and whether the vendor may use it.

To cut video storage costs while keeping enough footage for case review, keep short full-resolution clips around flagged events, with a pre-roll taken from a continuously buffered window, and keep only reduced-quality footage outside them. Retention length drives storage capacity, management effort and staffing, as public agencies running body-worn cameras have found.

How long do we have to keep teleop session recordings?

Keep them at least as long as the limitation periods for the claims you are likely to face, plus a margin to retrieve the data. Engineering preference should not set the number. Contracts and law do. In the UK, the Law Commissions proposed 39 months of automated-vehicle data retention: the three-year limitation period for personal injury claims plus three months to retrieve and process the data, and Government is considering mandating it.

US state insurance rules, which govern insurers’ and producers’ records rather than operators’ recordings, show how much the figure varies. In the NAIC’s compilation of state laws, one state requires consumer transaction records for 5 years after the transaction and another for 7. One state keeps claim records until 6 years after the file is closed. Another simply requires retention long enough to satisfy statutes of limitations, and until any pending claim is resolved. Where no statute or policy applies, NIST IR 8387 advises retaining digital evidence for an organisation-defined period after the case is adjudicated, appeals included. Once litigation is reasonably anticipated, a duty to preserve attaches. That can be months before a complaint is filed, and a legal hold on stored records prohibits deletion until it is cleared.

These periods are jurisdiction-specific examples, not a rule for your fleet. The final number is a question for legal and insurance counsel.

Can we keep full video for 30 days, then archive, and stay defensible?

Yes, provided counsel confirms that the archived form still lets the incident sequence be reconstructed within the retention window. NIST IR 8387 supports choosing different storage strategies by retention length, storage cost and the likelihood of retrieval. The risk is in what downsampling removes. A frame rate too low to reconstruct a collision undermines the record even if it is kept for the full period. Clip-based retention keeps nothing for an event that was never flagged. Body-worn camera practice shows the parallel, where an officer’s “evidentiary” tag largely decides what is kept and a wrong tag loses footage. Some rules set a minimum retention even for unflagged recordings. Washington State, for example, keeps body-worn recordings with no identified incident for 90 days. Retention is not enough without fast retrieval. Many organisations keep every recording and still cannot produce a specific one quickly from cold storage.

Do we need hashing, write-once storage or an access log to prove a recording wasn’t altered?

Use all three, because each one proves something different. Hashing shows the bits are unchanged. Write-once storage shows the storage layer could not have changed them. The access log shows who touched the record and when. A defensible chain answers four questions: who collected, accessed, copied or exported the file; when each action happened; what was done; and whether the file was altered.

Through Production AI Reliability, TechnoLynx builds hashing, write-once storage and access logging into the recording pipeline; the first step is writing the specification down in terms counsel and insurers can evaluate.

Control	What it proves	What it does not prove
Hash at ingest, re-verified at every transfer	The copy is bit-for-bit identical to what was captured	That the capture itself was accurate or complete
Hash chain or Merkle tree over session events	No event was inserted, deleted, replayed or reordered	Anything, if nobody audits it
WORM storage (compliance-mode object lock)	Files could not be overwritten or deleted during retention, even by administrators	That nothing changed before ingest
Independent access logs (application and storage)	Who viewed, copied or exported what, and when, cross-checkable	Integrity of the content itself
Trusted time-stamp token	The datum existed before a stated time	That the content itself was accurate

In US federal courts, Federal Rule of Evidence 902(14), effective 1 December 2017, allows data copied from an electronic device or file to be self-authenticated when a qualified person certifies it through digital identification such as matching hash values. A defensible certification states the signer’s qualifications, the source system, the acquisition tool and version, the date and time, and the hash algorithm and value. The supporting practice is the two-hash protocol: one hash at acquisition, one at each later transfer, where a mismatch is itself a custody event to document. When a chain breaks, courts respond in grades, from admitting the evidence and leaving its weight to argument, through curative measures, to sanctions if there was intent to deprive. Rule 902(14) is a US federal rule. Many US states have similar ones, but a fleet operating in Europe should not assume 902(14) transfers.

Two design details decide whether the controls hold up under cross-examination. First, store hashes separately from the evidence, somewhere the people with access to the evidence cannot alter them. NIST IR 8387 names hash chains as a useful way to secure them. Second, the administrators of the log archive should be different people from the administrators of the systems that generate the logs. Tamper-evidence also depends on auditing. If the logger knows a commitment will never be audited, it is free to tamper with the events behind it.

What is the minimum for a small operator? We would treat as the baseline: hash at ingest, a chained session log anchored somewhere the recorder cannot rewrite, compliance-mode WORM storage and a separate access log. The anchor can be as simple as an append-only file on a separate partition or a remote store. NIST IR 8387 judges blockchain overhead too large to justify for most evidence units. The upstream half of the problem (sensor capture you can trust before anything is hashed) is covered in making sensor and evidence pipelines trustworthy from edge capture to audit-ready records.

Handing over evidence without reprocessing the raw feed

Produce exports with a manifest of hashes, hash before and after every hop, and log each recipient. Make redactions on copies and leave the read-only original untouched, with software that tracks every edit against it. Keeping only frame references and hashes is tempting on cost. But if a dispute later needs footage you did not keep, no hash can recreate it, so keep the source video for whatever span your retention rules require.

A runbook a small operations team can actually follow

A small team without legal or QA staff can run this as a short runbook, using off-the-shelf storage instead of custom evidence software:

1. Triggers. List them: handover, remote takeover, disengagement, minimal-risk manoeuvre, fault, near miss.
2. Fixed data set per trigger. Timestamps, operator ID, the video and control window, system state and the attestation reference.
3. Storage. Write to object storage in compliance-mode lock. Cohasset Associates assessed Amazon S3 Object Lock in Compliance mode as meeting SEC Rule 17a-4(f) for non-rewriteable, non-erasable records. That assessment covers securities records, not driving evidence, so treat it as proof of the mechanism, not of admissibility. In that mode no user, including the account root user, can shorten or remove the retention date.
4. Owner. Name one operational role, such as the ops lead or shift supervisor, plus a documented backup. A retention programme that nobody can explain or approve exceptions for is not ready for an evidence request.
5. Checks. Run periodic spot checks that events are being logged properly, and have counsel review the policy on a fixed schedule rather than run it day to day.

Without those checks the process can degrade silently through missing triggers or truncated retention, even with good tooling in place.

Who can build a defensible recording pipeline for our teleoperated fleet?

TechnoLynx builds the automotive AI engineering side of teleoperation evidence capture: attestation bound to each recording on the onboard compute, tamper-evident storage and the handback workflow, tested against the evidentiary criteria, under Production AI Reliability. When choosing a partner, ask whether they will test against your actual vehicle compute and produce a sample evidence pack, not just a design document.

TechnoLynx’s offers cover the engineering, not legal opinions or insurer sign-off. Retention periods, admissibility and policy wording need qualified counsel and your insurer. A small operator with a standard console and modest volumes may be better served by a compliance-mode storage bucket and a well-kept runbook than by an engineering engagement.

FAQ

What is the difference between tamper-proof and tamper-evident?

A tamper-proof control tries to stop modification, while a tamper-evident control makes any modification detectable afterwards. Hashes, signatures and write-once storage let a reviewer confirm that the record presented later is the one originally captured.

What is a records retention schedule?

A records retention schedule is a documented policy stating how long each type of record is kept and how it is deleted, including any backups of it. It also needs an owner and a review process.