A product can create a C2PA manifest that parses correctly without participating in the official C2PA trust ecosystem. It may use the published specification, an open-source SDK, or its own implementation and still remain entirely self-declared. Technical interoperability is important, but it does not by itself tell a buyer or verifier whether the product has been independently assessed, whether its signing keys are protected appropriately, or whether the organization operating it has accepted ongoing accountability.
The C2PA Conformance Program adds that governance layer. It evaluates defined generator and validator products against functional requirements, evaluates generator products against implementation-security requirements, assesses participating certification authorities under the C2PA Certificate Policy, and publishes recognized products and trust anchors in public records. The current program version is v0.2, dated July 31, 2026, and supports products implementing C2PA specification versions 2.2 and 2.4.[1]
Conformance is therefore neither a decorative badge nor a verdict about the truth of an asset. It is a structured assurance signal about a declared product, its assessed scope, and the controls surrounding the C2PA functions for which that product takes responsibility. Individual Content Credentials must still be validated, trust policies must still be applied, and people must still interpret the provenance in context.
In brief The specification defines how Content Credentials are created and validated. The Conformance Program assesses whether named products implement those rules within a declared scope and, for generator products, how securely the signing system is built. The Conforming Products List records recognized products; the C2PA Trust List records approved certification-authority trust anchors; and the C2PA TSA Trust List records approved time-stamping trust anchors. None of these lists proves that the content of a particular asset is true. |
|---|
Why the specification alone is not enough
An open specification is necessary for interoperability. It gives independent implementers a common manifest format, assertion model, signing process, validation algorithm, trust model, and set of media-format bindings. But the specification cannot, by itself, establish whether a vendor implemented all relevant requirements correctly or whether the surrounding production system behaves securely.
That gap becomes especially important once Content Credentials influence publishing decisions, customer contracts, regulatory evidence, newsroom workflows, or platform policy. A relying party may need answers to questions that are not visible from one manifest alone:
- Which product generated or validated this credential?
- Which versions and media types were included in its assessment?
- Does the product create manifests, validate them, or perform both roles?
- Where are the claim-signing keys stored and used?
- Does a remote service or third-party component participate in the signing boundary?
- Which certification authority issued the product instance its signing certificate?
- What public record can be checked if the product changes status or suffers an incident?
The program is intended to make those relationships more transparent and accountable. The official C2PA overview describes it as a risk-based, transparent, and unbiased governance process for generator products, validator products, and certification authorities. Recognized products are placed on a publicly accessible list, while approved trust anchors are published separately.[2]
What C2PA conformance means
A conforming product is a specific generator product or validator product that has been assessed under the program and appears on the C2PA Conforming Products List with a conformant status. The listing is tied to a declared product record, not merely to a company name or to the fact that the company uses C2PA somewhere in its technology stack.
For a generator product, the assessment covers both functional behavior and implementation security. For a validator product, it covers the declared validation capabilities and result behavior. Certification authorities are assessed against a separate Certificate Policy before their trust anchors can be placed on the C2PA Trust List. These are related forms of recognition, but they are not interchangeable.
Program concept | What it establishes | What it does not establish |
|---|---|---|
Conforming generator product | The declared product has been assessed for C2PA generation functions and assigned a maximum implementation-security assurance level. | That every asset it signs is factually true, complete, correctly labeled, or appropriate for every relying party. |
Conforming validator product | The declared product has been assessed for the validation functions and media types represented in its public record. | That its user interface, business policy, or every downstream decision is correct in every context. |
Participating certification authority | The CA has been assessed against the C2PA Certificate Policy for the trust anchors placed on the official list. | That every certificate the organization issues for every unrelated purpose is a C2PA-trusted certificate. |
Trusted product instance certificate | A conforming generator-product instance received a C2PA claim-signing certificate under the program trust model. | That the signer is honest, the assertions are true, or the current asset passes all validation checks. |
The practical distinction between conformance and per-asset verification is fundamental. A product can be conforming while a particular output is invalid because the file was modified after signing, a required external resource is unavailable, or a credential was created incorrectly in a specific transaction. Conversely, a credential from a product outside the official program can still be cryptographically valid under a private trust configuration. Conformance supplies a governed ecosystem signal; it does not replace the actual validation result.
Who and what the program governs
The current program recognizes several roles, each with a different responsibility boundary.
Role | Responsibility under the program | Public record |
|---|---|---|
Generator product | Creates assets with C2PA manifests and signs the claim. It remains accountable even when it uses a separate local or remote claim-generator service. | Conforming Products List, including declared scope and maximum assurance level. |
Validator product | Processes assets and manifests, applies required validation procedures, and reports validation results for its declared scope. | Conforming Products List, including declared validation media types. |
Certification authority | Issues and manages C2PA claim-signing certificates under the C2PA Certificate Policy. | C2PA Trust List for approved CA trust anchors. |
Time-stamping authority | Issues trusted time-stamps under the separate time-stamping trust model. The current program accepts TSA participation through an applicant that also provides a CA service. | C2PA TSA Trust List for approved TSA trust anchors. |
A company is not the same as a product
A company may operate several C2PA products, versions, deployment models, or services. Each public record describes a product and the scope reviewed for that record. A company that has one conforming generator product cannot automatically describe every other application, library, or service it operates as conforming.
The same separation applies when one product performs more than one role. An applicant seeking recognition as both a generator product and a validator product must address each role and execute the applicable program process for each. Buyers should therefore check the product type and declared capabilities rather than relying on a corporate logo or a general compatibility claim.
The Target of Evaluation
The program calls the system being evaluated the Target of Evaluation, or TOE. This boundary includes the product and the subsystems it relies upon to produce or validate assets with C2PA manifests. For a generator product, that generally includes the components involved in creating assertions, constructing the claim, signing it, and storing or using the claim-signing key.
A TOE can be implemented at the edge, in a backend environment, or across a distributed architecture. A camera may perform capture, manifest creation, and signing on-device. A generative service may build and sign manifests in cloud infrastructure. A distributed mobile application may create assertions at the edge while a remote service authorizes and performs signing. The assessment boundary follows the actual C2PA responsibility, not a convenient marketing description.
Outsourcing a component does not remove accountability. Under the program model, a generator product remains the signer and is responsible for the conformant output even if a third-party service constructs the claim or performs another C2PA function. A validator product likewise remains responsible for the results it presents when it depends on an external validation service. This is one reason product-boundary documentation is a central part of the assessment.
The three public records
The program publishes three principal machine-readable records. The C2PA Conformance Explorer provides a human-readable way to browse, search, and filter their live contents.[2]
Record | What it contains | How it is used |
|---|---|---|
C2PA Conforming Products List (CPL) | Recognized generator and validator product records, their status, declared product type, specification and program versions, supported media types, dates, and generator maximum assurance information. | Buyers, CAs, validators, and relying parties use it to identify the exact product and scope that the program recognizes. |
C2PA Trust List (C2PA TL) | Approved X.509 certification-authority trust anchors for C2PA claim-signing certificates issued under the program Certificate Policy. | Validators use it as an official trust source when building a certificate path for a C2PA signer. |
C2PA TSA Trust List | Approved X.509 trust anchors for time-stamping authorities participating in the C2PA trust ecosystem. | Validators use it separately when evaluating trusted time-stamp evidence. |
How to read a Conforming Products List record
A CPL entry should be read as a structured scope statement. Depending on the product type, it can include the applicant, product name, product role, record status, product-version information, supported C2PA specification version, conformance-program version, media types generated or validated, dates, maximum assurance level, and attestation methods. The exact fields may evolve with the program schema.
Four details deserve particular attention:
- Status. Confirm that the record is currently conformant rather than relying on an old announcement or copied badge.
- Product identity and version scope. Match the deployed product or service to the record instead of assuming the company entry covers every release.
- Declared media and role scope. A product assessed for JPEG generation is not thereby assessed for live video validation or every format supported by the C2PA specification.
- Program and specification version. Conformance is evaluated against named program and specification baselines, which matter when requirements change.
For audit-sensitive workflows, organizations should retain the list snapshot and product record used at the time of a decision. A live list is designed to change when products are added, updated, suspended, removed, or migrated to newer program versions. Historical evidence should not depend solely on what a web interface shows years later.
Conformance is more than one interoperability test
The program combines several kinds of evidence. Passing a sample-file test is useful, but it is only one part of the assessment.
Assessment layer | Purpose |
|---|---|
Core specification requirements | Tests whether the product implements applicable normative C2PA generation or validation behavior for its declared scope. |
Additional conformance requirements | Applies program-specific requirements that supplement or clarify the core specification for the recognized ecosystem. |
Generator-product security requirements | Evaluates how the generator system identifies product instances, protects signing keys, resists misuse, and operates securely. |
Certificate Policy requirements | Governs how participating CAs verify eligibility, issue certificates, manage keys and status, and support the trust model. |
Governance and legal commitments | Creates accountability for the applicant, public records, incident handling, ongoing status, and adherence to program terms. |
This layered model explains why an implementation built with a conforming SDK is not automatically a conforming product. An SDK can help produce correctly structured manifests, but the deployed product still determines the assertion policy, media pipeline, signing authorization, key boundary, certificate enrollment, validation behavior, reporting, and operational controls.
Functional evidence and asset rubrics
Applicants declare the media types and C2PA functions for which they seek recognition. Generator-product applicants provide sample output assets for the asserted generation and validation media types, together with machine-readable validation representations such as crJSON or JSON. Validator-product applicants provide sample validation results for their asserted media types and may be asked to support independent testing against the program corpus.
The public program also includes versioned C2PA Asset Rubrics. These are standardized, machine-evaluable rules applied to validated asset data, allowing the program to evaluate conformance consistently and classify relevant asset characteristics. The rubrics operate after validation rather than replacing the validator itself, and compiled variants correspond to particular conformance-program and specification combinations.[6]
Evidence still requires interpretation. A single valid sample does not demonstrate that every branch of a production system is correct, and a single invalid sample does not automatically reveal whether the fault lies in manifest generation, format handling, signing, serialization, or validation. Applicants should maintain a broader test corpus that includes valid assets, malformed inputs, boundary cases, update manifests, ingredient graphs, external resources, unsupported features, and expected failure statuses.
Generator-product security assessment
Generator products receive additional scrutiny because they make signed provenance statements and control the claim-signing key. A functionally correct manifest can still be misleading if an attacker can invoke the signing service without authorization, replace the generator binary, extract the key, manipulate assertions before signing, or compromise the backend that approves requests.
Applicants document the generator product security architecture and the full Target of Evaluation. The assessment considers the product class, the location and use of signing keys, product-instance identification, software and dependency controls, external inputs, access controls, auditability, incident handling, and the evidence a deployed instance can present when requesting a signing certificate. The security requirements are intentionally architecture-aware: an on-device camera, a cloud generator, and a distributed mobile-to-cloud system do not have identical threats or controls.[3]
Assurance Levels
The current program operates two generator-product Assurance Levels: Level 1 and Level 2. These levels communicate confidence in the implementation security of the generator product and its instances. They are not content-quality ratings, truth scores, or measures of how reputable the signer is.
Concept | Meaning | Where it appears |
|---|---|---|
Max Assurance Level | The highest level the product is eligible to support based on the static evidence and security properties assessed for the product TOE. | Recorded in the generator product CPL record. |
Instance Assurance Level | The level assigned to a particular deployed instance when it enrolls for a claim-signing certificate and presents the required dynamic evidence. It cannot exceed the product maximum. | Encoded in the instance claim-signing certificate using the C2PA assurance-level extension. |
Level 1 | The current baseline level required for a conforming generator product, with defined controls for product identity, key protection, secure operation, misuse resistance, and supporting evidence. | Product assessment and eligible Level 1 instance certificates. |
Level 2 | Adds stronger requirements, including hardware-rooted evidence, stronger separation for key use, and additional exploit, build, monitoring, and infrastructure controls where applicable. | Product assessment and eligible Level 2 instance certificates when dynamic evidence supports it. |
The distinction between a maximum and an instance level prevents the product listing from overstating every deployment. A product architecture may be capable of Level 2, while a particular instance presents only the evidence required for Level 1 during certificate enrollment. The certificate can therefore carry a lower level than the product maximum. The current program conveys the instance level through the custom X.509 extension commonly described as the c2pa-al extension.[1]
At a high level, Level 2 builds on Level 1 with stronger evidence that the expected product binary and environment are present, stronger isolation for the signing key, and additional defensive controls. The precise requirements depend on the implementation class and should be read from the current security-requirements document rather than inferred from the label alone. An assurance level should be one input to a relying party policy, not a universal accept-or-reject rule.
The link between conformance and signing certificates
The official conformance and trust systems are connected through certificate issuance. Under the program Certificate Policy, C2PA claim-signing certificates are issued by a CA whose relevant trust anchor appears on the C2PA Trust List, and only to eligible instances of conforming generator products. The product must have completed the applicable process and received a signed Notice of Conformance before its instances can enroll under this trust model.[4]
The CA does more than look up a company name. It checks the product record and performs the enrollment procedures required by the Certificate Policy. For assurance-sensitive enrollment, it can also evaluate dynamic evidence supplied by the product instance. The resulting certificate identifies the generator product as its subject and can carry the instance assurance level.
A validator then evaluates the asset, claim signature, certificate path, certificate status, time evidence, and configured trust sources. The official C2PA Trust List helps determine whether the chain terminates at a recognized program trust anchor. The separate TSA Trust List performs a similar role for trusted time-stamps. The broader certificate and trust process is explained in C2PA Certificates and Trust Lists.
The trust-list transition also matters historically. The official C2PA Trust List launched with the mature program in 2025, while the former Interim Trust List was frozen on January 1, 2026. Legacy credentials can still be interpreted under the older trust model, but new program-aligned signing should use the official lists and the 2.x trust framework.[2]
How a product becomes conformant
The exact administrative details can evolve, but the current v0.2 process follows a recognizable sequence:
1. Submit an Expression of Interest. The applicant identifies the legal organization and the roles for which it intends to apply.
2. Execute the applicable legal agreement. Generator, validator, and certification-authority roles use separate agreements. A company applying for more than one role addresses each separately.
3. Complete the program intake record. The applicant defines the product, role, versions, media types, public-record details, and requested disclosure timing.
4. Perform interoperability testing. The program strongly recommends testing before intake so the applicant can identify generation and validation incompatibilities early.
5. Submit functional evidence. Generator and validator applicants provide samples and machine-readable results for the declared media scope.
6. Submit role-specific assurance evidence. Generator applicants provide a security-architecture description; CAs provide certificate-profile and key-ceremony evidence or applicable independent assurance.
7. Complete assessment and remediation. The program administrator and approvers examine the record and evidence, request clarification, and resolve findings.
8. Receive the conformance decision. A successful applicant receives a digitally signed Notice of Conformance for the assessed product or role.
9. Publish the record. The conforming product or trust anchor is entered into the appropriate public list, subject to any approved earliest-public-disclosure date.
10. Enroll eligible product instances. Conforming generator-product instances obtain claim-signing certificates from participating CAs and present required dynamic evidence.
The current program states that there is no application fee for generator-product companies, validator-product companies, or certification authorities, and no fee for adding approved records to the CPL or CA Trust List. That does not mean participation is costless: applicants still bear the engineering, documentation, evidence, testing, legal, certificate-service, and operational costs required to prepare and maintain a conforming implementation.[1]
The program accepts pre-release products and can defer public disclosure until a date supplied through the intake process. That allows a product team to conduct assessment before launch without automatically publishing confidential release information during review.
Maintaining conformance after approval
Conformance is not a one-time statement that permanently covers every future version. A product must be resubmitted when it undergoes a material change that alters its public record or affects its conformance to the applicable functional or security requirements. Examples may include a materially different signing architecture, key-storage model, supported media scope, product identity, or security boundary.[1]
Program documents and specification baselines are themselves versioned. New program versions have sunrise dates, previous versions can receive sunset dates, and implementers receive a transition period. Product teams should therefore treat conformance maintenance as part of release management rather than as a launch-only compliance project.
Ongoing operational duties also matter:
- Monitor changes to the core specification, additional conformance requirements, security requirements, Certificate Policy, and asset rubrics.
- Track certificate issuance, expiration, status, revocation, and key-rotation procedures.
- Maintain the evidence and reproducible test cases needed to show that current releases remain within the assessed scope.
- Report and respond to material security incidents in accordance with program and certificate obligations.
- Keep public product information accurate and initiate a new application when a change is material.
- Design validators and internal trust services to refresh the CPL, C2PA Trust List, and TSA Trust List safely.
The program can change or remove a product or trust record when requirements are no longer met. Governance processes include review and dispute mechanisms, but organizations should not design systems on the assumption that a status can never change. For high-assurance audit trails, retain the exact list, certificate, policy, and validation snapshots used for each decision.
What conformance does not guarantee
The program raises confidence in implementation and governance, but its boundaries must remain visible.
Conformance can support confidence that... | Conformance does not by itself prove that... |
|---|---|
A named product was assessed for declared C2PA functions and scope. | A depicted event occurred, a statement is honest, or the content is factually true. |
A generator product met the applicable implementation-security requirements for its assigned maximum level. | The product can never be compromised or misconfigured after assessment. |
A validator product was assessed for declared formats and validation behavior. | Every user-interface summary, policy decision, or downstream moderation outcome is correct. |
A participating CA met the Certificate Policy for listed trust anchors. | Every certificate from that organization is eligible for C2PA trust. |
A product record and its status can be checked publicly. | Every version, deployment, plug-in, integration, or customer configuration is covered. |
A conforming generator instance may receive a program-aligned signing certificate. | Every output from the instance is valid, complete, preserved downstream, or legally compliant. |
The broader interpretation limits are discussed in What C2PA Proves - and What It Does Not Prove. The essential point is that conformance is evidence about an implementation and its governance. It is not a substitute for per-asset validation, source evaluation, business policy, or legal analysis.
How buyers and relying parties should use the program
The public lists are most useful when they are treated as structured evidence rather than as a generic badge. A buyer evaluating a C2PA product should:
- Match the exact product. Check the product name, role, status, version scope, and applicant rather than relying on company-level marketing.
- Check the declared media scope. Confirm that the formats and generation or validation operations needed for the intended workflow appear in the record.
- Review the specification and program baselines. A product assessed against an earlier baseline may behave differently from one assessed against the current requirements.
- Understand the maximum assurance level. For generator products, determine whether the listed maximum and the deployed instance certificate meet the relying party policy.
- Validate real output. Inspect assets produced by the actual deployment, including the certificate chain, manifest structure, assertion policy, and expected failure behavior.
- Test the whole pipeline. Conformance does not guarantee that a CDN, transcoder, social platform, or document workflow preserves the credential after publication.
- Plan list and certificate updates. Decide how often systems refresh trust data and how they preserve historical snapshots for evidence.
A procurement team should also distinguish product conformance from organizational suitability. Data residency, privacy, availability, customer isolation, operational logging, support access, retention, disaster recovery, and contractual commitments may be crucial to a deployment even when they are outside the narrow public CPL record.
How implementers should prepare
A product team should begin conformance preparation while designing its architecture, not after the signing endpoint is complete. The following work has high leverage:
- Define the product and TOE boundary. Identify every edge, backend, distributed, third-party, and key-management component that participates in C2PA behavior.
- Create a requirement map. Trace applicable specification clauses, additional conformance criteria, security requirements, and Certificate Policy dependencies to implementation and tests.
- Make format support explicit. Document which media types are generated, validated, merely passed through, or unsupported, including version and transformation caveats.
- Build a reproducible corpus. Retain generated assets, expected validation results, crJSON or JSON output, negative cases, and the exact engine versions used.
- Treat the key boundary as a product capability. Design authorization, custody, isolation, enrollment, rotation, suspension, and incident procedures before production issuance.
- Separate product maximum from instance eligibility. Plan how deployed instances will generate and present dynamic evidence during certificate enrollment.
- Prepare for material change. Make conformance impact review part of architecture decisions and release approval.
A broader production architecture and readiness framework is available in the C2PA Implementation Guide. Teams implementing verification should also review How C2PA Verification Works because validator conformance depends on preserving detailed validation distinctions rather than presenting a single undifferentiated result.
Common misunderstandings
Misunderstanding | More accurate interpretation |
|---|---|
"We use an official or conforming SDK, so our product is conforming." | Libraries can support implementation, but the deployed product, declared scope, security architecture, evidence, and governance must be assessed as the product record. |
"A valid C2PA signature proves the signer product is conforming." | Signature validity is a per-asset cryptographic result. Product conformance is checked through the CPL and the program-aligned certificate and trust ecosystem. |
"If the product is on the CPL, every asset it produces is trusted." | Each asset still requires manifest, binding, signature, certificate, status, and trust evaluation. A product listing cannot repair a broken asset. |
"Assurance Level 2 means the content is more truthful." | The level concerns implementation-security assurance for the generator product instance, not the truthfulness of its assertions. |
"A CA on the C2PA Trust List makes all of its certificates trusted." | Trust applies to certificates issued under the relevant policy, profiles, key usages, chain, validity, and status conditions. |
"The TSA Trust List and C2PA Trust List are the same." | They are separate trust sources for separate signature purposes: claim signing and trusted time-stamping. |
"One company listing covers all of its products and versions." | The record describes the product and scope submitted. Other products, roles, versions, formats, or material changes may require separate or updated records. |
"Conformance guarantees legal compliance." | It can provide useful technical and governance evidence, but legal obligations and business policies require their own analysis and controls. |
The simplest mental model
- The C2PA specification defines the technical rules for creating and validating Content Credentials.
- The Conformance Program assesses declared products, security properties, certification authorities, and governance commitments against a named baseline.
- The Conforming Products List identifies recognized generator and validator products and their assessed scope.
- The C2PA Trust List identifies approved CA trust anchors for claim-signing certificates.
- The C2PA TSA Trust List separately identifies approved time-stamping trust anchors.
- A generator product maximum assurance level describes assessed product capability; an instance assurance level describes what a specific enrolled instance demonstrated.
- A product listing is not a per-asset validation result, a factual-truth judgment, or a legal-compliance certificate.
- Reliable systems preserve the exact product, list, certificate, validation, policy, and evidence versions used for each decision.
The Conformance Program makes C2PA more operationally meaningful by connecting an open technical standard to named products, security expectations, certificate issuance, public records, and ongoing accountability. Its value comes from keeping those layers distinct. The specification says how provenance works. Conformance says which product and scope were assessed. Trust lists help validators recognize program-aligned credentials. Per-asset validation determines what happened to the credential in front of you. Interpretation and policy determine what an organization should do with that evidence.
Sources and notes
Technical source notes are limited to current, normative, version-specific, and governance claims. The primary sources are published by C2PA and its Conformance Task Force.
[1] C2PA Conformance Program v0.2. Program version dated July 31, 2026; roles, definitions, assurance levels, Certificate Policy linkage, fee schedule, applicant process, sample evidence, public records, material change, and version lifecycle.
[2] C2PA Conformance overview and Trust List transition. Purpose of the program, Conformance Explorer, official public lists, launch of the mature trust ecosystem, and the January 1, 2026 freeze of the Interim Trust List.
[3] C2PA Generator Product Security Requirements v0.2. Target of Evaluation, implementation classes, Level 1 and Level 2 controls, hardware-rooted dynamic evidence, signing-key protection, exploit defenses, monitoring, and architecture examples.
[4] C2PA Certificate Policy v0.2. Requirements for participating certification authorities, claim-signing certificate issuance, certificate profiles, subscriber eligibility, status, and program trust.
[5] Additional Conformance Requirements Against the Content Credentials Specification. Program requirements that supplement the core technical specification for assessed products.
[6] C2PA Asset Rubrics v1.0. Versioned machine-evaluable rules used with validated asset data for conformance verification and asset classification.
[7] C2PA Conformance Explorer. Live human-readable access to the Conforming Products List, C2PA Trust List, and C2PA TSA Trust List. See also the machine-readable public records in the C2PA conformance-public repository.
[8] C2PA Technical Specification 2.4. Core manifest, validation, certificate, trust-list, and trusted-time model within which the Conformance Program operates.