Digital Product Passports Need Global Interoperability, Not Another Data Silo

CIRPASS-2, the EU-funded project running Digital Product Passport pilots, set aside 10 November for an open meeting on global DPP collaboration. One of the three topics on its agenda was titled “Doomsday scenarios for DPP”, and it included this line:

Badly designed, DPPs could create new data silos instead of enabling the flow of interoperable data.

That warning comes from inside Europe’s own passport work. The same agenda lists the other risks: passports that become nothing more than a regulatory obligation, with effects beyond EU borders that turn into barriers to trade.

For a manufacturer selling into more than one market, the silo risk is easy to picture. You keep one product record for the EU, another for a customer’s supplier portal, a third for a battery registry in another country, and you spend every quarter reconciling them. We think that outcome is avoidable, and most of the pieces needed to avoid it already exist.

Every market wants product data, in its own shape

The EU is furthest along. Under the Ecodesign for Sustainable Products Regulation (ESPR), the Commission’s DPP registry went live on 20 July 2026. The first product rules, for iron and steel, are expected by the end of this year, with textiles, aluminium and tyres following in 2027. Batteries come first in practice, under the separate Battery Regulation: from 18 February 2027, EV batteries, light means of transport batteries and industrial batteries above 2 kWh need a battery passport.

India is working on batteries too. In January 2026 the Ministry of Road Transport and Highways published draft guidelines for a “Battery Pack Aadhaar”: a 21-character ID for each EV battery pack, marked on the pack as text and as a QR code, with battery data reported to a government portal. The static data it asks for includes material composition and carbon footprint, both of which the EU battery passport also requires.

Plenty of rules never use the word “passport” and still ask for the same kind of data. Australia’s Modern Slavery Act requires large companies to report on supply-chain risks, and its mandatory climate disclosure rules phase in Scope 3 emissions. Canada has a forced-labor reporting law. Japan’s plastics resource circulation law sets design-for-recycling and take-back obligations. UNTP keeps a running list of these regimes, and nearly all of them want evidence about where a product came from and what it contains.

Industries have built their own schemes on top of that, from the Global Battery Alliance’s Battery Passport to Catena-X in automotive and Germany’s DIN DKE SPEC 99100, which defines 94 data attributes for battery passports.

The motivations differ. The EU is focused on circularity and the single market, forced-labor laws on who made the product, climate rules on emissions, and large buyers want all of it for their own audits. So the requests overlap heavily, but they never quite line up.

Proprietary formats turn passports into silos

Many DPP tools handle the first request well. They take your product data, store it in their own schema, and publish a page behind a QR code. The trouble starts with the second request.

When another market or a large customer asks for the same facts in a different structure, you either buy a second tool or pay for a custom module. Your product data now lives in the ERP, in the PLM system and in one or two passport platforms, and the copies drift apart. A change to a bill of materials has to be entered in three places, and only one of them is the record anyone trusts.

Time makes it worse. A passport is meant to outlive the sale, and the EU’s DPP standards include one, EN 18221, just for storage, archiving and persistence. If your passports sit in a format only one vendor can read, switching vendors means migrating years of product history. If the QR code printed on your products resolves through that vendor’s domain, you depend on that vendor to keep redirecting, or you reprint.

EU DPP standards and UNTP do different jobs

Two bodies of work matter most right now: the EU’s DPP standards and the United Nations Transparency Protocol (UNTP). They often get discussed as if you had to pick one. You don’t.

The eight JTC 24 standards define how the European passport system works. EN 18216 and EN 18219 to EN 18223 cover data exchange, identifiers, data carriers, storage, APIs and system interoperability; EN 18239 and EN 18246 cover access rights and data integrity. The first six were cited in the Official Journal in July, and the Commission has said it plans a decision on the last two in November.

UNTP is built for a different problem: carrying product and sustainability data across borders between companies that don’t share software. Its credentials are W3C Verifiable Credentials, so anyone can check the issuer’s signature without calling the issuer’s database. Version 1.0 hasn’t been published yet, though the public review drew feedback from more than 30 countries.

The UNTP team is clear about how the two relate: “UNTP is not a profile of JTC24, and conformance to one does not imply conformance to the other.” Where they overlap, the aim is a published mapping, with EU-specific requirements kept in a jurisdictional extension rather than in the UNTP core. The same page says that pattern applies to every other jurisdiction’s passport regime.

We think that’s the right design. A shared core holds what every market needs (identity, composition, conformity evidence, provenance), and each jurisdiction adds its own rules on top. UNTP reports that a CIRPASS-2 alignment review found the two architecturally interoperable across 14 topics, and that the UNTP passport maps all 94 attributes in DIN DKE SPEC 99100. Those are UNTP’s own assessments, and they’re encouraging. A full mapping for each ESPR product group doesn’t exist yet, and it can’t until those product rules are written.

Identifiers and shared meaning

Two systems can only exchange data about a product if they agree on which product they’re talking about. Identifiers are the first interoperability question, and so far nobody is forcing a single scheme.

According to UNTP’s identity resolver specification, EN 18219, the EU standard on unique identifiers, recognizes several families: ISO/IEC 15459 and ISO/IEC 18975 web-enabled identifiers (using GS1 Application Identifiers or ASC MH10.8.2 Data Identifiers), IEC 61406 Identification Links, decentralized identifiers (DIDs) and DOIs. UNTP’s resolver is scheme-neutral too. Any identifier that can be written as a resolvable web address can take part, and UNTP’s linkset format extends the one GS1 resolvers already use.

So if you already use GTINs and serial numbers, keep them. A scan resolves the identifier to a list of links (the passport, conformity credentials, traceability events), and each link can carry its own access rules. A consumer and a market surveillance authority can scan the same code and see different things.

Shared meaning is the harder half. Two systems can both have a field called “recycled content” and disagree on whether pre-consumer scrap counts. A carbon footprint can be stated per product or per kWh. If those differences get settled by whoever wrote the export script, the data isn’t really interoperable.

UNTP handles this with JSON-LD. Versioned context files map each term to a canonical web address, coded values point to published vocabularies instead of free text, and UNTP maintains mappings to EU passport semantics. A verifier can merge credentials from different issuers and know that “recycled content” means the same thing in each.

One product record, many passports

The way out of separate records is to stop treating each passport as a document you create and start treating it as a view generated from data you already have.

1. Keep your systems of record where they are. ERP, PLM and MES stay the source of truth for product, batch and facility data.
2. Map that data once to a shared, published model. UNTP’s core vocabulary is a sensible choice because it isn’t tied to any one jurisdiction.
3. Generate each jurisdiction’s output from the shared model: an EU passport, a national battery filing, a customer’s due-diligence request.
4. Give each item one identifier you control, and let a resolver point to every passport and credential attached to it.
5. Attach evidence once. A conformity certificate issued as a verifiable credential can back the EU passport and a customer audit without anyone re-entering it.

Take a battery maker shipping packs to a carmaker in Germany and a two-wheeler maker in India. Both markets want material composition and carbon footprint. With this approach those values live in one place, the EU passport and the Indian filing are both produced from them, and a change of cell supplier updates both.

What vendor-neutral architecture looks like

“Vendor-neutral” is easy to claim, so it helps to have questions you can put to any provider, including us.

• Does the passport layer read from your systems, or does it become a new master copy you have to maintain?
• Is the data model published and open (UNTP, the EU standards), or is it the vendor’s own schema?
• Do the identifiers and resolver URLs printed on your products belong to you?
• Can a third party verify a passport by checking a signature, without access to the vendor’s database?
• When a new jurisdiction publishes rules, does that mean a new mapping or a new copy of your data?
• Could you move your passports, identifiers and history to another provider next year without reprinting labels?

If the answer to the last one is no, you’re buying a silo.

Where AgentBridge fits

Ourbits AgentBridge is the layer we’re building for this. It sits between a manufacturer’s systems and everyone who needs product data from them, and it translates in both directions.

On the inbound side, bridge connectors are designed to read product, batch, facility and certification data from ERP, PLM and MES systems and map it once to the UNTP core vocabulary, versioned so a schema change doesn’t break the history. On the outbound side, AgentBridge is being built to produce what each audience needs from that one model: UNTP credentials for trading partners, EU passports aligned with the JTC 24 standards, and other jurisdictions’ formats added as extensions rather than as new data stores. Identity resolution is designed to work across identifier schemes, so a GS1-identified product and a DID-identified facility can sit in the same chain of evidence.

Translation runs the other way too. When a supplier sends a UNTP conformity credential, AgentBridge is designed to verify it and write the relevant facts back into your ERP, so nobody has to retype a PDF.

CIRPASS-2’s agenda asked for interoperability “across borders, across standards stacks, across platforms”. That’s the goal we’re building toward. We’ve written more about the interoperability problem behind it and why we chose a decentralized design.

What to do now

UNTP 1.0 is expected to go to the UN/CEFACT plenary, the last two EU standards are due to be cited, and the first ESPR product rules should appear over the coming months. Battery makers have until February 2027.

None of that requires you to choose a side. It does reward a few early decisions: know where your product data really lives, own your identifiers and resolver domain, and ask every passport vendor the exit question before you sign.

If you’re preparing for battery passports or ESPR and want to keep one product record across markets, we’re preparing multi-organization pilots and would like to hear from you.

---

AgentBridge is in design and pilot preparation. Regulatory dates and standards status in this post come from the European Commission, CEN-CENELEC, CIRPASS-2 and UNTP pages linked above, as of 14 November 2026.