Short answer: C2PA is an open standard for attaching a signed, tamper-evident record of origin to a media file. For field photos it answers the question "where did this image come from and has it changed?" in a way a viewer can verify independently, rather than taking the sender''s word for it.

What C2PA actually is

The Coalition for Content Provenance and Authenticity publishes a specification for content credentials: a manifest embedded in or bound to a media file, cryptographically signed by the issuer, describing how the asset was created and what has happened to it since. Any tool that supports the standard can validate the signature and display the history. If the pixels change without a new signed entry, validation fails.

What goes in the manifest for an inspection photo

  • That the image was captured in a live session by the capturing application.
  • Capture time, recorded server-side rather than from the device clock.
  • Location at capture, where permitted and available.
  • The identity of the issuing organization, via its signing certificate.
  • Any subsequent actions — annotation, redaction, export — as additional signed entries.

Annotations are recorded as a separate layer so the original frame is never overwritten. That distinction is what lets you show a reviewer both the marked-up version and the untouched source.

Why now

Two forces. First, generative models produce convincing damage imagery cheaply, so "the photo looks real" has stopped being evidence. Second, verification is shifting from detection to provenance — instead of trying to spot a fake, you prove a real one. Detection is an arms race; a signed provenance chain is not.

C2PA vs. the alternatives

ApproachWhat it provesWeakness
EXIF metadataNothing verifiableUser-writable; stripped by most transports
File hash in a databaseThe file has not changed since uploadSays nothing about what happened before upload
WatermarkVisual attributionCroppable; not machine-verifiable
C2PA content credentialsSigned origin plus edit historyNeeds a verifier; bindings can be stripped by naive re-encoding

In practice you use them together: content credentials for the provenance chain, a stored hash for the durable server-side record, and a visible verification seal for humans.

What it means for your workflow

Nothing changes for the field user — they take a photo in the session. Downstream, a reviewer, adjuster, building official, or opposing party can check the credential and see the image is original, when and where it was taken, and who issued it. That converts "our photos" into evidence. See our C2PA page and chain of custody.

How a signed manifest is produced in a live session

Provenance has to be created at the moment of capture; it cannot be bolted on later. In Virtual Inspection Pro the sequence is deliberately boring, which is the point:

  1. The guest joins the session in a browser — no app download — and grants camera and, where used, location permission.
  2. The frame is captured by the application rather than handed over from a gallery, so the origin claim is about a live camera, not an arbitrary file.
  3. The server records its own timestamp, the session and participant identity, the device-reported position and accuracy radius, and a hash of the bytes.
  4. Those assertions are assembled into a manifest and signed with the issuing organization''s certificate.
  5. Every later action — annotation, redaction, resize on export — is written as an additional signed entry rather than a silent overwrite.

The practical consequence is that the burden of proof moves. Instead of an inspector arguing that a photo is genuine, the recipient checks a credential and gets a yes or a no.

What a verifier actually sees

When a reviewer opens a credentialed image, validation returns one of three states, and it is worth designing your process around all three rather than only the happy path.

StateMeaningWhat to do
ValidSignature verifies and the pixel hash matches the manifestAccept; record the issuer in the file
ModifiedSigned history exists but the current bytes differ from the last signed entryRequest the original from the issuing system
No credentialNo manifest is present, usually because the file was re-encoded, screenshotted, or forwarded through a messaging appTreat as an ordinary unverified photo, not as evidence of fraud

That third row is the one teams get wrong. Absence of a credential is not proof of tampering; it is absence of proof of anything. Write your evidence policy so a missing manifest triggers a re-request rather than an accusation.

Where credentials survive and where they get stripped

Manifests can be embedded in the file or bound to it by hash and stored alongside. Embedded manifests travel with the image but are fragile: many transports re-encode. Anything that passes through consumer messaging, most social platforms, and a fair number of email gateways will arrive stripped.

  • Direct download from the platform — credential intact.
  • Report export (PDF/Word) — the embedded manifest usually does not survive rasterization, which is why the verification state is printed into the report as a visible seal and a link back to the hosted original.
  • Messaging apps and chat forwards — assume stripped.
  • Cloud drive sync — usually preserved, because the bytes are copied unchanged.

This is the argument for keeping the durable record server-side. The manifest proves origin to anyone holding the file; the stored hash and audit trail prove it to anyone with access to the system, regardless of what happened to a particular copy in transit.

Adoption: who is asking for this

The specification is published by the Coalition for Content Provenance and Authenticity, whose steering membership includes Adobe, Microsoft, the BBC and other major publishers and camera manufacturers, and it is developed alongside the Content Authenticity Initiative. Camera makers and generative-AI vendors have both begun attaching credentials, which matters for inspection work in a specific way: as AI-generated images become routinely labelled, unlabelled images stop being neutral. The question in a disputed claim shifts from "can you prove this is fake?" to "why does your evidence carry no provenance?"

Building an evidence policy around content credentials

Standards only help if the workflow uses them. A workable policy is short:

  • Photos submitted as evidence must originate in a live session, not an upload. See verified capture.
  • Original frames are retained unmodified; annotations live as a layer.
  • Exports carry the verification state visibly, plus a link to the hosted original.
  • Missing credentials trigger a targeted retake request, not a rejection.
  • Retention and deletion follow the same rules as the underlying media — see GDPR and CCPA.

Where the same team also runs live remote support calls, Virtual Support Pro captures frames through the same pipeline, so a troubleshooting screenshot and a formal inspection photo carry identical provenance. Sessions are pooled across both, which is why pricing is quoted per session rather than per product.

FAQ

Can content credentials be removed?

A file can be re-encoded to strip the manifest — but that produces an image with no credentials, which is itself the signal. The absence is informative.

Do recipients need special software?

Public verification tools and a growing number of platforms read credentials natively, and our reports display the verification state directly.

Does this replace fraud detection?

No. It complements it. See tamper detection.

What is C2PA in simple terms?

It is a way of attaching a signed receipt to an image or video that says who made it, when, with what, and what has been done to it since. Anyone can check the receipt without trusting the sender.

Is C2PA the same as a watermark?

No. A watermark is a visible mark that can be cropped out and proves nothing cryptographically. A content credential is a signed record that a machine can validate.

Does C2PA prove a photo is not AI-generated?

It proves what the manifest asserts. A credential from a camera application asserts camera capture; a credential from a generative tool asserts synthesis. Provenance tells you the origin rather than guessing at it.

Are content credentials admissible in court?

Admissibility depends on the jurisdiction and on your overall chain of custody, not on any single technology. Signed provenance plus server-side hashing and complete access logs is materially stronger than a bare JPEG, but talk to counsel about your specific process.

Keep reading