Digital Product Passport platform for product data, documents and compliance

A Digital Product Passport platform has to do more than show a product page behind a QR code. It must hold structured, versioned product data tied to a unique identifier, attach the right evidence documents, serve different information to consumers, business partners and authorities, and stay in sync with the ERP and PIM that already manage most of that data. If a platform cannot handle identifiers, access levels and change history, it is a product microsite, not a passport. This article explains what those requirements mean in practice and how to start without waiting for every regulation to be final.

Why product data teams are dealing with this now

The EU Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781) entered into force in July 2024 and makes the Digital Product Passport the standard way to deliver product sustainability information. It does not switch on obligations for everything at once. Requirements are set product group by product group in delegated acts, and the Commission's first working plan names groups such as textiles, steel, aluminium, furniture and tyres as priorities. Batteries have their own timeline under the Battery Regulation (EU) 2023/1542: EV batteries, light means of transport batteries and industrial batteries above 2 kWh need a battery passport from 18 February 2027.

For most manufacturers the exact field list for their products is not yet fixed. What is already clear is the shape of the problem: product-level data, a data carrier on the product, a unique identifier, controlled access and information that remains available for the product's lifetime. Those are architectural decisions you can prepare now.

What a DPP platform needs to handle

Identifiers and granularity

Every passport is tied to a unique product identifier. Depending on the product group, the passport may apply to a model, a batch or an individual item. This matters for your data model: a model-level passport can be generated from PIM data, while an item-level passport needs data from production, such as serial numbers, batch composition or test results. Many companies use GS1 identifiers and GS1 Digital Link URLs in the QR code, because the same code can then serve retail and passport purposes.

Structured data, not documents only

Declarations of conformity, safety data sheets and manuals will still exist as files. But the passport itself should expose attributes as structured data: materials, recycled content, repair information, substances of concern, and whatever the delegated act for your product group requires. Structured data can be validated, versioned, translated and delivered through an API. A PDF cannot.

Access levels

Not every piece of information is public. A typical passport distinguishes at least three audiences:

• Public: product identity, basic sustainability information, care and repair instructions, end-of-life guidance.
• Business partners: repairers, recyclers or distributors who need disassembly details or component data.
• Authorities: market surveillance and customs, who may need access to compliance evidence.

The platform needs authentication and authorisation per audience, not just a hidden URL.

Versioning and lifetime availability

Product data changes: a supplier switches, a material is replaced, a document is reissued. A passport must show what was true for a specific item or batch, while keeping the history. That means immutable versions, clear effective dates and a publication workflow with review, not direct edits on a live page. The passport also has to remain reachable for years, so hosting, domain and URL structure deserve the same care as the data.

How the platform fits your existing systems

A DPP platform should not become a fourth place where product data is typed in by hand. A workable data flow looks like this:

1. ERP provides the article master, identifiers, batches and serial numbers.
2. PIM provides descriptions, images, technical attributes and translations.
3. Suppliers provide material and substance data, ideally through a structured import or portal rather than email attachments.
4. The DPP platform combines these sources, adds passport-specific attributes and documents, runs validation and publication, and exposes the result through public pages, authenticated views and an API.
5. The data carrier – usually a QR code – resolves to the right passport version for the model, batch or item.

Each import should be logged and validated against the required fields for the product group, so gaps are visible before publication rather than after a customer or inspector scans the code. We discuss the relationship between product data systems in more depth in product data platforms for e-commerce, B2B and compliance.

Build a platform or use one

You can build passport functionality into an existing system, develop a dedicated platform, or use an existing DPP product and connect it to your data. Criteria that help:

• Number of product families and variants. A few dozen models can be handled differently from tens of thousands of serialised items.
• Data sources. If most data is already clean in a PIM, integration effort is lower. If it lives in spreadsheets and supplier emails, data work dominates the project, whatever tool you choose.
• Access control needs. Partner and authority access adds real complexity that simple product-page tools do not cover.
• Long-term ownership. Someone must maintain the platform as delegated acts and standards evolve. CEN and CENELEC are developing harmonised standards for passports, and your platform should be able to adapt when they are published.

This is the gap we built DPPC – Digital Product Passport Cloud for: public product cards and QR access, structured documents, an editorial workflow for updates and an API for integration with ERP, PIM and e-commerce. You can read how the product was developed in the DPPC case study.

Common mistakes

• Starting with the QR code. The label is the last step. Without identifiers and structured data behind it, the code leads to a static page that will need rebuilding.
• Copying data manually into the passport tool. It works for a pilot and fails at scale. Plan integrations from the start, even if the first import is a file.
• Ignoring suppliers. Material and substance data usually comes from upstream. Without a process for collecting and checking it, the passport will have gaps.
• One access level for everything. Publishing everything publicly exposes sensitive data; hiding everything defeats the purpose.
• No ownership inside the company. Passports touch product management, quality, compliance and IT. Without a clear owner, updates stall.

Readiness checklist

• Do we know which regulations and product groups apply to our portfolio?
• Do we have unique identifiers at the level the passport will require?
• Can we list, per attribute, which system or supplier is the source?
• Are compliance documents stored centrally, with versions and validity dates?
• Is there a review and approval step before product information goes public?
• Can our systems export this data through an API or at least a structured file?

Next step

Pick one product family and build a simple inventory: the attributes and documents a passport will probably need, where each one lives today and who is responsible for it. That exercise usually reveals whether the main challenge is data, integration or process. Our DPPC product data services start exactly there, and if you would like to walk through your inventory with us, contact us.