What Is the UN Transparency Protocol (UNTP), and How Does It Work?

UNTP is an emerging way for organisations to exchange product, facility, traceability, conformity and identity data as machine-verifiable credentials. The important part is what it is not: it is not a central database, not a software platform and not a replacement for the law that creates a Digital Product Passport obligation.

UNTP in one sentence

UNTP is a common protocol for packaging and exchanging supply-chain facts so that one organisation can publish them and another can discover and verify them without both parties first agreeing a private point-to-point data format.

That matters because product data usually crosses organisational boundaries. A brand might hold the product master. A factory holds production evidence. A certification body holds an assessment result. A logistics provider creates events. A regulator, customer or downstream business may need only part of that picture.

UNTP tries to make those exchanges more portable. The protocol is deliberately protocol over platform. It does not require every participant to join one vendor network or copy all of its data into one global database. Credentials can remain distributed and be retrieved through resolvable identifiers and service links.

This decentralised design is also why UNTP is better understood as an interoperability layer than as a new product-data system. A business can keep a governed internal product record and expose selected facts through UNTP credentials when there is a reason to exchange them.

Recommendation 49 and the technical protocol are not the same thing

UNECE Recommendation No. 49, Transparency at Scale, is the adopted policy recommendation. It sets the broader direction for scalable, interoperable and trustworthy information exchange across value chains.

UNTP is the technical work that turns that direction into implementable data and credential patterns. The distinction matters for maturity. Recommendation 49 being adopted does not mean every UNTP technical component is finished, nor does it turn an emerging protocol profile into a legal requirement.

A useful rule is:

• Recommendation 49 provides the policy framework and rationale.
• UNTP provides the developing technical protocol and implementation patterns.
• Jurisdictional law still decides what information is legally required, by whom and for which products.

The UNTP architecture: product, facility, event, conformity and identity

UNTP is easier to understand as a small set of related credential types rather than one giant passport schema.

The components are designed to work together, but they do not have to collapse into one document. A product credential can point to conformity evidence. A traceability event can refer to a product identifier. A facility record can provide context without being copied into every product record.

This is one of UNTP's more useful architectural ideas: the product record does not have to carry every piece of evidence inside itself.

What a Discover, Resolve, Verify flow actually does

UNTP separates three jobs that are often blurred together.

Discover starts with an identifier. The identifier tells software what it is dealing with and gives it a route towards relevant digital services or records.

Resolve follows that route. An Identity Resolver can return links to credentials or service endpoints associated with the identifier.

Verify is a separate act. The receiving system still has to check the credential's proof, issuer information, status and whatever trust policy applies to the claim.

That last step is essential. Finding a credential does not prove it. A URL resolving successfully does not mean the issuer is authorised. A valid cryptographic proof does not prove the physical object in front of you is the object described by the record.

For the deeper trust boundary, see what a verifiable credential actually proves. For the identity and discovery side, see how product identity can become an API endpoint.

UNTP reuses mature standards, but the profile is still emerging

UNTP is not trying to invent every technical layer from scratch. Its architecture builds on standards that already have their own maturity and adoption history.

This mixed maturity is normal in standards work. A new profile can sit on mature foundations and still need time for its own release stability, conformance tooling and deployment evidence.

It also answers a common question: UNTP does not require blockchain. W3C DIDs can use different methods and underlying technologies. UNTP's architectural requirement is interoperability around identifiers, credentials and verification, not one ledger technology.

What implementation evidence exists today

UNTP has moved beyond a purely conceptual paper exercise. The official software implementer register contains named implementers and records their stated development status.

That evidence needs to be read carefully. At the 6 September 2026 check, most entries remained planned rather than evidenced as mature production implementations. One listed implementation, Reeco, was shown as active against UNTP 0.7.0, but the register recorded no conformance observations for it.

So the strongest defensible statement is not “UNTP is already proven at scale”. It is that there is an active implementation community and pre-production work around a concrete protocol, while broad conformance and production evidence are still developing.

Register membership is not the same as observed conformance. A pilot is not the same as a durable production deployment. The protocol's own status language remains the better guide to maturity.

Where UNTP fits beside existing standards and regulation

UNTP sits in a different layer from most of the rules it may interact with.

A regulation can say that a product must have a Digital Product Passport and define the information that must be available. A European standard can define horizontal technical requirements for parts of that system. A sector standard such as EPCIS can define how a particular kind of event data is represented. UNTP can then provide a common credential and discovery pattern for exchanging some of those facts across organisations and jurisdictions.

That means coexistence is more plausible than replacement.

For example, UNTP Digital Traceability Events can work with established event models rather than forcing businesses to abandon them. See EPCIS events versus product master data for the distinction. For the regulatory comparison, see EU Digital Product Passport vs UNTP DPP. For the status of the European horizontal DPP standards, use the DPP standards status owner.

What should a company do now?

For most organisations, the sensible position is learn and pilot, but do not make UNTP your only production truth layer yet.

Watch the official version and implementation registers. The protocol is moving quickly enough that version assumptions should be dated and revisited.

Pilot if you have a real cross-company interoperability problem, especially where the same governed product or conformity facts need to be exchanged with several parties. A pilot can test identifier resolution, credential generation, verification and mapping without pretending the standard is settled.

Keep your internal product record independent of the exchange profile. Your source of truth should know which fact is current, what evidence supports it and at what granularity it applies. That makes it possible to publish the same governed fact through an EU DPP interface, UNTP credential or another channel without letting one emerging protocol become the master record.

Do not treat technical verification as substantive assurance. A signed credential is valuable, but it does not remove the need to know who made the claim, what evidence supports it and whether the claim applies to the physical product.

What would change this page

This page should be rechecked when UN/CEFACT publishes a stable UNTP 1.0 release, changes the status language on the official specification, publishes formal conformance tooling or records credible conformance observations and sustained production deployments in the implementer register.

Those events could justify moving parts of UNTP from emerging towards now. Until then, the safest description is a concrete, actively implemented pre-production interoperability protocol built on several mature standards.

Sources

• UNTP Documentation Versions, UNECE / UN/CEFACT
• UNTP Technical Specifications, UNECE / UN/CEFACT
• About UNTP, UNECE / UN/CEFACT
• UNTP Requirements, UNECE / UN/CEFACT
• UNTP Architecture, UNECE / UN/CEFACT
• UNTP Digital Product Passport specification, UNECE / UN/CEFACT
• UNTP Software Implementer Register, UNECE / UN/CEFACT
• Recommendation No. 49: Transparency at Scale, UNECE
• Verifiable Credentials Data Model v2.0, W3C