What Data Must a Digital Product Passport Contain?

Ask five vendors what a Digital Product Passport must contain and you will get five different field lists. They are all partly right, because the ESPR deliberately does not specify a universal schema — each product group's delegated act sets its own. What is common is the categories the data is drawn from, and those are stable enough to build against today.

The five data families

Family one: identity

Identity answers "which thing is this?" It is the only family most organisations already hold in a usable state, because it lives in the ERP or PIM and has commercial value independent of regulation.

Family two: composition

Composition is where DPP programmes go wrong. The data is unambiguous, technically simple, and almost never available — because it lives with suppliers who have never been asked, do not measure it, and are not contractually obliged to provide it.

Read the right-hand column carefully. Nearly everything a regulator wants sits two or three steps beyond the supplier you have a relationship with. That is a commercial and contractual problem long before it is a technical one.

Family three: environmental impact

Impact data quantifies what producing the item cost. The methodology matters as much as the number: a footprint calculated to a different boundary is not comparable, and a regulator will ask which standard you used.

• Carbon footprint by lifecycle stage — raw material, manufacturing, distribution, use and end-of-life, calculated to ISO 14040 and 14044 or the GHG Protocol Product Standard.
• Water and energy consumption — increasingly required for textiles and electronics, where use-phase or processing impact dominates.
• The methodology declaration itself — the standard applied, the system boundary, and whether data is primary or secondary. Without it, the number is not auditable.

Family four: durability and repair

This family is the ESPR's most direct intervention in product design, because it makes design decisions publicly visible and comparable.

• Expected lifetime under defined conditions, which for batteries becomes cycle life and state of health.
• Spare parts availability — which parts, for how long after the last unit is sold, and at what price.
• Repair documentation — instructions detailed enough for an independent repairer, not only an authorised one.
• Disassembly sequence — the order and tools needed to take the product apart without destroying recoverable material.
• Repairability score where the delegated act defines one.

Family five: end of life

This is the family the passport exists for. Everything else is instrumentation; this is the payload, and it is read by someone who has no relationship with you and no reason to call.

• Recyclability by material stream, so a sorter knows what can actually be recovered.
• Take-back routes — where the product can be returned, and by whom.
• Hazardous handling instructions for safe treatment.
• Depollution steps for regulated components such as batteries and capacitors.

How to model this without guessing the final schema

Since no universal field list exists yet, the architectural question is what you model against. There are two options, and one of them is a trap.

The second approach also handles the case where two regulations want the same fact in different shapes — CSRD wants aggregate emissions, the ESPR wants them per product — because both become views over one underlying record.

The field nobody lists: attribution

Every field above needs one more thing attached: who said so. A passport that asserts 22% recycled cobalt without recording which party asserted it, when, and on what basis is a marketing claim in structured form.

Issuing each material claim as a signed W3C Verifiable Credential from the party who actually knows it turns the passport from a store of assertions into a chain of evidence a third party can check without trusting the platform hosting it. That distinction is what an auditor is looking for.