Product Data You Need Before a Digital Product Passport Becomes Mandatory

Compliance

Product Data You Need Before a Digital Product Passport Becomes Mandatory

Arun Krishnan2026-09-139 min read

The list of data a digital product passport needs is public and knowable. The reason most manufacturers are not ready has nothing to do with the list. It is that half of those fields live in systems no passport can read, and a few of them do not exist anywhere yet.

What product data do you need for a digital product passport?

A digital product passport is a structured, machine-readable record, linked to a product through a data carrier, holding its identity, compliance, performance and material data across its life on the market. The European Commission describes it as a digital identity card for products, components and materials.

Annex III of the regulation names the identity and paperwork layer: a persistent unique product identifier, a GTIN under ISO/IEC 15459-6, commodity codes such as a TARIC code, compliance documents including the declaration of conformity and technical documentation, user manuals and safety information, and identifiers for the manufacturer, operators, facilities and importer.

Article 7 adds the performance layer: how a product performs against the Annex I parameters, including repairability, durability and carbon or environmental footprint, plus use, maintenance, repair and end-of-life instructions. Article 7(5) covers substances of concern, each logged by name or code, by location within the product, and by concentration.

One requirement runs across all of it. Article 9(1) demands the data be accurate, complete and up to date, which makes this an ongoing obligation rather than a one-time upload.

Seven clusters, and which ones you already hold

The Annex III menu is long, so it helps to group it the way manufacturers actually store data. A 2023 study by Jensen and colleagues in Sustainable Production and Consumption, drawn from case work across three manufacturers and their suppliers, service partners and recyclers, sorts the requirement into seven clusters.

Read down the last column. Identity and paperwork already exist. The fields that matter most for circular decisions, meaning footprint, substance location and end-of-life data, are the ones you are least able to produce as structured data.

Where the data usually does not exist yet

The same 2023 study found that companies already hold vast amounts of data but house it in dispersed management systems, and that the infrastructure for exchanging it remains at low maturity. The fields a passport most needs are the ones scoring high on importance and low on availability.

That gap bites in three specific places.

• Identity usually stops at SKU or model level. A passport can require model, batch or item level (Article 9(2)(d)). Moving from knowing a product line to knowing a unit means adding serialisation, which is the hardest part of this to retrofit.
• Compliance documents exist, but as PDFs. Article 10(1)(d) demands data that is machine-readable, structured, searchable and transferable without vendor lock-in, so a cabinet of conformity certificates is not passport-ready however complete it is.
• Footprint, substance location and end-of-life data often do not exist at all. No current process generates them in most plants, so this is new data work rather than a migration exercise, and it needs a budget of its own.

How to prepare, in five steps

Preparation is an audit rather than a rebuild. Start with scope: the regulation applies to any physical goods placed on the market or put into service, including components and intermediate products (Article 1(2)), with narrow exemptions for food, feed, medicines, live organisms and vehicles covered by other law.

Then build the five essentials: the regulation names.

• A persistent unique product identifier for every product, connected through a data carrier on the product, its packaging or its documentation (Article 10(1)(a) and (b)). This is the anchor everything else attaches to.
• Data at the level the delegated act sets, whether model, batch or item (Article 9(2)(d)). Unit-level serialisation is the slowest thing to retrofit, so start it early if your records stop at SKU.
• The underlying attributes in machine-readable, open-standard form, since Article 10(1)(d) rules out PDFs and closed formats. Plan for document-to-field conversion work.
• An access model deciding who reads and who updates each field (Article 9(2)(f) and (g)). Customers, recyclers and regulators each get a different slice of the record.
• A plan to keep the record accurate (Article 9(1)) and available for at least the expected lifetime of the product (Article 9(2)(i)). This is data governance, not a project with an end date.

When the rules reach your product group

There is no single digital product passport deadline, and treating one date as the deadline is the most common planning mistake. The regulation is framework law: it creates the passport, but the obligation for any product arrives through a product-specific delegated act. The European Commission set the running order in its ESPR and Energy Labelling Working Plan 2025-2030, adopted 16 April 2025.

Read those as the years the Commission expects to adopt rules, not the day a passport goes live. The obligation follows each delegated act after a transition period, so a 2027 adoption year still means the data work starts now.

One passport already sits in law with a hard date. Under the EU Batteries Regulation (Regulation (EU) 2023/1542, Article 77), every LMT battery, industrial battery above 2 kWh and electric-vehicle battery placed on the market from 18 February 2027 must carry an electronic battery passport. It also demonstrates the tiered-access model the framework generalises: some data public, some for regulators, some for repairers and recyclers.

Turning siloed records into a passport-ready dataset

By this point the shape of the work is clear. The attributes are knowable, but they sit in silos, in the wrong format, and often above the unit level a passport can demand. Closing that gap is a data-infrastructure job rather than a compliance-paperwork one.

What it needs is a system that assigns a persistent identifier at the granularity the delegated act will ask for, links units to cases and pallets, records events as the product moves, and pushes all of it into the ERP where the rest of your product data lives. We built Acviss Origin for that layer, serialising at unit, case and pallet level with parent-child aggregation and integration into SAP, Oracle and Microsoft Dynamics 365.

The identifier also has to be trustworthy, which is a separate problem from being unique. A plain copyable code can be photographed and reprinted, which undermines the single identifier the whole passport hangs from. A unit-level identity that is difficult to replicate keeps the anchor sound.

No traceability platform is a compliance guarantee, and it is worth being clear about the limit. Serialisation captures identity, granularity and chain of custody. It does not produce your carbon footprint, your substance concentrations or your end-of-life instructions, and that data still comes from your design, sustainability and supplier teams.

FAQ

Who inside the company should own the passport project?

It does not sit cleanly in any one function, which is why it stalls. Compliance owns the obligation, IT owns the data plumbing, and sustainability owns the fields that do not exist yet. The arrangement that works is a single named owner with authority across all three, usually in operations or product management, with the others contributing. Handing it to compliance alone tends to produce a gap analysis rather than a dataset.

Does this apply if you only sell into the EU through a distributor or importer?

The obligation attaches to the product placed on the EU market, so it reaches your goods even when someone else places them there. In practice the importer will pass the requirement to you contractually, because they cannot generate your bill of materials or your footprint data themselves. Assume you will be asked for it, and that your commercial position is stronger if you have it before they ask.

What happens if the data in a passport turns out to be wrong?

The regulation requires the record to be accurate, complete and up to date, and enforcement sits with national market surveillance authorities under the usual ESPR mechanisms rather than with a passport-specific penalty regime. The commercial risk arrives sooner than the regulatory one: a buyer, recycler or auditor who finds a wrong figure will ask what else is wrong. Build a correction process and a version history from the start rather than after the first error.

Can you reuse your GS1 barcode work for the passport?

A good deal of it, yes, and that is the most useful overlap in this whole area. The GTIN, the data carrier and the move to 2D codes carrying a GS1 Digital Link URI all serve both purposes, so a plant already migrating its barcodes is part way into its passport work without having planned it. What GS1 work does not give you is the environmental and substance data, which no barcode project touches.

How far back does this reach for products already on the market?

The obligation attaches to products placed on the market after the relevant delegated act applies, so goods already sold are generally outside it. The practical complication is products with long production runs and long lives, where the same model crosses the boundary. Decide early whether you serialise the whole line or only post-cutoff output, bec

Written by

Arun Krishnan

Arun is a storyteller at heart, with a knack for making complex ideas click. He works at the intersection of technology, content, and communication, turning technical jargon into stories people actually want to read.