C2PA and Content Credentials — The May 2026 State of Provenance

C2PA moved from standards conversation to production signal — but unevenly. By May 2026, capture-time signing is meaningfully real on Leica, Sony, Nikon, Canon, and Google Pixel 10. It's narrower on Samsung, underdocumented on Fujifilm, and still absent from native iPhone capture in any public source I could find.

On the generation side, Adobe, Microsoft, Google, OpenAI, and Stability all ship default provenance on flagship lines — but they don't behave the same, don't expose the same fields, and don't yet produce a uniform user experience across the web.

Most importantly: a 2026 UMBC-led security paper showed that some conforming C2PA validators continued accepting revoked credentials more than six months after the certificate was revoked. A single green checkmark is no longer a defensible UX. This post lays out what's actually true today, what we surface on /check/image, and what we're building because of the gaps.

Capture-time signing: who's actually shipping

Leica. The M11-P launched as the world's first camera with Content Credentials at capture. The SL3-S is officially marketed as the first SL-system camera with Content Credentials for photos.

Sony. The most explicit firmware-by-body matrix in public materials. March 2024 firmware added still-image authenticity / C2PA support to Alpha 1, Alpha 7S III, Alpha 7 IV, and Alpha 9 III. June 2025 Camera Verify launch named compatible bodies: Alpha 1 II, Alpha 1, Alpha 9 III, Alpha 7S III, Alpha 7 IV, with stated minimum firmware versions.

Canon. May 2026 Authenticity Imaging System launch is narrower but very clear: initially supports EOS R1 and EOS R5 Mark II, with paid C2PA activation and trusted timestamps, launching first in EMEA.

Nikon. Both a yes and a caution. Nikon Authenticity Service enables compatible Nikon cameras to add secure Content Credentials at capture, with Z6III listed as compatible as of August 27, 2025. But the strongest publicly documented C2PA compromise centers on Nikon: a 2026 independent security analysis states Adam Horshack demonstrated a Nikon Z6 III path for signing forged content; Nikon revoked the camera's certificate in November 2025; and validators still disagreed months later, with some continuing to present the content as valid. Operationally, Nikon counts as "shipping" but its public trust story isn't yet mature enough to treat as low-risk evidence.

Fujifilm. The biggest documentation gap among major camera brands. Officially joined C2PA and CAI in May 2024, said Content Credentials would roll out via firmware starting with GFX100S II. But I couldn't find a current English vendor page enumerating the May 2026 shipping model-and-firmware matrix the way Sony and Canon do.

Phones. Google is the clear leader. Pixel 10 is officially the first native camera app with built-in C2PA Content Credentials for photos captured in Pixel Camera, with and without AI, running on-device using Tensor G5 and Titan M2. Google Photos displays the credentials. Samsung's Galaxy S25 line is described as the first smartphone lineup to support Content Credentials, but Samsung's own wording narrows the feature to content created and edited with generative AI, not every ordinary native-camera photo. iPhone: I did not find an Apple source announcing native iPhone capture-time C2PA signing.

Generation-time signing: who signs by default

OpenAI now says images generated with ChatGPT, Codex, and its API include both C2PA metadata and SynthID watermarks. Its May 2026 provenance update says OpenAI added Content Credentials to DALL·E 3 first, then ImageGen and Sora. Sora-generated videos embed C2PA metadata as well.

Adobe says Content Credentials are automatically applied to content made with Adobe Firefly and its APIs. Firefly marketing describes Content Credentials as attached to all AI-generated content.

Microsoft says all AI-generated Copilot images use Content Credentials. Bing Image Creator images and Bing Video Creator videos use C2PA-based provenance. Azure OpenAI images include Content Credentials automatically. Azure text-to-speech avatar videos do too.

Google Cloud says Content Credentials are automatically signed by Google LLC for supported Gemini image models, Veo video models, and Lyria preview audio models.

Stability AI says API outputs for images, video, and WAV audio are tagged with content provenance and sealed with a cryptographic Stability AI certificate. But openly released models don't get provenance at generation time.

Meta is the notable partial exception. Meta continues to emphasize visible labels, invisible watermarks, and IPTC metadata for "Imagined with AI" images, plus building detection of industry-standard C2PA / IPTC signals from other companies. I did not find a current public statement that Meta AI outputs are themselves C2PA-signed by default. Meta is part of the provenance ecosystem more as a detector / labeler / watermark user.

Manifest fields: more semantic convergence than documentation convergence

The CAI authoring guidance says generative AI outputs should use the c2pa.created action with IPTC DigitalSourceType of trainedAlgorithmicMedia. Mixed assets should use compositeWithTrainedAlgorithmicMedia.

Microsoft exposes unusually concrete field mappings: Azure OpenAI describes description as "AI Generated Image," softwareAgent as "Azure OpenAI DALL-E" or "Azure OpenAI ImageGen," when as the timestamp. Azure avatar video uses generator and when. Google says supported model outputs are signed by Google LLC and list "Google Media Processing Services" as the app or device in the credential.

OpenAI and Adobe clearly expose AI-generated nature and generator identity, but exact field-by-field mappings aren't fully documented in public materials. Any claim that every vendor uses exactly the same assertion structure should be treated as informed inference, not verified fact.

Trust list, revocation, and validator behavior

The CAI's current developer docs say conforming generator products should use signing certificates from CAs on the C2PA trust list — naming DigiCert, SSL.com, Tauth Labs, and Trufo as the complete list as of April 2026 — while noting the Conformance Explorer is the authoritative current source. The C2PA spec separately defines a C2PA TSA Trust List for timestamp authorities, meaning creator signers and timestamp authorities are intentionally not the same trust store.

Revocation is the sharpest hole in the current system. In the current C2PA specification:

• Claim generators are supposed to use OCSP and OCSP stapling
• Explicitly not CRLs
• Validator-side: if no OCSP information is embedded and the validator is online, it may query the OCSP responder
• If it chooses not to: records signingCredential.ocsp.skipped
• If it cannot reach the responder: records signingCredential.ocsp.inaccessible
• If status is unknown: records signingCredential.ocsp.unknown

That means "valid signature" and "revocation fully checked" are not the same state — and many user interfaces flatten them together.

The 2026 UMBC paper is the most important warning for product teams. It reports some conforming validators continued accepting revoked or compromised credentials, specifically highlighting the Nikon Z6 III case and showing contradictory validator outcomes more than six months after revocation. A production verifier has to distinguish certificate-chain trust, revocation state, timestamp state, binding validity, and semantic provenance. A single green checkmark is no longer defensible.

Hard edges: screenshots, re-encoding, durable credentials

The basic hard edge: screenshots, many exports, and many platform uploads strip or invalidate embedded manifests. The CAI manifest docs explain manifests are looked up in asset metadata first, then a sidecar .c2pa file, then a remote manifest reference. Google's docs state plainly that non-C2PA modifications count as tampering and lead to validation failure. OpenAI's help page now explicitly contrasts C2PA metadata with SynthID watermarking — noting the watermark may survive transformations like screenshots while the metadata often doesn't.

Durable Content Credentials are the spec's answer. A Durable Content Credential is one with one or more soft bindings enabling discovery in a manifest repository. The spec defines soft bindings as fingerprints or invisible watermarks, and manifest repositories as stores searchable using those bindings. The NSA-coauthored January 2025 paper Strengthening Multimedia Integrity in the Generative AI Era explains the same design: a durable credential pairs a watermark with a fingerprint and a database reference so provenance can be recovered after metadata loss.

This is the most important medium-term design direction.

Library state: c2pa-rs, c2pa-node, browser packages

The migration story is clearer on the server than in the browser. Adobe's open-source docs say the old c2pa-node library is deprecated and developers should move to c2pa-node-v2 as soon as possible. The same docs still describe the Rust SDK as a beta 0.x.x project, while docs.rs shows a newer c2pa crate line.

I did not verify a stable public c2pa-rs 1.x announcement. For your stack, treat npm [email protected] as acceptable for lightweight client-side reading and visualization, but not as your only authoritative validator.

Our architectural recommendation, with high confidence: move trust-list validation, revocation handling, and normalized status generation to a server-side service using c2pa-node-v2 or a Rust / WASM service. Retain client-side rendering for responsiveness. Dissent: keeping validation in-browser is simpler and more privacy-preserving for sensitive uploads — but it exposes too much trust logic to inconsistent runtimes and weaker update discipline.

What we surface in the UI

For /check/image and /check/video, the fields we surface in one stable order:

1. Provenance state banner. Verified · Present but untrusted · Present but broken · No credentials found
2. Issuer data. Signer organization, root CA, whether the chain reaches the C2PA trust list
3. Time data. Signing time, whether a trusted timestamp exists, whether revocation was checked online, stapled, skipped, or inaccessible
4. Generator data. softwareAgent or generator normalized into a human label: "OpenAI," "Google LLC," "Microsoft," "Adobe Firefly," "Sony Alpha 1 II," "Leica M11-P"
5. Creation method. Camera capture · edit · composite · generative AI, normalized from c2pa.actions plus IPTC DigitalSourceType
6. Chain view. Active manifest, ingredient list, prior capture or edit steps
7. Storage and recovery hints. Embedded manifest · sidecar · remote manifest
8. Validation detail panel. Low-level states like trusted, ocsp.notRevoked, ocsp.skipped, ocsp.inaccessible, timeStamp.trusted, binding mismatch

For video, we add two extras: an explicit note about container-level provenance (users assume a clipped/transcoded MP4 should validate the same as the original), and a "derivative workflow" hint indicating whether the file appears to be an ingredient-preserving derivative vs. a provenance-breaking transcode.

What we ship next

1. An authoritative provenance normalization service. Highest ROI, moderate effort. Store the original upload in R2, run server-side validation, emit one normalized JSON object across images and video: manifest_present, binding_valid, issuer_trusted, revocation_state, timestamp_state, generator_label, creation_method, ingredient_count, user_explanation. Browser package for instant preview; server is source of truth. Immediately closes the biggest gap vs. Adobe Inspect.

2. Result page redesigned around provenance states, not manifest presence. In /check/image and /check/video: state banner → compact provenance card → expandable chain view → technical evidence drawer. Human-readable explanations for "No credentials," "Credentials present but issuer not on trust list," "Credentials broken after editing or re-encoding," "Credentials valid but revocation not checked." The middle layer between raw C2PA JSON and a meaningless green badge.

3. A durable-provenance recovery lane. Preserve original file, compute perceptual fingerprint, cache manifest extracts in D1 or KV, build internal lookup that tries to recover provenance when users upload screenshots, reposts, or platform-stripped derivatives. Extend later with remote-manifest support and durable content credential compatibility.

Open questions

The most important unresolved question isn't whether C2PA will keep growing — it almost certainly will. The real question is whether validator behavior, revocation checking, and timestamp semantics will converge quickly enough for the signal to become evidence-grade in journalism, legal, insurance, and KYC workflows. The 2026 independent security work suggests not yet, even though platform and vendor adoption is accelerating.

Still underdocumented in public materials: Fujifilm's exact live body-and-firmware matrix as of May 2026; precise public field schemas used by OpenAI and Adobe manifests beyond high-level AI-generated and generator semantics; current public C2PA position of Meta's own generators; exact browser-package roadmap beyond npm [email protected]; whether Apple plans native iPhone capture-time signing at all.

Strategic open question for products: how much to invest in provenance vs. classical forensic cues? Provenance should be a first-class lane in the UI — but never the only lane. The ecosystem is moving in this direction, but it's still too easy for credentials to be missing, stripped, broken, inconsistently validated, or semantically oversold. C2PA is highly valuable as explainable evidence, and still insufficient as a standalone verdict.

That's the /check/image and /check/video we're building.