C2PA Interim Trust List frozen: why Content Credentials look untrusted

The C2PA Interim Trust List (ITL) was frozen on 1 January 2026: no new certificates are added or updated, existing ones stay valid for legacy use, and validators are told to move to the official C2PA trust lists. If a validator now flags credentials as untrusted or 'legacy', the signer likely relied on an ITL certificate.

This comes from the Content Authenticity Initiative's trust-lists page (read 2026-10-02), which I fetched; I also read the C2PA Conformance Explorer and IPTC's conformance announcement (read 2026-10-02) for context.

What are the trust lists?

The page names two official lists. The C2PA Trust List holds X.509 trust anchors that issue certificates to conforming generator products, and validators must consult it to check a Content Credential. The C2PA Time-Stamping Authority Trust List holds anchors for timestamp authorities, which allows signatures to validate long after a certificate expires.

The ITL was the stop-gap before the official lists. Its freeze means certificates already issued keep working for legacy content, while new signers must go through the conformance program.

Why would a validator show a warning?

The page says validators may consult both lists during the transition but must distinguish credentials signed with ITL certificates from those of conforming products on the official list. A tool that shows the two differently will mark an ITL-signed file with a lower trust state even though the signature is intact.

A different cause is a missing manifest. If a file was re-encoded by a tool that does not carry Content Credentials, the validator finds nothing, which is not an ITL problem.

What does this mean for files from Sume?

Sume's docs describe what each tool returns and say nothing about a watermark or embedded provenance record on outputs, so treat the output as unmarked until you have checked the delivered file yourself. That is the honest baseline: Sume does not claim to sign output with a Content Credential, so a validator showing nothing on a Sume file is expected, not a fault.

If your downstream needs credentials, sign the delivered file in your own pipeline with a conforming tool, after the last edit. Jobs and results tells you which job produced which artifact so you can log the origin next to the signature.

What should a validator report?

The trust-lists page asks validators to separate credentials by which list vouches for the signer. In practice a good validator shows three things: whether the signature is cryptographically intact, whether the manifest is intact against the file's current bytes, and which trust list the signing certificate chains to.

Those are different questions, and a single red badge can hide which one failed. An ITL-signed manifest on an unmodified file is intact but legacy. A manifest on a file that was later re-encoded fails the hash check, which is a content problem rather than a trust-list problem.

When you triage a warning, work in that order: is there a manifest at all, does it match the bytes, then which list signed it. Most 'untrusted' reports I would expect on files that moved through several editors are the first or second case, not the third, although the page I read does not give statistics.

How do I pick a signer?

Use this as a working list and adjust it to your own pipeline and counsel's advice.

• Look the product up in the Conformance Explorer, which lists conforming products and both trust lists.
• Prefer a signer whose certificate chains to the official list, not the ITL.
• Sign last, since any later re-encode can drop the manifest.
• Test the final file in a validator that reports the trust list used.
• Remember that a valid credential shows who signed, not that the content is true.