The C2PA Trust List, explained: who is on it, and how validators stay current

A note from ChronoVerify, built and maintained by a veteran intelligence analyst. Published August 22, 2026

The C2PA publishes two lists, and search results mix them up. The Conforming Products List names products that passed the conformance program. The Trust List does different work: it is the roster of signers whose Content Credentials a validator may call Trusted. It also changes without notice, so a validator running last month's copy gives wrong answers about brand-new signers and never notices.

What the Trust List is

C2PA Content Credentials are signed. Anyone with a certificate can sign a manifest, so the signature alone only proves the file has not changed since signing. The question that matters is whether the signer is anyone in particular. The Trust List answers it: a published set of root certificates, called trust anchors, for organizations approved to sign, such as camera makers, AI image generators, and creative software vendors. A validator checks the credential's cryptography, then asks whether the signer's certificate chains up to one of these anchors.

As of August 22, 2026, the signer side held 57 certificates, drawn from two published sources: the Content Authenticity Initiative's interim anchor list and the C2PA's own official trust list. Most of the names on it you already know. Google, Adobe, Microsoft, Sony, Canon, Nikon, Leica, Fujifilm, Samsung, Xiaomi, vivo, and Huawei all have roots there, alongside provenance specialists such as Truepic and a handful of certificate authorities. A separate companion list carried 22 anchors for RFC 3161 timestamp authorities, the services that countersign when a credential was created. Those counts are dated on purpose; the list changes.

Not the Conforming Products List

The Trust List holds certificate anchors and answers who may sign. The Conforming Products List names generator and validator products that passed the C2PA conformance program and answers which products were checked. An organization can be on both, one, or neither. ChronoVerify is a listed validator on the Conforming Products List; ChronoVerify signs nothing, so it has no reason to appear on the Trust List. Neither list involves the word "certified": the C2PA runs a conformance program and publishes trust anchors, and no one is "C2PA certified."

What the three states mean

When a validator checks a credential against the Trust List, the result lands in one of three states:

• Trusted. The cryptography checks out and the signer chains to an anchor on the list. This is the only state with institutional backing behind the signature.
• Valid. The cryptography checks out but the signer is not on the list. The claim is intact and unaltered; it is simply signed by someone the ecosystem has not vouched for.
• Invalid. Validation fails, most commonly because the image bytes no longer match what was signed.

ChronoVerify maps only Trusted to validated provenance. A Valid credential gets reported as what it is, an intact claim from a signer nobody on the list has vouched for, and never gets presented as confirmation.

A stale copy gives wrong answers

The list changes without notice. When a new signer's root is added, every validator running an old copy starts giving a systematically wrong answer: images signed by the new entrant come back Valid instead of Trusted, and the error never announces itself, because Valid is a perfectly ordinary result. It happened this month: a root certificate for Castlabs, a Berlin media technology company, landed in our August 17, 2026 weekly sync. A validator that last refreshed in July is still under-crediting every file that chains to it.

The C2PA conformance program addresses this directly: listed validators are required to refresh the Trust List regularly. The failure direction matters too. A stale list under-credits new signers, which is conservative; the dangerous direction is a removed anchor that a validator keeps trusting. A refresh pipeline has to handle both.

How ChronoVerify keeps its copy current

Our refresh runs every Monday morning. It fetches both published anchor sources and the timestamp-authority list, refuses to write an empty bundle, and validates the refreshed anchors against the full test suite before anything ships. Changes that only add anchors deploy automatically once validation passes, because an added anchor can only upgrade honest verdicts. A removed anchor, or any movement in the allow list, stops the pipeline and waits for a person, because a removal takes Trusted away from images that had it, and we want somebody to have read that diff before it ships.

One detail from running this in practice: in August 2026 our consistency checks caught the bundled timestamp-authority list one certificate behind its recorded snapshot, a gap introduced by the refresh pipeline itself carrying an incomplete file list. The test suite flagged the mismatch, the pipeline was corrected the same day, and the counts on this page come from the corrected bundle.

Check a file against the list

The free verifier validates any image's Content Credentials against the current Trust List and says plainly which state the result is in, signed or not. The same check is one API call. To read our own conformance record, or the full table of listed validator products, see the Conforming Products List page.

Sources: the CAI interim anchor list; the official C2PA Trust List and TSA Trust List (both read August 22, 2026); the C2PA conformance explorer; ChronoVerify's conformance record; the ChronoVerify method page.