How it works.
The architecture from shutter to verifiable record. Industry-standard open formats throughout. Designed so the proof outlives any single operator.
The capture-to-verification pipeline.
Each stage produces a signed artifact; subsequent stages build on it without being able to alter the prior signatures. Two preflight stages run continuously, separate from the per-capture flow.
preflight
OS integrity. The bedrock.
The app installs and runs only on non-jailbroken (iOS) and non-rooted (Android) devices. The operating system itself must still enforce its sandbox, its code-signing rules, and its secure-enclave protections, or no software running on top of it — including ours — can make a meaningful integrity claim.
This is the bedrock layer. Every subsequent stage depends on the device’s OS not being compromised. If the OS has been jailbroken or rooted, the app refuses to launch in a signing capacity.
preflight
The app verifies itself before it verifies anything else.
At runtime, the app re-checks itself against the original App Store / Play Store build to confirm the binary has not been tampered with or sideloaded. A modified app refuses to sign captures.
If the signing environment can’t be trusted, nothing downstream of it can be either. Stages 00 and 01 run continuously and are the precondition for Stages 02–06.
Capture-time signing on the device.
When the shutter fires, the app composes a C2PA-conformant manifest containing the pixels, the device’s clock-and-sensor state, the lens parameters, and a device attestation token. This bundle is signed inside the app’s secure runtime before the photo is written to the device library.
Because signing happens at the moment of capture, AI-generated imagery, screen-recapture, or after-the-fact edits cannot reproduce the signature. The signature is bound to the exact frame the sensor saw.
Device attestation.
The signing key is bound to a device attestation chain rooted in the operating system. On iOS, this is Apple App Attest. On Android, this is Play Integrity. On hardware-supported devices, the chain extends into silicon — for example, Qualcomm Snapdragon C2PA on supported Android flagships.
The verification page reports the attestation tier of each capture: software-rooted (App Attest / Play Integrity) or hardware-rooted (silicon-anchored). This lets evaluators set policy on which tiers they accept.
Invisible watermark.
An invisible watermark is imprinted into the pixel data at capture. It is imperceptible to viewers but recoverable algorithmically. The watermark binds the file to its original capture even when the C2PA manifest has been stripped, the file has been recompressed, the image has been cropped, or the photo has been recaptured by screenshot.
This is the difference between “the metadata says it’s authentic” and “the pixels themselves carry the proof.” Stripping the manifest does not defeat verification.
Witness-anchored timestamp.
The hash of the signed capture is published to an independent witness network. The network co-signs the timestamp, producing a tamper-evident record of when this hash first existed. Forging a capture date later requires forging the entire witness consensus — not editing a single field.
The timestamp record is distributed across many independent witnesses, not held by a single authority. The architecture is designed to outlive any one operator, including us.
Public verification page.
Every certified photo gets a public verification page at cert.photos/v/<id>. The page resolves the C2PA manifest, validates the signing certificate against the trust list, recovers the invisible watermark, and confirms the witness-anchored timestamp. No account is required to view it.
The page is the canonical proof surface. Newsroom CMSes, marketplace listings, social shares, and reader-side verifiers all point at the same URL.
The verification page.
Every certified photo has a unique public page with varying levels of disclosure. Anyone, anywhere, can load it — no account, no app, no fee. The page is the canonical place to verify; CMS badges, social shares, and all link back to it.
The signing identity.
Verified contributor identity (newsroom staff, freelancer, public account) or a pseudonymous handle if the contributor needs source protection. The cryptographic binding is identical; only the human-readable surface differs.
Witness-anchored capture time.
Precise to the millisecond and anchored against the independent witness network. Forged dates fail verification.
GPS if not redacted.
GPS coordinates if the contributor (or the publishing organization) has not redacted them. Redaction is per-photo or per-organization policy; the proof of authenticity does not depend on the GPS being present.
Device and attestation tier.
Which device captured the photo, which attestation tier signed (software or hardware-rooted), which C2PA assertions were included. Enough technical detail for evaluators to set policy.
Permanent proof. Deletable PII.
The cryptographic record of capture lives forever. The personally identifying data — photographer ID, GPS coordinates, EXIF — lives in deletable storage. Right-to-erasure works. Source protection in war zones works. These two facts are reconciled by a single architectural principle: the proof of authenticity does not depend on the data that has to be deletable.
What stays forever.
The cryptographic hash of the capture. The signing certificate. The witness-anchored timestamp. These produce the proof of authenticity.
What you can erase.
Photographer ID. GPS coordinates. EXIF detail. Device serial. Anything that could identify a person or a precise location. All of this is kept separately and can be erased.
The proof does not depend on the PII.
A verifier can confirm the photo is authentic, was captured at this time, and was signed by this account — without ever needing to read the personally identifying data. When the PII is erased, the proof of authenticity remains intact.
Per-photo or per-organization policy.
Newsrooms can publish with PII redacted for source protection. The verification page resolves to a pseudonymous handle instead of a named identity. The cryptographic binding is identical; only the human-readable surface differs.
Where we are today.
Want to go deeper?
Technical evaluation, integration scoping, partnership conversations — we’re a small team and we respond. Email us and tell us what you’re working on.