Does a Digital Product Passport Require Supply Chain Traceability?

Traceability is an objective, not one universal data checklist

ESPR Article 9 gives the passport three broad jobs: make relevant product information accessible to actors along the value chain, help authorities verify compliance and improve traceability of products along the value chain. Recital 32 goes further in policy language and says the DPP is expected to enhance end-to-end traceability.

Those statements explain why traceability matters. They do not themselves prescribe a universal list of tiers, events or supplier records that every DPP must contain. Article 9 ties the actual passport obligation to the applicable delegated acts and requires those acts to specify the relevant data and implementation details for the product group.

So keep two statements separate:

• A DPP is designed to improve traceability.
• Every DPP requires complete end-to-end supply-chain traceability.

The first is established. The second is not.

What “traceability” can mean in practice

The word is used for several different capabilities:

A business can have a valid reason to invest in traceability capability even where the DPP does not require every tier. The same data may support recalls, due diligence, deforestation controls, chain-of-custody claims, quality investigations or retailer requests. Avoid describing those adjacent requirements as though they were one universal DPP rule.

Product master data is not event data

A DPP needs governed product information. A traceability system may also need events. Those are different information objects.

Product master data answers questions such as:

• what the product is
• which identifiers refer to it
• its composition or specification
• who placed it on the market
• which declarations or evidence support its fields.

Event data answers questions such as:

• what happened
• to which identified object
• at what time
• at which location
• under which business process.

GS1 EPCIS is one established event-data model. It can be useful where event-level traceability is required, but ESPR does not say that every DPP must use EPCIS. See What Do EPCIS Events Add to Product Master Data? for that boundary.

How far upstream does DPP evidence need to go?

There is no single horizontal answer such as “tier 3” or “all the way to raw material”. The answer depends on the fact you are trying to establish and the rule or claim behind it.

If the required field is a manufacturer identifier, the evidence path may be short. If the field is a recycled-content statement, origin assertion or regulated material fact, the evidence may need to reach further upstream because the conclusion depends on supplier or chain-of-custody evidence.

The test:

1. What exact product fact must be established?
2. At what model, batch or item scope must it be true?
3. What source can establish it at that scope?
4. Does the source depend on upstream supplier or facility evidence?
5. Is an event history needed, or is governed master data enough?

For the evidence-depth question, use How Far Back Does Product Evidence Need to Go? and Supplier Evidence.

Delegated acts decide the product-specific requirement

Under ESPR, the product-specific measure is where the horizontal architecture becomes an actual requirement for a product group. So it is risky to buy a “DPP traceability checklist” that treats one industry's practice as universal.

As at 7 September 2026, no ESPR product-specific delegated act had changed this central answer. Product groups are moving through study and rulemaking at different speeds. A Working Plan position or intended adoption date is not itself a final traceability specification.

See What a Delegated Act Decides and DPP Data Requirements: Mandatory, Conditional and Voluntary Information.

DPP traceability is not the same as every adjacent regime

Some businesses already face deeper traceability duties under other legislation or schemes. That does not make those duties generic DPP requirements.

For example, the EU Deforestation Regulation has its own due-diligence and geolocation logic for covered commodities. The UN Transparency Protocol is a separate cross-border product-data framework. Those regimes can create useful context or reusable data, but neither should be presented as the horizontal ESPR DPP rule.

If those are relevant to your product, compare EUDR and EU Digital Product Passport vs UNTP DPP.

What a business should build now

A sensible architecture can stay useful across several regulatory outcomes:

• keep stable product, model, batch and optional item identities
• link each material fact to its source and scope
• keep supplier and facility identities as governed records rather than free text where they matter
• preserve batch relationships where production-run evidence can change
• keep event data separate from product master data but joinable by typed identifiers
• retain unknown or unresolved states rather than fabricating upstream certainty
• add deeper chain-of-custody or event capture where a real legal, evidence or business requirement calls for it.

That is stronger than assuming either extreme: “a DPP means full traceability” or “a DPP has nothing to do with traceability”.

Current maturity

NOW: ESPR establishes the horizontal DPP architecture and improving traceability as an objective.

EMERGING: product-specific measures will determine the actual data and passport requirements for ESPR product groups.

POSSIBLE: a given product rule may require information that depends on deeper supplier, facility, batch or chain-of-custody evidence.

NOT_SUPPORTED: every DPP requires full multi-tier end-to-end traceability, every DPP must use EPCIS or a DPP replaces a traceability system.

Next question

If the answer is not “trace everything”, the next useful question is how far upstream the evidence actually needs to go.

Direct answer

No. The applicable product-specific rules decide which information belongs in the passport and at what granularity.

The distinction is between the product fact, the evidence behind it and the events that may connect it through the chain. Those layers can work together without being the same dataset.

If the terminology itself is getting in the way, see the separate comparison of mapping, visibility, provenance, traceability and chain of custody.

Product facts, evidence and events are three different layers

A useful DPP architecture keeps three things separate:

An event can help bind evidence to the right object, but an event does not make an unsupported product fact true. Equally, a strong document can become unusable downstream if a transformation creates new product identities and the evidence is not bound to them.

GS1 EPCIS is an example of an event-layer standard. It can represent what happened, when, where and why for identified objects. That is useful traceability infrastructure, but not a universal DPP requirement. The deeper architecture question sits with what EPCIS events add to product master data.

Product-specific rules decide the depth

ESPR allows DPP requirements to be set at the granularity appropriate to the product group. So there is no safe horizontal rule saying every future passport must expose raw-material-to-retail events.

One product rule may need a model-level fact. Another may depend on batch evidence. A lifecycle use case may need item-level events. The legal requirement and the operational evidence route have to be checked separately.

“We can technically trace it” is also not the same statement as “the passport must contain it”. Technical capability, voluntary standards and product-specific legal obligations are different maturity levels.

The DPP Registry is not a supply-chain event database

Commission Implementing Regulation (EU) 2026/1778 establishes the DPP Registry and the registration data that must be recorded there. The Registry follows the relevant passport granularity and stores prescribed identifiers and registration information.

It should not be described as an end-to-end database of every manufacturing, logistics or custody event. A business may use separate systems to hold product master data, evidence and event histories, then expose or register only what the applicable DPP rules require.

Where deeper traceability becomes necessary

Deeper traceability becomes operationally important when a downstream fact cannot remain trustworthy without preserving its identity and scope through change.

In a steel service centre, a parent coil can be cut or slit into new saleable descendants. If a downstream claim depends on evidence attached to the parent, the child identity needs a governed binding back to that evidence. Otherwise the certificate may still be genuine but no longer prove which child it applies to.

That is a traceability need created by the evidence relationship. It is not proof that every DPP must publish every event in the same way.

When a chain will not join reliably, see why supply-chain traceability breaks. Due diligence is also a separate legal and operational question: traceability can provide evidence to a due-diligence process without replacing the process itself.

What this means in practice

Before buying or extending a traceability platform, list the facts the product needs, the evidence that supports each fact and the transformations that could break the binding between them. Then decide where event data is needed.

That produces a smaller and more defensible architecture than assuming “DPP traceability” means one continuous public ledger for the whole supply chain.

Sources

• Regulation (EU) 2024/1781, especially Article 9 and Recital 32
  EU law
• European Commission, Digital Product Passport
  European Commission