What data must a Digital Product Passport contain?

One layer is settled and safe to build against. The other does not exist for any product group. Knowing which is which saves a great deal of wasted work.

Passport data splits cleanly into two layers with completely different maturity. Conflating them is the most common cause of both wasted effort and misplaced confidence.

Layer one: the Annex III data elements

Fixed by the framework. Every passport draws from this closed list, whatever the product. This layer is stable and safe to design storage for today.

  • Unique product identifier — persistent, and the anchor for everything else.
  • GTIN per ISO/IEC 15459-6 or equivalent, for products or their parts.
  • Commodity codes — TARIC or equivalent, used at the customs verification step.
  • Compliance documentation — declaration of conformity, technical documentation, conformity certificates.
  • User manuals, instructions, warnings and safety information.
  • Manufacturer information, including its unique operator identifier.
  • Unique operator identifiers for other actors in the chain.
  • Unique facility identifiers.
  • Importer information, including EORI number.
  • EU-established responsible operator — name, contact details and unique operator identifier, under Article 4 of Regulation (EU) 2019/1020.
  • DPP service provider reference — who hosts the back-up copy.

Voluntary label information may also be included, and Annex III explicitly contemplates recording whether an EU Ecolabel has been awarded.

Layer two: the Annex I parameters

This is the sustainability content, and it arrives through information requirements set per product group. The parameters a delegated act may draw on include:

  • Durability and reliability — guaranteed lifetime, technical lifetime, mean time between failures, resistance to stress and ageing.
  • Ease of repair and maintenance — spare part availability, delivery time and affordability, modularity, tool compatibility, repair instructions, ease of non-destructive disassembly, and conditions for accessing product data, hardware and software.
  • Ease of upgrading, reuse, remanufacturing and refurbishment.
  • Design for recycling, and avoidance of technical solutions that impede repair, reuse or recycling.
  • Use of substances, in particular substances of concern.
  • Energy, water and other resource use, including deforestation impact.
  • Recycled content and material recovery, including critical raw materials.
  • Sustainable renewable materials content.
  • Weight and volume, and the product-to-packaging ratio.
  • Incorporation of used components; consumables; environmental footprint.

Which of these apply to your product, at what granularity, against which test methods — none of that exists yet for any product group.

Substances of concern: the one to start on

Article 7(5) is unusually specific for framework-level text, which makes it the one part of layer two you can act on now. Where substances of concern are covered, the passport must include at least:

  • Identification — IUPAC name, other names, trade names and abbreviations, EC number from EINECS, ELINCS or NLP, or ECHA number, and CAS name and number.
  • Location within the product. Not just presence — where it is.
  • Concentration, maximum concentration or concentration range, at product, component or spare-part level.
  • Safe use instructions.
  • End-of-life information relevant to disassembly, preparation for reuse, reuse, recycling and environmentally sound management.

"Substance of concern" is defined by reference to REACH Articles 57 and 59(1) — the SVHC list — plus a broad set of CLP hazard classes including carcinogenicity, germ cell mutagenicity, reproductive toxicity, endocrine disruption, PBT/vPvB and PMT/vPvM properties, respiratory and skin sensitisation, and several aquatic and organ toxicity categories.

This is the field with the longest supply chain lead time, and it does not depend on your delegated act to start on. If you begin one thing today, begin this.

The one concrete example: batteries

Because the Batteries Regulation is further ahead, its Annex XIII is the only fully specified passport data set in EU law. It is worth reading even if you do not sell batteries, because it shows what a mature delegated act looks like — and how much detail "recycled content" turns into once specified. See the batteries page.

Data quality is a legal requirement

Article 9 requires passport data to be accurate, complete and up to date. That is not aspirational language; it is the standard against which your passport is judged.

Three practical consequences that should shape your schema:

  • Provenance matters. Store where each value came from and which document backs it, because "our supplier told us" is a position you may have to defend.
  • Values change. Recycled content varies between production runs. A model that assumes one permanent value per SKU will be wrong the first time a supplier changes feedstock.
  • Wrong is worse than absent. A passport is a public, machine-readable declaration tied to a product identifier. An incorrect figure is trivially checkable by an authority, a competitor or a journalist — and unlike a gap, it is a documented misstatement.

Format and interoperability

Article 10 requires passport data to be open-standard, interoperable, machine-readable, structured, searchable and transferable without vendor lock-in. That last phrase has real procurement consequences: a DPP platform that cannot export your complete passport data in an open format is not a compliant place to keep it.

The EU DPP Registry that went live on 20 July 2026 includes a free semantic repository of machine-readable data models and vocabulary — currently the best available reference for how the Commission expects passport data to be structured.

Questions

Can I start building a passport schema now?
Yes, for layer one — the Annex III framework elements are settled. Design identifier storage, operator and facility identifiers, commodity codes and compliance document references now. Hold off on modelling product-specific sustainability fields in detail until your delegated act exists, but do start collecting substance-of-concern data, because that has the longest lead time and is defined at framework level.
How specific does substance data have to be?
More specific than most merchants expect. Article 7(5) requires not just identification but the location of the substance within the product and its concentration or concentration range, potentially at component or spare-part level, plus safe-use and end-of-life information. That is a level of detail only the manufacturer can supply.
What if the data does not exist anywhere in our supply chain?
That is the normal starting position, particularly for carbon footprint. Someone upstream has to produce it, often by commissioning a calculation to a defined methodology, and that takes months. It is also why the readiness checklist puts supplier engagement first and schema design fourth.
Is there a standard DPP data format we can adopt?
The European standards published in May 2026 cover data exchange, identifiers, carriers, storage, APIs and interoperability, and the Commission's registry now publishes a semantic repository of data models. Those are the right things to build against. But there is no product-specific schema, because there is no product-specific delegated act.

Sources

Turn this into a plan for your catalogue

The readiness checklist walks your product groups one at a time and tells you what data to start collecting from suppliers now.

Open the readiness checklist