Where does your product data live? The check-up that determines the success of your Digital Product Passport

Why this question comes before everything else

When a company begins working on a Digital Product Passport (DPP), the temptation is to start with the technology: which platform to choose, which QR code to print, or which service provider to engage. In reality, the decisive question is something else—and far more concrete: how is product data organized today?

A passport does not create information out of thin air. It is a digital container that presents—in a structured and interoperable way—data that the company must already possess, such as material composition, origin, certifications, repair instructions, and end-of-life information. If this data is fragmented, incomplete, or difficult to retrieve, the DPP will inherit those same issues—multiplied across every product and every batch placed on the market.

In the DPP Designer guide, this topic appears within the section dedicated to data: it follows the question regarding the number of suppliers involved and precedes the one concerning information already on hand. This sequence is intentional: first, you determine who provides the data; next, where it is stored; and finally, what is already available.

---

The Regulatory Framework: A Decentralized Passport

The key reference is Regulation (EU) 2024/1781, known as the ESPR (Ecodesign for Sustainable Products Regulation). Two principles within this regulation have direct implications for how data is organized:

1. Open and interoperable standards. The passport must be readable and exchangeable across different systems, without relying on proprietary formats.
2. Decentralized architecture. Passport data remains with the economic operator—or with the DPP service provider they have appointed. The European Central Registry, which will be operational from July 2026, does not store the passports themselves; instead, it indexes their identifiers, making them traceable.

In practical terms, the European Union will not ask you to "upload" data to a common platform; rather, it will require you to maintain the data yourself—ensuring it remains reliable, up-to-date, and accessible throughout the entire lifespan of the product. This is why the internal organization of your data is the essential starting point.

Technical standards have arrived

In 2026, the joint technical committee CEN-CENELEC JTC 24 published the first European standards to make the Digital Product Passport (DPP) operational, developed at the request of the European Commission (Standardisation Request M/604). The package covers:

Standard	Scope
EN 18216	Data exchange protocols
EN 18219	Unique identifiers
EN 18220	Data carriers (e.g., QR codes, RFID)
EN 18221	Data storage, preservation, and persistence
EN 18222	APIs for lifecycle management and searchability
EN 18223	System interoperability

For those tasked with organizing data, the most relevant standards are EN 18221 (persistence: data must remain available over time) and EN 18223 (interoperability: different systems must be able to communicate with one another). Both assume that the company knows exactly where every piece of information is located.

Key deadlines to keep in mind

• July 2026 – Launch of the European DPP Registry. - February 18, 2027 – First binding deadline: the battery passport, as stipulated by Regulation (EU) 2023/1542.
• From 2026 onwards – Sector-specific delegated acts, in accordance with the ESPR (Ecodesign for Sustainable Products Regulation) 2025–2030 work plan: starting with iron and steel, followed by textiles, tires, aluminum, furniture, mattresses, and other product groups.

Each delegated act will define specific data fields and timelines, with an indicative transition period of approximately 18 months. Eighteen months may seem like a long time, but it is not—especially when the data must first be located, cleaned, and linked.

---

The three possible scenarios

1. Data centralized in a single system

How ​​it works: There is a primary reference system—typically a PIM (Product Information Management) or an ERP—that houses all product specifications. Anyone looking for information knows exactly where to find it.

Strengths

• A "single source of truth" already exists.
• The passport can be populated via one main integration, rather than many separate ones.
• Responsibilities for data updates are generally clear.

Risks to consider

• Centralized does not mean complete. A PIM designed for e-commerce may contain descriptions, images, and prices, but often lacks details on material composition, environmental footprint, substances of concern, or disassembly instructions.
• Insufficient granularity. Many systems manage data at the model level, whereas some passports will require information at the batch or individual unit level. - Data from external suppliers. Even the most well-organized system depends on what is received from the supply chain.

Operational Priorities

The guidance here is clear: distributed data requires a common data model before it can feed into the passport. In practical terms, this means:

1. Defining a common data model that describes the entities (product, component, material, batch, supplier, certificate) and the relationships between them.
2. Establishing a reconciliation key—a unique identifier shared across systems—consistent with the requirements of the EN 18219 standard.
3. Mapping each field in the passport to the system that "owns" it, thereby avoiding duplication.
4. Choosing an integration architecture: either an intermediate layer (such as middleware or a data hub) to aggregate the data, or direct integrations between the various systems and the DPP (Digital Product Passport) platform.
5. Transforming documents into data: extracting key information (issuing body, expiration date, scope) from certificates and converting it into a structured format.

3. Unorganized Data

The current state: There is no reference system. Information is scattered across Excel files saved on individual computers, emails, personal folders, and—most significantly—within people's own memories.

This is a common situation in small businesses and many companies throughout the supply chain. It is important to state this without judgment: for years, there was no mandate requiring such information to be structured.

Risks that should not be underestimated

• Dependence on individuals. If someone who holds key data changes roles or leaves the company, that information is lost.
• Inability to ensure persistence. The ESPR (Ecodesign for Sustainable Products Regulation) and the EN 18221 standard require data to remain available over time—potentially for years after a product has been placed on the market.
• Errors and inconsistencies arising between different files that describe the same product. - Difficulty in responding to customers. Downstream companies that need to create their own product passports will request structured data from their suppliers.

Operational priorities

1. Inventory existing data: identify which files exist, where they are located, and who is responsible for updating them.
2. Select a reference system—even a simple one—provided it is unified and shared across the organization. Some DPP (Digital Product Passport) solutions include a basic product repository.
3. Start with a limited scope: focus on a single product line or family, rather than the entire catalog.
4. Establish basic governance rules: define who creates, validates, and updates the data.

While this approach may take more time, it offers a distinct advantage: you can design your data organization with the product passport in mind from the very beginning, rather than having to retrofit systems originally built for other purposes.

---

Quick Comparison

	Centralized	Distributed	Unorganized
Typical example	PIM or ERP containing all product records	PLM + MES + shared folders	Local Excel files, emails
Integration effort	Low	Medium-to-high	High (a system must be built first)
Main risk	Missing fields	Inconsistent identifiers	Loss of data and knowledge
First step	Gap analysis of data fields	Common data model	Inventory and selection of a reference system

---

Checklist: Five questions to ask yourself today

1. Is there a unique product identifier recognized by all company systems?
2. For every piece of information required by the product passport, is it clear which system or individual is responsible for it?
3. Is the data managed at the required level of detail (e.g., by model, batch, or individual item)? 4. Does the information from suppliers arrive in a structured format, or as documents that require interpretation?
4. Can we ensure that the data remains accessible and up-to-date throughout the entire product lifecycle?

If the answer to two or more of these questions is "no" or "I don't know," then data organization is the first area that needs to be addressed—even before selecting a platform.

---

Conclusion

The Digital Product Passport is often framed as a technological project, but it is, first and foremost, a data project. The decentralized architecture mandated by the ESPR places the responsibility for storing and maintaining information squarely on companies: those starting with centralized data will primarily need to supplement it; those with distributed data will need to unify it via a common model; and those who have not yet organized their data will need to build the necessary foundation.

In all three cases, answering the question "How is our data organized today?" with complete honesty is the fastest way to estimate the timelines, costs, and priorities for your journey toward the DPP.