Can Surveillance Video Be Trusted? How Verification and Chain of Custody Work
When surveillance video is used to investigate a theft, support an insurance claim, or explain an incident to police, the image on the screen is only part of the story. The recipient also needs to know where the file came from, whether it changed, who handled it, and whether the copy being reviewed is the same evidence that was originally preserved.
That is why trustworthy video evidence needs more than a timestamp or a watermark. It needs technical integrity checks and an operational chain of custody that travel with the evidence from recording through preservation, sharing, and review.
Four Terms That Describe Different Things
Integrity, provenance, verification, and chain of custody are often treated as interchangeable. They answer different questions:
- Integrity: Are these the same bytes that were signed or preserved, or has the file changed?
- Provenance: What recorder or trusted system produced or received the media, and when?
- Verification: Can another person check the file's hash, signature, certificate, and related proof?
- Chain of custody: What happened to the evidence after it was preserved—who shared it, who accessed it, and whether access later expired or was revoked?
A strong evidence workflow addresses all four. A digital signature without an access history is not a complete chain of custody. An audit log without a content hash cannot show that the downloaded file is unchanged.
Verification Begins With a Content Fingerprint
Video Armed's integrity-enabled AiNVR workflow uses SHA-256 hashing to create a fingerprint of recorded or exported media. The fingerprint is derived from the file's contents. If even one byte changes, the resulting hash changes as well.
A hash is excellent for detecting change, but a hash by itself does not identify who created it. Anyone can calculate SHA-256. That is where digital signatures and certificates enter the process.
The Recorder Signs With Its Own Identity
Each integrity-enabled AiNVR has its own private signing key. The private key stays on that recorder. Video Armed's certificate hierarchy can sign the recorder's public identity, allowing a verifier to check two things:
- The signature matches the media's content fingerprint.
- The signing key belongs to a recorder identity recognized by the Video Armed trust chain.
This distinction matters. A matching hash says that a file has not changed since that hash was recorded. A valid, trusted signature connects that statement to a specific signing identity—in this case, a specific network video recorder whose public signing identity was certified by Video Armed and whose private key remains on that recorder.
Portable Proof Should Travel With the Evidence
Evidence becomes difficult to use when it can only be opened or checked inside the original recorder. Video Armed uses portable formats so verification information can accompany exported media:
- ONVIF Export File Format information can carry signatures, certificates, and Video Armed verification metadata in exported MP4 video.
- C2PA manifests can carry signed provenance and event details in supported JPEG, PNG, and WebP images.
The practical goal is straightforward: the recipient should be able to download a normal, playable file and check its embedded proof without needing access to the originating NVR. Video Armed provides a browser verifier, while standard cryptographic tooling can also be used for offline verification when the appropriate public trust material is available.
Preserve the Original Range Before Sharing
Verification is not useful if the source recording disappears under normal retention before the investigation is complete. The Video Armed evidence workflow can place a hold on selected camera and time ranges at the NVR. That hold protects the selected recording qualities from routine cleanup for a fixed period or until an authorized operator releases it.
Preservation and sharing are separate actions. Releasing a local hold can make the original recording eligible for ordinary retention again; it does not silently erase an existing cloud evidence copy. Keeping those lifecycle decisions separate makes them easier to understand and audit.
A Secure Evidence Room Adds Operational Custody
When evidence must be provided to police, an insurer, a lawyer, or another external recipient, the system can create a private Evidence Room. The recipient receives an expiring public link—not access to the customer portal or the NVR.
An Evidence Room can record:
- The incidents and camera/time ranges associated with the room
- Each item's source, size, SHA-256 fingerprint, and verification result
- When the room was created, extended, placed on legal hold, revoked, or had its link rotated
- Delivery attempts and recipient access activity
- Staff or recorder actions in an append-only custody timeline
Room expiry controls access, while a legal hold controls preservation. A legal hold does not leave a public link open forever; it preserves the underlying evidence and custody history while access can still expire normally. If a link is believed to have been exposed, it can be rotated so the previous link stops resolving.
Not Every File Starts With Capture-Time Proof
Evidence sometimes arrives from a legacy recorder, a third-party system, or an operator upload. It would be misleading to treat that media as if a Video Armed recorder signed it when it was captured.
For eligible unsigned material, Video Armed monitoring can apply a custody seal at receipt. The seal binds the received file's original fingerprint, size, receipt time, and custody metadata to a monitoring certificate. It supports a narrower and honest statement: the file has remained unchanged since Video Armed monitoring received and sealed it.
That is not the same assurance as recorder- or camera-origin proof. The verification result should preserve that distinction rather than displaying every green result as equivalent.
Recipients Can Check the Evidence Themselves
A recipient should not have to take the sender's word for it. On the public Evidence Room page, supported media can be verified in the recipient's browser. The verifier checks the embedded signature and certificate information against the trusted public identity, and the custody report summarizes the result alongside the room's handling history.
A proper verification result can also fail. If the media bytes have changed, the signature does not match, or the certificate chain is not trusted, the system should report that outcome rather than applying a new seal that hides the problem.
What a Blockchain Anchor Actually Proves
The recorder's signature identifies the network video recorder that signed a recording fingerprint. A blockchain anchor adds a separate property: a public, independently timestamped commitment that cannot be rewritten by changing the recorder or Video Armed's monitoring database later.
Signed recording fingerprints can be grouped into a Merkle tree. Only the tree's root is published to the blockchain; the video itself and its customer details are not. A recording's Merkle proof connects its individual SHA-256 fingerprint to that public root.
If the fingerprint, recorder signature, Merkle proof, and public root all verify, they support a precise statement: this exact form of the recording was known to the signing recorder and included in a publicly anchored batch no later than the blockchain transaction time. Change any byte of the recording and its fingerprint no longer follows the same proof path to the anchored root.
Attacks an External Anchor Helps Detect
- Retroactive replacement: someone cannot substitute different footage after an incident and make the new fingerprint appear in the earlier anchored batch.
- Backdating: footage created later cannot be made to look as though its fingerprint was committed before the public transaction, unless the attacker can break the underlying hash or blockchain security.
- Database rewriting: compromising the NVR or monitoring database after anchoring is not enough to rewrite the independent public root.
- Insider alteration: an administrator cannot silently edit the file and update only the private database records; the changed file will no longer match the previously published commitment.
- Competing versions: if two different files are presented as the original, the anchored proof identifies which fingerprint—if either—was committed in that earlier batch.
What the Anchor Does Not Prove
A blockchain does not watch the camera, store the video, or decide whether the scene is truthful. The anchor does not prove that the camera's clock was correct, that no earlier footage was omitted, or that the physical event happened exactly as it appears. If a camera or recorder is compromised before the fingerprint is created, the system could faithfully anchor a fingerprint of misleading media.
It also does not prevent deletion. An anchor can preserve evidence that a particular fingerprint was committed, but the video still needs ordinary protected storage and retention so it remains available. Recorder signatures, certificate trust, preservation holds, access logs, and chain-of-custody records continue to do jobs the blockchain cannot.
That is why blockchain is an additional independent witness, not a replacement for local verification or evidence handling. Local hash, signature, certificate, and embedded-media verification remain useful when external anchoring is disabled or unavailable. Video Armed's public Sui implementation is currently on testnet, so it demonstrates this model but is not a claim that every recording is anchored permanently on a production blockchain.
What Verification Can—and Cannot—Prove
Cryptographic verification can show that a file matches what a trusted system signed or sealed. It can detect post-signing changes and document handling. It cannot prove that the physical scene was truthful.
Verification does not, by itself, rule out:
- A camera pointed at a screen or a deliberately staged scene
- A compromised camera before the recorder receives the stream
- Missing footage that was never recorded or preserved
- An incorrect interpretation of genuine video
It also does not guarantee that a court will admit a particular file. Admissibility depends on the facts, the evidence offered, the applicable law, and the surrounding testimony. What a well-designed system can do is provide concrete technical and operational records that support authentication and system-integrity questions.
A Practical Evidence Checklist
When video may matter beyond routine site review, ask these questions:
- Was the relevant camera and time range preserved before normal retention could remove it?
- Does the exported file carry a content hash and trusted signature or a clearly identified custody-since-receipt seal?
- Can the recipient verify the downloaded file independently?
- Are access, delivery, expiry, link rotation, and revocation recorded?
- Does the custody report distinguish original provenance from later handling?
- Are limitations stated plainly instead of calling the evidence “tamper-proof”?
Video Armed's Video Integrity page explains the customer-facing verification layers, while the technical attestation paper covers the optional external-anchor architecture and its threat model. You can also open the verification portal to inspect supported media.
If your organization needs a repeatable workflow for preserving, verifying, and securely sharing surveillance evidence, contact Video Armed to discuss the recorder, monitoring, and Evidence Room options appropriate for your deployment.