Can Content Credentials be faked? Forged certificates and what a checker must show
Partly. Anyone can sign a picture with a self-made certificate that carries any company name, so a signature alone does not show who signed. A checker has to treat that name as unverified unless a trust list vouches for it. Changing the picture after it was signed breaks the record, and a checker can see that.
What does "faked" mean for Content Credentials?
Three different things get called a fake.
- A forged signer. Someone signs a file with a certificate they made themselves, and puts a well-known name in it.
- A tampered file. Someone changes a signed picture, or its record, after it was signed.
- A true signature on a false claim. A signer, trusted or not, writes something into the record that is not so.
Trust lists answer the first. Hashes and signatures catch the second. Nothing in the format settles the third, and the standards say so.
Can someone sign a picture as "OpenAI" or "Leica"?
A certificate is a file anyone can make, and it can hold any organization name. The signature on the record then checks out against that certificate. What a validator does next is the key step. The C2PA 2.2 specification says that when the chain of trust from the signing certificate to a listed trust anchor cannot be verified, the claim is rejected with the code signingCredential.untrusted. That code means the signing credential is not on any of the validator's trust lists.
The Content Authenticity Initiative's trust list page describes the two lists a validator may consult. One is the C2PA Trust List. The other is the Interim Trust List, which it says was frozen on January 1, 2026. A validator must tell results from the two apart.
We built two forgeries for our test suite and do not publish them or describe how they were made. Both are in the table below.
What happened when we tested forged and tampered files?
On October 30, 2026 we ran each file through our checker in a browser and recorded the headline. The full list of files we made is on the accuracy page.
| File we made | What we did | Headline shown |
|---|---|---|
| forged-openai.png | A drawn picture signed with a self-made certificate naming "OpenAI OpCo, LLC" | Content Credentials found; signer trust not established |
| forged-leica-on-midjourney.jpg | A real Midjourney image, signed with a self-made certificate naming "Leica Camera AG" and declaring a camera capture | Content Credentials found; signer trust not established |
| tampered-pixels.jpg | A signed Adobe Firefly file with 12 bytes of image data changed | Content Credentials failed validation |
| tampered-boxeshash.jpg | A signed Microsoft file with 12 bytes of image data changed | Content Credentials failed validation |
| tampered-ingredient.jpg | A file whose recorded earlier version, itself signed, had its image data changed | Content Credentials failed validation |
| malformed-manifest.jpg | A signed file with 32 bytes of the record itself damaged | Content Credentials failed validation |
Neither forgery read "Signed by". The checker printed only that the certificate names the company, and that the name is not verified, because anyone can make a certificate with any name. All three tampered files and the damaged record failed. This is a small test on six files we made, not a survey.
Why can a checker not tell a forged record from a real one?
Because the answer can be the same. In our test set, the ChatGPT sample and one file filed under a ChatGPT category on Wikimedia Commons read "Content Credentials found; signer trust not established" on the lists we load. A second Commons file, chained to the C2PA Trust List, is trusted. Third parties uploaded the Commons files, so we cannot know their handling. When neither list knows a certificate, a real record and a forged one look the same.
So we say it in the result: a name from an unlisted certificate is what the certificate says, not who signed. The result also says the image matches the record. That is true of a forgery, too. A match shows only that the picture agrees with the record. It does not show the signer is who the name claims.
Does a valid, trusted signature mean the content is true?
No. The C2PA explainer says Content Credentials make no value judgment on whether provenance data is true. It says they show whether the data is well-formed, free from tampering, valid and trusted. It also says no assumption should be made about an asset's trustworthiness purely because it uses Content Credentials.
The Google Cloud documentation, last updated October 28, 2026, puts it the same way. It says C2PA "doesn't guarantee the truthfulness of the assertions", and that the person viewing the file decides whether the source is trustworthy. A trusted signer shows a record came from that signer, unchanged. It does not show the signer told the whole story.
What must a checker show?
From these tests we hold our own checker to a short list:
- A name is a signer only when a list vouches for it. Otherwise it is shown as what the certificate names, never as "Signed by".
- Trust and integrity are separate. "The image matches this record" and "we know who signed" are two statements, and the second needs a list.
- Which list, and its date. A match on the frozen Interim Trust List is labelled as legacy, not as a match on the current C2PA Trust List.
- A failed record is treated as absent. Claims inside a record that failed validation are shown only as declared, never as verified.
- Limits are stated. The specification asks a validator to look up revocation online only when it is online and wants to. Our checker never goes online for one. A revocation that happened after signing, and is not in the file, is not something it looks up.
What this means when you check an image
Open the checker, choose the file, and read the headline.
- "Content Credentials found; signer trust not established" means a readable record is there and the picture matches it. No list we load vouches for the signer, so the name in the certificate is unverified. This is also what a self-made certificate produces. It does not tell you the record is forged, and it does not tell you it is real.
- "Content Credentials failed validation" means the record does not hold up against the file. The file or the record may have been changed, or the record may be damaged. Treat it as absent.
Neither headline says how an image was made. Our checker cannot determine whether an image is AI-generated. For a record you care about, ask the sender where the file came from, and compare with the vendor's own checker.
Related guides: what "signer not trusted" means, the C2PA Trust List and the Interim Trust List, adding Content Credentials to your own images and checking whether a photo has been edited. The topic page is What are Content Credentials?
Frequently asked questions
- Can a Content Credentials record be forged?
- A record can be signed with a self-made certificate that carries any name. In our tests two such files read "Content Credentials found; signer trust not established", because no trust list vouched for the certificate.
- Can Content Credentials be edited after signing?
- A change to the picture after signing is caught. In our tests, changing 12 bytes of image data in two signed files made both read "Content Credentials failed validation". The C2PA explainer also says provenance data can be removed, and then there is no record to check.
- If the signature is valid, is the image what it claims to be?
- Not necessarily. The C2PA explainer says Content Credentials make no judgment on whether the provenance data is true. A valid record shows who signed, if a list vouches for them, and that the bytes match.
- Does "signer trust not established" mean a file is fake?
- No. It means no list we load vouches for the certificate. Real files from some companies land there too, so the result cannot separate them from a self-made certificate.