In a recent post, we explored how AI-generated content is making it harder to distinguish authentic media from manipulated content. Now, as organizations move from understanding the problem to implementing solutions, a more practical question is emerging: What does it take to deploy C2PA across production systems and enterprise workflows?

Regulations like the EU AI Act and the California AI Transparency Act don’t mandate C2PA. But they’re increasing pressure on organizations to disclose AI use and preserve verifiable authenticity. That’s driving interest in open, interoperable standards for content provenance.

Integrating the open-source C2PA SDK is an important starting point. But it’s not enough for a production deployment.

Content Credentials are the visible layer of a much larger trust system. Behind each one is a manifest containing provenance information, a cryptographic signature protecting the manifest, and a certificate identifying the application or service that produced the signature.

An SDK can help you create signed content. It doesn’t, by itself, address what it takes to operate a C2PA signing service that remains trusted over time.

Content Credentials are part of a larger trust model

The Coalition for Content Provenance and Authenticity, or C2PA, defines a technical standard for recording and protecting the provenance of digital content.

A protected asset contains a manifest describing aspects of its creation or modification. Depending on the workflow, this information can include:

• The application used to create or edit the content
• Actions performed on the asset
• The party making a provenance claim
• Whether generative AI tools contributed to its creation

This information isn’t simply added as conventional metadata. The manifest is cryptographically signed, allowing a verifier to determine whether the provenance information has changed since the signature was created. Traditional metadata can often be modified or removed with little effort. A C2PA signature provides tamper evidence, helping a viewer confirm that the provenance information is the information the signer intended to publish. Content Credentials present that information in a form people can easily inspect. The underlying signature is what protects its integrity.

5 common misconceptions about C2PA

Understanding what C2PA does—and what it doesn’t do—helps clarify both the value of the standard and the requirements of a production implementation.

Misconception #1: C2PA detects AI-generated content

C2PA isn’t an AI detection system.

It doesn’t analyze an image, video, or document and attempt to determine whether artificial intelligence created it. Instead, C2PA provides a cryptographically verifiable record of how content was created or modified. That record can include a disclosure that AI-assisted tools were used during the creative process.

That’s an important distinction. AI detection technologies analyze content and make probabilistic judgments. Those judgments can become less reliable as generative models improve. C2PA takes a different approach: It allows creators, publishers, and applications to make transparent, verifiable claims about content and its history.

This emphasis on transparency also aligns with emerging regulatory frameworks. For example, the EU Artificial Intelligence Act introduces transparency obligations for certain AI-generated and AI-manipulated content. The legislation doesn’t mandate C2PA, but the standard gives organizations a practical, interoperable way to communicate provenance and disclose AI usage where appropriate. 

Misconception #2: The open-source SDK is all you need

The C2PA specification is openly published, and the project provides open-source SDKs for creating and verifying signed content. Those tools can help you begin an implementation, but deploying a production signing service involves considerably more than integrating a library.

For a production service (and the Content Credentials it produces) to be recognized as trusted within the official C2PA ecosystem, the signing product must pass the C2PA Conformance Program’s technical and security evaluation and complete its legal onboarding. Only approved Generator Products are eligible for a C2PA Claim Signing Certificate issued by a certificate authority on the official C2PA Trust List and for inclusion on the public Conforming Products List.

Conformance is therefore closer to product certification than open-source participation. A product must demonstrate compliance with the C2PA specification and its security requirements, including appropriate key protection and certificate management. Those controls have to extend across every relevant organizational workflow, from design and PR to social, web, agency, and broader marketing operations.

It’s also an ongoing commitment. Implementations must keep pace with changes to the specification and conformance requirements to preserve interoperability and trusted status. That means the production challenge isn’t simply implementing C2PA once—it’s operating a signing service that remains secure, conformant, and trusted over time.

Misconception #3: The Interim Trust List is good enough for production

Many early C2PA implementations used the Content Authenticity Initiative (CAI) Interim Trust List or internally developed signing services to experiment with Content Credentials. These approaches are valuable for evaluation, prototyping, and proof-of-concept projects, but they shouldn't be treated as production-ready deployments.

The Interim Trust List was created to support early adoption and testing. Production deployments, however, are expected to rely on the official C2PA Trust List so Content Credentials can be verified consistently across conformant applications and services.

As validator applications place greater reliance on the official C2PA Trust List, content accepted by evaluation tools today may not be recognized as trusted in future production deployments if it was signed outside that trust framework.

Teams planning a production deployments should therefore consider not only how they generate Content Credentials, but whether those credentials will be trusted throughout the broader C2PA ecosystem. Using the official trust framework supports interoperability today while positioning deployments for wider adoption over time. 

Misconception #4: Any signing certificate will work

Digital signatures are fundamental to C2PA, but not every signing certificate is appropriate for the job.

Many teams are already familiar with document signing and code signing certificates. Those certificates establish trust in documents or software publishers, but they’re designed for different use cases.

C2PA signing certificates follow a different trust model. Rather than identifying the author of a document or the publisher of a software package, they identify the application or service responsible for producing the C2PA signature. This allows verifiers to understand which trusted implementation generated the protected provenance information.

Implementing C2PA therefore requires certificate issuance that aligns with the specification and its conformance requirements. Reusing an existing enterprise signing certificate isn’t enough.

Misconception #5: The signing application is the creator’s identity

Because a C2PA signing certificate identifies the application or service performing the signature, it’s easy to assume that the application is the only identity the credential can represent.

The Creator Assertions Working Group (aka CAWG) has developed an identity assertion framework that allows an organization to cryptographically assert its own creative identity alongside the signing application. That means a publisher, media organization, brand, or agency can be identified as the creator of content even when a third-party application or managed service performs the signing.

Separating application identity from organizational identity gives enterprises more flexibility in how they construct creative workflows. It also allows creators to retain recognition when they change or outsource the tools used to sign their content.

What production C2PA signing requires

Once you move beyond a proof of concept, you need to account for the infrastructure surrounding the signature.

A production implementation may need to manage:

• C2PA-specific certificate issuance and renewal
• Protection of private signing keys
• Access controls and authentication
• Conformance testing and legal onboarding
• Changes to the C2PA specification
• Supported media formats 
• Monitoring, availability, and operational maintenance
• Integration with existing applications and content pipelines

You can build and operate these capabilities internally. That approach gives your team direct control over the signing environment, but it also makes you responsible for its security, maintenance, and continued conformance.

A managed signing platform offers another option. It can handle certificate lifecycle management, secure key protection, and ongoing conformance while exposing the signing capability through an API.

The right approach depends on your security model, available expertise, integration requirements, and appetite for operating trust infrastructure.

Integrating C2PA signing with DigiCert Content Trust Manager

DigiCert Content Trust Manager allows developers to integrate C2PA signing into existing applications and content workflows through an API. The platform manages certificate management, key protection, and conformance behind the scenes.

Teams that want to experiment before building an integration can also use a web interface to upload content and apply Content Credentials. For automated production workflows, the API allows signing to become part of an existing application or content pipeline.

A typical integration follows four steps:

1. Obtain an API key (or Client Authentication Certificate) and your Account ID from your DigiCert ONE account.
2. Select the file you want to sign. Content Trust Manager supports a range of image, video, audio, and document formats. 
3. Send the file to the Content Trust Manager API with the creative role you want to assert, such as publisher, creator, or editor. 
4. Receive the signed file with its attached Content Credential. 
   

Here’s an example using a single command:

This API call returns the signed content, allowing an application to save the protected file and continue processing it within the existing workflow.

DigiCert Content Trust Manager operates the signing infrastructure, allowing development teams to focus on adding verifiable provenance to their applications rather than managing PKI, certificates, private keys, and conformance themselves.

DigiCert continues to add integration options and capabilities. Consult the current product documentation for the latest APIs, supported formats, and implementation guidance.

Build trust into every Content Credential

C2PA provides a standard way to make content provenance verifiable, but the trust behind each credential depends on how the signing service is built and operated. As adoption grows, teams will need to look beyond the visible badge and consider the infrastructure that keeps provenance secure, interoperable, and trusted over time.

Watch a demo to see how DigiCert Content Trust Manager supports trusted C2PA signing and content provenance at scale.