The C2PA Trust List and the Interim Trust List: who is on which, and why it changes results
The C2PA Trust List is the current set of certificate authorities behind the signing certificates a Content Credentials checker should recognise. The Interim Trust List is an older set, frozen on January 1, 2026. A signer can be on one list and not the other, so the same file can read differently on each.
What is the C2PA Trust List?
A Content Credentials record is signed with a certificate. A trust list is a published set of certificates that a checker uses to decide whether it recognises that signer. The Content Authenticity Initiative's trust list documentation describes the C2PA Trust List as a list of trust anchors. These are root or subordinate certification authorities that issue certificates to conforming generator products. A companion C2PA TSA Trust List covers time-stamp authorities.
The C2PA specification, version 2.2, says a checker must follow the chain of trust from the signing certificate to an entry in one of the applicable trust anchor lists. If that fails, the claim is rejected with the code signingCredential.untrusted (section 15.7). A checker's list must include the anchors C2PA provides but need not be limited to them, and a checker should let a user add anchors (section 14.4).
Because anchors are certification authorities, a name on the list is not always the company that signs.
What is the Interim Trust List?
The documentation says the Interim Trust List supported early C2PA adoption and has since been superseded by the C2PA lists. It says that since January 1, 2026 the list is frozen: no certificates are added or updated. Existing certificates stay valid for legacy support until they expire.
The same page says a checker may consult both lists, but must distinguish credentials signed under the Interim Trust List from those signed under the C2PA list. Frozen does not mean wrong; it means closed to new entries.
Who is on which list?
We loaded both lists into the checker and read the subject of every certificate with Node's X509Certificate on October 30, 2026. The files were fetched on October 27, 2026. We compared the SHA-256 hash of each upstream file with the current upstream file, and all five matched.
| List and file | Certificates | Organisations named | Last changed |
|---|---|---|---|
| C2PA Trust List, anchors | 32 | 18 | October 17, 2026 |
| C2PA Trust List, time-stamp authorities | 23 | 14 | October 17, 2026 |
| Interim Trust List, anchors | 27 | 20 | January 8, 2026 |
| Interim Trust List, allowed list | 115 | 75 | April 21, 2026 |
| Interim Trust List, configuration file | not a certificate list | not applicable | August 28, 2025 |
Organisation counts are the distinct names in the certificate subjects, compared without regard to capital letters. The Interim Trust List is three files with three dates, so we show all three. The configuration file lists the certificate purposes the list accepts. We also load one settings file we wrote, for the C2PA Trust List: it lists one purpose, c2pa-kp-claimSigning, as version 2.2 asks. The allowed list holds individual signing certificates (none is a certification authority), which is why it names far more organisations than the anchors. Its last change is dated after the freeze; we have not compared versions.
Which names appear on only one list?
| Where | Names |
|---|---|
| C2PA Trust List only | Google LLC (6 certificates), Xiaomi Inc., Huawei Technologies, Encypher, and others |
| Interim Trust List anchors only | Microsoft Corporation (5), Leica Camera AG, SONY Corporation, Canon Inc., NIKON CORPORATION, FUJIFILM Corporation, Samsung, Truepic, Pinterest Inc., and others |
| Both anchor lists | vivo, Trufo, DigiCert, and two names that differ between the lists: Adobe ("Adobe Inc" on the C2PA list, "Adobe Systems Incorporated" on the Interim list) and SSL ("SSL Corporation", "SSL Corp") |
| Interim allowed list only | TikTok Inc., Stability AI Ltd, Black Forest Labs Inc., Cloudflare, and many others |
| Named on no list | OpenAI: no certificate in any of the four files names it. Its newest certificate chains to Trufo |
Why does the same file read differently on the two lists?
A checker asks one question of the signing certificate: does it lead back to an anchor on the list I am using? If the answer differs by list, the result differs. The signature can be sound in both cases; only the recognition of the signer changes.
Our checker applies a fixed policy. A signer on the C2PA Trust List can earn a headline that begins "Trusted Content Credentials". A signer found only on the Interim Trust List earns "Content Credentials found; legacy trust-list match". A signer on neither list earns "Content Credentials found; signer trust not established", because anyone can make a certificate with any name. The C2PA explainer notes that trust can also rest on other lists.
What did we measure?
On October 30, 2026, we ran 32 real files through the checker. Five carried a signed record that chained only to the Interim Trust List: three Adobe Firefly files (one filed as a vendor sample, two on Wikimedia Commons) and two Microsoft Image Creator files from Commons. We do not know how each was handled before it reached us. The validator reported an untrusted signing credential for all five on the C2PA Trust List, and all five as trusted on the Interim Trust List. The list dates are on our accuracy page, and a table by product is on What are Content Credentials?
It is a small test, and we do not know whether newer files from the same products behave differently.
Of the three signed OpenAI files we hold, the newest is trusted on the C2PA Trust List: its certificate was issued under Trufo, which is on both anchor lists. The two older files get "signer trust not established" on both lists, because their certificates have expired. A record we made ourselves, with a certificate naming "OpenAI OpCo, LLC", gets that headline too. So read it as "no list vouches for this name", not as a judgment on the file. See what "signer trust not established" means.
What this means when you check an image
Open the checker and read the headline.
- "Content Credentials found; legacy trust-list match" means the signer is on the frozen Interim Trust List and not on the current C2PA Trust List. The headline does not say the claim in the record is true, and it does not say the signer is untrustworthy.
- "Content Credentials found; signer trust not established" means the certificate names a signer that neither list vouches for. It does not say the record is forged, and it does not say the file is fine.
The C2PA explainer says provenance information alone cannot tell you whether content is true. A file with no record says nothing either way, because most images lose these records when they are shared or re-saved. For the other results, see how to check Content Credentials step by step. The background is on What are Content Credentials?
Frequently asked questions
- Is the Interim Trust List still valid?
- The Content Authenticity Initiative says it was frozen on January 1, 2026 and that existing certificates stay valid for legacy support until they expire. Checkers must tell its results from the C2PA Trust List's.
- Does being on a trust list mean an image is real?
- No. It means the signer's certificate leads back to an anchor on a list the checker loads. The C2PA explainer says provenance information alone cannot show that content is true.
- Why is Microsoft or Adobe not simply "trusted" in your checker?
- In our copy, Microsoft is only on the Interim list. Adobe is on both, but our three Firefly files chain only to the Interim list. We report a legacy match and name the list.
- Can I add a signer to the list?
- Not in our checker, which uses the two lists as published and adds no anchors. The specification says a checker should let users add anchors, but a name you add yourself says nothing to anyone else.