Content Credentials for audio: what C2PA does, and what it does not

Content Credentials, standardised by C2PA, are the closest thing the media industry has to a common provenance format. The single most useful thing to understand about them is the distinction in the lead, because nearly every misunderstanding downstream is a version of it.

What a manifest actually asserts

A C2PA manifest attached to a file carries assertions — statements about origin, authorship, tools used, and edits made — plus a hash binding them to the file's contents, all signed by a certificate. Verification answers two questions well:

1. Have the bytes changed since signing? The hash binding answers this cleanly. If the audio was re-encoded, trimmed, or re-rendered, the binding breaks.
2. Who signed these assertions? The certificate answers this, subject to the trust question below.

It does not answer whether the assertions are *correct*. If a signer states that a track was recorded in a studio in March, C2PA makes that statement tamper-evident and attributable — it does not investigate it. The credential moves the question from "is this true?" to "who is willing to be on the record saying it, and has anyone edited it since?" That is a genuinely valuable shift, and it is a narrower one than the marketing around provenance usually suggests.

The trust list is the part that gets skipped

A valid signature and a *trusted* signature are different things. Anyone can generate a certificate and sign a manifest; a verifier that checks only the cryptography will report the manifest as intact regardless. What determines whether a credential reads as trustworthy to a third party is whether the signing certificate chains to something on the C2PA trust list, which as of 1 January 2026 replaced the earlier interim list and is governed by the conformance programme.

That list is still filling in. Conformant certificate authorities exist, but membership across the ecosystem is partial, which means a correctly signed credential can still show up in a generic verifier as valid-but-not-recognised. When you evaluate any provenance product, the question to ask is not "is it C2PA?" but "whose certificate signs it, and is that certificate recognised by the verifier my counterparty will use?"

Where audio sits relative to images

The specification handles audio, and credentials can be embedded directly in a WAV. The gap is not the format; it is everything around it. Camera and image-editing support arrived first and drove most tooling, so image credentials have more producers, more consumers, and more places that display them. Audio has fewer of each.

Two consequences matter in practice. First, survivability: audio is routinely transcoded on its way to listeners, and a credential embedded in a WAV does not automatically survive conversion to a lossy stream. Provenance is realistic at delivery and ingest — handing a file to a distributor, a sync client, a platform — and unrealistic as something a listener checks on a streaming service today. Second, display: comparatively few audio surfaces show credentials to anyone, so the value right now is in machine-to-machine handoff rather than public labelling.

What a general credential leaves out for music

C2PA describes where media came from and how it changed. That vocabulary was shaped largely by photography, where the meaningful events are capture and edit. Music has a different shape: a track is assembled over weeks from performances, programming, imports, and revisions, and "where it came from" is not one answer.

This is the gap Chronatum works in, and we build it, so weigh this accordingly: a music-specific assertion carried inside a Content Credential, describing production activity observed in a DAW session and bound to the exact export. It keeps directly observed activity, rule-based inferences, creator declarations, conflicts, and things it could not determine as separate categories rather than merging them into a verdict — because for music the unknowns are large and permanent, and a format that hides them would be describing a different problem. You can see what a credentialed file reports without an account, and platforms can read the same report through the API.

How to think about it

Content Credentials are infrastructure, not a verdict. They make a claim attributable and tamper-evident, which is exactly what you want underneath a dispute and exactly not what you want to describe as proof of anything. Combined with an accurate release declaration and a record you actually kept, a credential turns a disagreement about your credibility into a question about a document — which is a much better argument to be having.