Digital Product Passport: What It Changes for Product Data

A QR code on a package is easy to see. The data architecture behind it is not. That may explain why the Digital Product Passport is still frequently reduced to its access method. For a company managing thousands of SKUs across several information systems, however, generating a scannable code is not the main challenge.

The harder questions are what information sits behind the code, where that information comes from, whether it can be trusted, who may change it, and how to prevent conflicting versions from circulating through the ERP, PIM, supplier databases, internal files, and store-facing tools.

The Digital Product Passport is not the QR code

The EU Ecodesign for Sustainable Products Regulation, known as the ESPR, defines a Digital Product Passport as a set of data specific to a product that can be accessed electronically through a data carrier.

That carrier may be a two-dimensional symbol such as a QR code, but three separate layers matter: the physical carrier that is scanned, the identifier linking the product to its passport, and the information contained in the passport itself.

This distinction changes how the project should be approached. Printing or installing an access carrier is a relatively defined technical task. Maintaining trustworthy product information over time is a data governance challenge.

A phased rollout, not one identical requirement for every product

Another misconception is that every product sold in Europe must already carry a DPP.

The system is designed for a phased rollout. Required information, passport granularity, the data carrier, access rights, and update responsibilities depend on the product group and the regulatory measures that apply to it.

There is no single DPP template that a company can apply unchanged across its entire catalog. The European Commission provides an indicative sector-by-sector timeline, while noting that implementation depends on the adoption of the corresponding requirements.

One major development is already in place: the European Digital Product Passport registry has been operational since July 20, 2026, together with a testing environment. The registry is not a single European database containing every piece of product information. Product data remains decentralized; the registry stores unique identifiers and the metadata needed for the system to operate.

This architecture reinforces a central point: the DPP does not replace a company’s information systems. It has to work with them.

The question the DPP brings back into focus: which data is correct?

This is where the issue becomes tangible for a retailer or store network. The same information may already exist in several places.

Consider a product whose composition changes. The manufacturer supplies an updated value. The PIM is current, but an internal export still contains the previous version. Another database holds a description edited several months earlier. The ERP has the correct product reference, but not necessarily the same level of detail.

All of these values may be technically accessible. That still leaves the most important question unanswered: which one is authoritative?

The table is not meant to declare a winner between the ERP and PIM. In practice, the authoritative source may differ by data element. Commercial references may belong to one system, composition data to another, and translations to a third.

Governance makes that arrangement explicit instead of leaving tools and users to resolve conflicts case by case.

Reliable data must remain reliable as it moves

Identifying the right source is not enough. Data must retain its meaning as it moves between systems.

Two applications may use different labels for the same attribute, apply different units, or support different levels of granularity. Information that is accurate in its source system can become ambiguous after transformation, export, or reimport.

This is why data interoperability is one of the DPP’s technical foundations. The regulation calls for structured data and, where applicable, information that is machine-readable and transferable through interoperable formats.

Organizations therefore need to look beyond technical connectors. Field mappings, units, precedence rules, versions, correction responsibilities, and synchronization mechanisms also need to be documented.

Store networks already face this problem

For retailers, this is not an entirely new issue. The same problems already arise when product information feeds multiple channels and formats.

An incorrect reference, outdated price, old description, or poorly imported attribute may be reused by an ecommerce platform, internal application, promotional sign, or in-store screen. The initial error happens once. Its consequences multiply each time another system reuses it.

This pattern is familiar in in-store communication. Toucan®, for example, can use catalogs, product databases, and other business sources to create store communication materials. When trustworthy data enters the workflow, automation saves time and improves consistency. When upstream data is wrong, automation can distribute the mistake more efficiently.

Toucan® is not a Digital Product Passport creation or management system, and it is not intended to provide DPP compliance. It simply illustrates a principle store networks already know: the quality of the final communication depends directly on the quality of the data it uses.

This is also why the issue extends beyond compliance and technical teams. Communications, marketing, product, ecommerce, data, and IT may use the same information while viewing it through very different operational lenses.

What companies can prepare now

Sector-specific requirements are not all identical or final. Companies can still prepare the groundwork, and several steps are useful regardless of the DPP’s eventual scope for a particular product group.

This work remains valuable even if the regulatory scope changes. Better product data management already improves ecommerce, internal tools, catalogs, in-store communication, and many exchanges with partners.

Treat the DPP as a data project

The Digital Product Passport makes information visible to consumers and other supply-chain participants even though that information may originate across several systems. Because the access point is so visible, the project can appear to begin at the end of the chain, with the QR code.

In practice, the opposite is closer to the truth. The easier information becomes to access, the stronger the organization behind it needs to be.

Companies need to answer questions that are more fundamental than how to create a passport: Where does the data live? Who owns it? Which exact product does it describe? How is a correction propagated? What happens when two systems disagree?

The DPP places these questions in a new regulatory context, but they already affect the entire product ecosystem. For store networks, it is an opportunity to examine the full chain, from data created or received upstream to its use across communication channels.