C2PA adoption is picking up speed. LinkedIn, TikTok, and Sony are signing content. Google Pixel 10 ships with Content Credentials built in. Adobe’s Content Authenticity tools are in production. But here’s the thing — signing content and having a verified trust infrastructure are two very different things. In early 2026, they haven’t come together yet.
The Interim Trust List that held C2PA together during its early years was frozen on January 1, 2026. The official C2PA Trust List exists, but the Conformance Programme that populates it only launched in mid-2025 and is still in early enrolment. Then in September 2025, the Nikon Z6 III incident showed everyone what happens when hardware key management fails inside a signing pipeline.
This article looks at the C2PA trust layer honestly — where the governance infrastructure holds, where the gaps are, and what you need to check before committing. For foundational context on how content provenance infrastructure works, see content provenance infrastructure explained. For technical detail on how manifests work, see what C2PA manifests contain and how signing works.
What is the C2PA Trust List and what does it actually govern?
The C2PA Trust List is a publicly maintained list of Certificate Authorities (CAs) whose certificates have been certified under the C2PA Conformance Programme for signing Content Credentials. Here’s what that actually means in practice.
A C2PA manifest is cryptographically signed. Anyone with a valid-looking certificate can produce a structurally correct manifest with a mathematically valid signature. The Trust List is what separates “this was signed by an entity certified against the C2PA specification” from “this was signed by someone with a self-signed certificate they made themselves.”
Without Trust List validation, a validator only confirms a mathematically valid signature. The cryptography checks out. The structure is valid. But there’s no independent accountability — none at all.
The Trust List is published in the conformance-public GitHub repository and browseable via the C2PA Conformance Explorer. You can also use C2PA Verify — the reference verification site — to check whether a specific piece of content has a Trust List-backed signature or an ITL-based one. As of early 2026, confirmed conformant CAs include DigiCert and SSL.com, which joined in September 2025. The list is not yet fully populated. Its completeness depends entirely on how many CAs and product vendors have completed Conformance Programme enrolment.
What was the Interim Trust List and why does its January 2026 freeze matter?
The Interim Trust List (ITL) was a transitional list of CAs used during C2PA’s early adoption phase from 2021 through 2025. It allowed C2PA Verify and other validators to distinguish valid, known certificates from unknown ones before the formal Conformance Programme existed. It was always meant to be temporary.
On January 1, 2026, the ITL was frozen. No new entries. No updates. Done.
Content signed during an ITL certificate’s validity period stays valid against the legacy trust model — those signatures aren’t invalidated. But no new ITL-based certificates will be issued, and existing ITL certificates are now a legacy trust signal, not a conformance signal. The official Trust List aligns with C2PA 2.x. If your implementation went live between 2021 and 2025, you’re running on ITL-era certificates. That’s not a crisis — but your validator needs to distinguish ITL-based credentials from Trust List credentials, and you need a migration path worked out.
Most mainstream C2PA coverage hasn’t touched the ITL freeze. Worth knowing when you’re reading adoption-positive takes.
What is the C2PA Conformance Programme and why is it still incomplete?
The C2PA Conformance Programme is the accountability layer that gives the Trust List any meaning at all. It launched in mid-2025 and certifies three categories of entity: generator products, validator products, and Certificate Authorities.
The idea is sound. The programme checks whether implementations actually behave consistently with the C2PA specification and its security requirements. A conformance programme for certification authorities opened in June 2025 — SSL.com satisfied those requirements and became an authorised issuer of C2PA-conformant signing certificates in September 2025.
But early enrolment is not a populated ecosystem. The Trust List is only as trustworthy as the certification process behind it, and that process hasn’t covered most of the CAs and vendors in the market yet. C2paviewer puts it plainly: the Certificate Trust List “is still maturing; revoked or expired certificates require timely infrastructure updates.” You can see who’s been certified via the C2PA Conformance Explorer, but the list will keep growing as enrolment proceeds.
The governance framework exists. Most of the ecosystem hasn’t been through it yet. See privacy risks embedded in the conformance model for additional gaps that affect identity assertions.
What does the Nikon certificate revocation tell us about trust layer risk?
In September 2025, a photographer known as Horshack discovered a vulnerability in the Nikon Z6 III’s C2PA signing implementation. He demonstrated it by encoding an AI-generated image of a pug flying an airplane into a NEF file, then using the camera’s multiple exposure mode to get that image signed with valid C2PA credentials. The resulting JPEG had a conformant signature from a Trust List-backed camera. The content was fabricated.
Nikon revoked all certificates issued for the Z6 III and suspended the Nikon Authenticity Service. Nikon’s notice to users stated: “the authenticity credentials attached to these images are no longer valid and cannot be used as proof of provenance.”
The incident exposes three things. First, hardware key management failure — the signing key wasn’t adequately isolated from untrusted input, and the multiple exposure mode processed NEF files from a non-C2PA body without validating the source. Second, retroactive invalidation — every piece of content signed with those Nikon certificates, legitimate or otherwise, lost its trust signal the moment Nikon revoked them. Third, the revocation checking gap — the default behaviour of available validation tools, including c2patool, is not to check revocation status. Horshack filed a GitHub issue to change that default. When revocation checking is forced on, images from the compromised Nikon certificates fail validation correctly. Out of the box, they don’t.
Horshack noted that Nikon responded as quickly and comprehensively as they could. The remaining problem sits with the open-source validation tools, not Nikon’s firmware. Resolution depends on the broader C2PA tooling ecosystem catching up — which is not something Nikon can fix on their own.
For how to avoid similar key management failures in a signing pipeline you operate, see key management and signing pipeline security.
Can C2PA credentials be forged — what are the real attack vectors?
Yes. And understanding how is useful for working out what your validator actually needs to do.
The common forgery vector is a self-signed certificate. Security researcher Neal Krawetz demonstrated this: using c2patool, he produced a forged manifest with Leica’s correct German address and valid C2PA signatures. Every validation tool reported the signatures as correct. The only flag came from the Content Credentials reference site, which noted the certificate was from an unknown source — but only because that site checks the Trust List. And Krawetz noted that for anyone wanting to bypass even that flag, a trusted signing certificate costs $289. The barrier is low.
The second vector is hardware signer exploitation — using a legitimate Trust List-backed certificate to sign illegitimate content, as demonstrated in the Nikon Z6 III incident.
There’s also a misconception worth clearing up. C2PA does not detect deepfakes. The World Privacy Forum’s report is explicit: AI detection “does not fall within C2PA’s scope of content provenance.” C2PA records provenance — who signed what, using what tools. It says nothing about whether content was manipulated after signing.
The absence of a C2PA signal is also ambiguous. Content without Content Credentials isn’t necessarily untrustworthy. Content with Content Credentials from a certificate not on the Trust List doesn’t mean anything was verified.
Validators need to check three things: Trust List membership, revocation status via CRL or OCSP, and the full certificate chain. Not just the signature. For the structural basis of these attack vectors, see what C2PA manifests contain and how signing works.
What does the World Privacy Forum’s analysis reveal about conformance gaps?
The World Privacy Forum (WPF) published a technical analysis of C2PA titled “Privacy, Identity and Trust in C2PA,” authored by Kate Kaye and Pam Dixon. It’s one of the few independent technical reviews of the framework that doesn’t come from an organisation with a stake in C2PA adoption.
The WPF’s assessment of the conformance model is measured. The report confirms that the Conformance Programme opened in June 2025 and that it “has not been reviewed for this report” — the programme was too new at the time of analysis to assess independently. That sentence alone tells you something about the gap between the governance framework’s existence and its maturity.
On the absence-of-signal problem, the WPF puts it bluntly: “C2PA metadata is meant to be used as signals for measuring content trustworthiness; indeed, the very absence of C2PA metadata can negatively affect C2PA-based interpretations of trust.” Once content provenance becomes expected infrastructure, the lack of a C2PA manifest becomes a negative signal — an implicit requirement to participate.
The WPF report also covers metadata stripping as a durability problem. Content Credentials that get stripped during platform ingestion or processing never reach the end user. The provenance signal is real at the point of signing and invisible at the point of consumption. The gap between what the standard promises and what actually happens in real-world media pipelines is wider than the adoption-positive narratives suggest.
The report’s framing of goal expansion is also worth reading. It notes that “some who have implemented C2PA or evaluated it from a policy perspective suggest the goals of the framework have morphed over time in an effort to solve an expanding and expansive set of problems.” That’s a useful check against any single source describing C2PA as a solution to problems it wasn’t designed to address.
See privacy risks embedded in the conformance model for detailed coverage of the identity assertion risks the WPF identifies separately.
How do I check whether my implementation’s certificates are on the Trust List?
The C2PA Conformance Explorer is the canonical public tool. Browse and filter the live C2PA Conforming Products List, Trust List, and TSA Trust List. The Trust List JSON itself is in the conformance-public GitHub repository — programmatic access is available if you want to query it in your tooling.
C2PA Verify validates Content Credentials against the Trust List and distinguishes between ITL-based and Trust List-based signatures. Use it as a reference check.
The confirmed conformant CAs as of early 2026 are DigiCert and SSL.com. If your signing certificates were issued by a CA not on the Trust List, the first step is checking whether your CA is in the Conformance Programme enrolment pipeline. If they’re not, you need a migration plan. The migration guidance is published in the conformance-public repository — it covers timeline expectations and backward compatibility for previously signed content.
For your validator configuration, you need to be checking three things: Trust List membership, revocation status via CRL or OCSP, and the full certificate chain. Not just the signature. If your validator isn’t doing all three, the trust chain has gaps.
For the regulatory dimension and why migration timelines matter in that context, see regulatory deadlines creating trust posture urgency. For foundational infrastructure context, see content provenance infrastructure explained.
FAQ
Is C2PA the same as deepfake detection?
No. C2PA records provenance — it documents who signed content and what tools were used to create or edit it. It doesn’t analyse content to detect whether it was AI-generated or manipulated. C2PA tells you where content came from, not whether it is authentic.
What happens to content I signed with ITL-era certificates after the January 2026 freeze?
Content signed with ITL-era certificates remains valid — the signatures are not invalidated by the freeze. Those certificates are now a legacy trust signal. Validators that distinguish ITL-based from Trust List-based signatures will flag ITL certificates as non-conformant going forward.
Can someone create a fake C2PA manifest that passes validation?
Yes, if the validator does not check the Trust List. A self-signed certificate can produce a syntactically valid C2PA manifest with a mathematically correct signature. Trust List validation is what distinguishes credible provenance from self-assertion.
Why does c2patool not check certificate revocation by default?
Revocation checking adds network latency (querying CRL or OCSP endpoints) and potential failure modes if the endpoint is unavailable. The current default prioritises availability over security. Horshack filed a GitHub issue on c2patool to change this behaviour after demonstrating that the Nikon revocation would be invisible to default-configured validators.
What is the difference between the C2PA Trust List and the TSA Trust List?
The C2PA Trust List covers Certificate Authorities that issue signing certificates. The TSA Trust List covers Time Stamping Authorities that provide timestamps for C2PA manifests. Both are governed by the Conformance Programme and published via the Conformance Explorer.
How many Certificate Authorities are on the C2PA Trust List in 2026?
The Trust List is in early population. DigiCert and SSL.com are confirmed conformant CAs as of early 2026. The number will grow as more CAs complete Conformance Programme enrolment.
Does platform adoption of Content Credentials (LinkedIn, TikTok) mean the trust layer is working?
Not necessarily. Platform adoption of signing and display is genuine progress. But most user-generated content remains unsigned and Trust List maturity remains an open challenge. Signing adoption is not the same as end-to-end verified trust.
What should I do if my CA is not yet on the C2PA Trust List?
Check whether your CA is in the Conformance Programme enrolment pipeline. If not, plan migration to a conformant CA — DigiCert or SSL.com as of early 2026. Review the migration guidance in the conformance-public GitHub repository for timeline and backward compatibility.
What did the Nikon certificate revocation incident mean for photographers who used C2PA on the Z6 III?
All content signed with the revoked Nikon certificates lost its trust signal. Photographers had to synchronise their cameras with Nikon Imaging Cloud to remove the invalidated certificates. A single signer’s key management failure retroactively invalidated an entire body of signed work.
Is it worth implementing C2PA now or should I wait until the Trust List is fully populated?
The governance infrastructure is real and the direction is clear. But the trust layer is not yet fully operational. Organisations facing regulatory deadlines (EU AI Act) may need to implement now. Others may choose to monitor Conformance Programme enrolment and implement when Trust List coverage reaches a threshold that matches their risk tolerance.
What is the C2PA Conformance Explorer and how do I access it?
The Conformance Explorer is a public web tool at spec.c2pa.org/conformance-explorer/ that allows browsing and filtering the live C2PA Conforming Products List, Trust List, and TSA Trust List. It shows which CAs, generator products, and validator products have been certified under the Conformance Programme.
