C2PA Content Credentials: implementation guide

C2PA is the open technical standard from the Coalition for Content Provenance and Authenticity, a joint effort whose steering members include Adobe, Microsoft, Google, Intel, Truepic and the BBC. Its user-facing name is Content Credentials. The standard defines a cryptographically signed block of metadata — a manifest — that travels inside a media file and records how that file came to exist.

Regulation is what made it urgent. The EU AI Act's Article 50 requires machine-readable marking of AI-generated content, and C2PA is the only mature, open, independently verifiable way to provide it. This guide covers what you actually have to build.

What a manifest contains

A C2PA manifest is a structured document attached to an asset. The parts that matter for compliance work:

• Claim. The set of statements being made about the asset, plus hashes binding those statements to the actual bytes of the file.
• Assertions. Individual statements. The critical one for AI disclosure is c2pa.actions, whose action entries carry a digitalSourceType value drawn from the IPTC Digital Source Type vocabulary. The values you will handle are trainedAlgorithmicMedia (produced by a generative model), compositeWithTrainedAlgorithmicMedia (human work combined with generated elements), and algorithmicMedia (produced by non-trained algorithmic means).
• Claim generator. The tool that created the manifest — useful evidence, and often the first place a generator identifies itself.
• Signature. A COSE signature over the claim, made with an X.509 certificate. This is what makes the manifest tamper-evident: alter the pixels or the assertions and validation fails.
• Timestamp. An RFC 3161 trusted timestamp, so the signature remains meaningful after the signing certificate expires.

Manifests chain. When an asset is edited by C2PA-aware software, the new manifest references the previous one as an ingredient, producing a provenance history rather than a single snapshot.

Format coverage, honestly

Embedding is well supported for JPEG, PNG, WebP, AVIF, TIFF, MP4/MOV, and common audio containers. Two gaps are worth planning around.

PDF. The C2PA reference implementation does not yet support embedding manifests in PDF. The practical substitute is to write the same IPTC digitalSourceType declaration into the document's XMP metadata packet. It is machine-readable, readable by Adobe tooling, and carries the same semantic claim — it simply is not cryptographically bound the way a C2PA manifest is.

Plain text. There is nowhere to put a manifest. Text loses all metadata the moment it is copied, which is why the EU AI Act handles AI-generated text through a disclosure duty under Article 50(4) rather than a marking duty. The right artefact for text is a disclosure log entry: the SHA-256 hash of the published content, the name of the responsible person, and a timestamp.

Hard binding vs soft binding

Manifests attach to content in two ways, and knowing which you have determines how much you can claim. A hard binding is a cryptographic hash of the asset's actual bytes, recorded in the claim. Change one pixel and validation fails, which is what makes a C2PA manifest tamper-evident rather than merely descriptive. A soft binding is a fingerprint or watermark that can survive re-encoding and lets a stripped file be matched back to a manifest stored elsewhere.

For compliance work, the hard binding is what you are relying on. It is the reason a signed asset is evidence: the statement and the bytes are cryptographically joined, so nobody — including you — can alter the content and keep the declaration. Soft bindings and cloud-hosted manifest recovery are useful recovery mechanisms for content that has passed through a stripping pipeline, but they are a best-effort layer on top, not a substitute.

The certificate question

This is where most implementations stall, and it deserves a direct answer. A C2PA manifest is signed with an X.509 certificate, typically using ES256 (ECDSA over P-256). Three options exist, and they are not equivalent.

Self-signed or demo certificates

Fine for development. Signatures are cryptographically valid and tamper-evidence works, but verifiers will report that the issuer could not be recognised, because the certificate is not on the C2PA known certificate list. That notice says nothing about whether the signature is valid or the file was altered — it is a statement about trust anchoring, not integrity. Do not ship it as your public posture.

A vendor's certificate

Convenient, and wrong for compliance. If your provenance tooling signs with its own certificate, the attesting party recorded in every manifest is the vendor, not you. When a regulator or client asks who declared this asset AI-generated, the answer should be your organisation.

Bring your own certificate (recommended)

Obtain an X.509 certificate from a CA participating in the C2PA ecosystem (DigiCert and Entrust both issue for this purpose), with an extended key usage suitable for content signing. Sign with that. Your organisation appears as the recognised issuer, and the claim is yours. Keys must be encrypted at rest at minimum; HSM- or KMS-backed signing is the mature end state, where the private key never leaves the module.

Where provenance dies: your own pipeline

The single most common implementation failure is not signing. It is signing correctly and then destroying the result three steps later. Metadata is discarded by more things than teams expect:

• Image processing libraries. Most resize and re-encode operations drop all ancillary chunks by default. If your CMS generates responsive variants, every variant is almost certainly unmarked even when the original is fine.
• CDN image optimisation. On-the-fly format conversion and compression strip metadata unless explicitly configured not to.
• Social platforms. Upload pipelines routinely re-encode. Some platforms preserve and surface Content Credentials; many do not.
• Design tool exports. "Export for web" presets are optimised for byte size, which means stripping everything non-visual.

The mitigation has two halves. First, verify at the publish boundary rather than at import, so you are testing the artefact you actually ship. Second, accept that some destinations will strip your metadata no matter what you do, and keep a timestamped audit record showing the asset's provenance state at the moment of delivery. That record is the evidence for the obligation you can control; you cannot control a third-party platform's encoder.

An implementation sequence

1. Scan before you sign. Read the existing library and find out what is already marked. Assets that arrive from Firefly, DALL·E, or other C2PA-aware generators may already carry valid manifests, and re-signing them needlessly discards upstream provenance.
2. Detect the unmarked AI. Beyond C2PA, look for XMP digitalSourceType declarations and generator fingerprints — the parameters text chunk written by Stable Diffusion web UIs, ComfyUI workflow JSON, and vendor signatures in EXIF Software or XMP CreatorTool fields. These identify synthetic assets whose C2PA manifest did not survive.
3. Decide the assertion. Fully generated content gets trainedAlgorithmicMedia; a human photograph with a generative fill gets compositeWithTrainedAlgorithmicMedia. Getting this distinction right matters more than getting it fast — an overbroad declaration is a false statement about your own content.
4. Sign and timestamp. With your own certificate, over an RFC 3161 timestamp authority.
5. Verify independently. Drop the output into verify.contentauthenticity.org. If a tool you do not control agrees with your tool, the implementation is real.
6. Handle the unknowable. Assets with no markers and no manifest are not proven human — they are unknown. Route them to a named human-origin attestation rather than silently treating absence as innocence.

What C2PA does not do

C2PA is a provenance standard, not a detector. It tells you what a file says about itself, cryptographically bound so the statement cannot be edited silently. It cannot tell you anything about a file that carries no manifest. Pixel-domain watermarking systems such as Google's SynthID address a different part of the problem and have no public detector API, so they cannot be part of a third-party scanning workflow today.

This is a feature, not a shortfall. Provenance that is attached and signed is verifiable by anyone; inference about origin from the pixels alone is a probability estimate that no one can audit. Build on the first, and use named human attestations to close the gap the second cannot honestly fill.

Authentrail implements this end to end — batch scanning, marker detection, BYOC signing with RFC 3161 timestamps, and timestamped audit reports. See the Article 50 guide for the regulatory framing, the homepage for a live scan you can run without an account, or pricing.