Digital Product Passport (DPP) : the new indicator of your product information system’s maturity

The QR code is the visible part of the Digital Product Passport. For IT departments, the real challenge lies behind it: the ability to identify, govern, secure and maintain product data throughout its entire lifecycle.

For many years, product information was primarily designed to support commercial activities: populating an e-commerce product page, producing a catalogue, sending product specifications to a distributor or supporting the launch of a new range.

The Digital Product Passport, or DPP, significantly broadens this scope. Businesses must do more than publish attractive and consistent information. They must be able to provide information that is structured, verifiable, contextualised and accessible to the different stakeholders within their ecosystem.

For IT departments, the subject therefore extends far beyond the creation of a QR code, an additional web page or an application developed specifically to meet an initial regulatory deadline.

The DPP is not a digital document

The term “product passport” may suggest a static document containing regulatory information.

However, this interpretation is too restrictive.

A product changes over time. Its components may change, its suppliers may be replaced, its certificates renewed and regulatory requirements updated. Information relating to maintenance, repairability or recycling may also be added after the product has been placed on the market.

The DPP must therefore be considered a living information service, associated with a product, model, batch or individual unit, depending on the applicable requirements.

The European Union’s Ecodesign for Sustainable Products Regulation (ESPR) establishes the general framework for the Digital Product Passport. In particular, it provides that the passport must be linked to a persistent unique identifier through a data carrier, and that information must be accessible according to access rights adapted to different stakeholders.

The 2D code is the point of entry.
The passport is the organised system that sits behind it.

For IT departments, the real issue is building a trusted architecture

The data required for a DPP is generally distributed across multiple systems.

Product identity may be managed in a PLM, ERP or MDM system. Commercial product characteristics may be stored in a PIM. Images, instructions, certificates and supporting evidence may be held in a DAM or document management system. Composition data may come from suppliers. Production information may reside in a MES or PLM system. Environmental data may be calculated using a specialist solution.

An architecture based on manual exports, an isolated database or a bespoke application developed to generate the first DPPs may be sufficient for a pilot. However, it becomes increasingly difficult to maintain as the number of product references, suppliers, countries and regulatory requirements grows.

Bespoke development can then become a source of significant technical debt. The required attributes, European standards, data models and access mechanisms will evolve. Each change may require additional development, testing cycles and a long-term dependency on a small number of internal specialists or external providers.

The role of the IT department is therefore to build a configurable and scalable architecture in which each system retains a clearly defined responsibility.

Depending on the organisation:

• the MDM governs core identifiers and reference data;
• the PLM manages product design, composition and development data;
• the PIM consolidates, enriches and contextualises information for different uses;
• the DAM or document management system manages media, instructions, certificates and supporting evidence;
• workflows organise approvals and responsibilities;
• APIs and connectors make information available to authorised services;
• a delivery layer presents the right data to the right stakeholder.

Within this architecture, the PIM does not replace the ERP, PLM or MDM. It plays an orchestration role: consolidating information from these environments, enriching it and preparing it for the different uses of the Digital Product Passport.

The DPP then becomes the result of a controlled architecture, rather than an additional data silo. It is also a practical use case for a Best-of-Breed strategy: assigning each function to the system best suited to perform it, rather than artificially extending the ERP into areas for which it was not designed.

Turning available data into usable data

Many businesses already hold a significant proportion of the information that could be used to populate their future Digital Product Passports.

However, the presence of information within the information system does not guarantee that it can be used immediately.

To be used within a DPP, data must be capable of being:

• associated with the correct identifier;
• expressed using a standardised unit;
• linked to a known source;
• accompanied by a validity date;
• checked and approved;
• assigned to a precise level: range, product reference, batch or individual unit;
• transmitted unambiguously to a third-party system.

The DPP therefore highlights a fundamental distinction between the mere availability of information and its ability to be substantiated, understood and reused.

This distinction is particularly important for data received from suppliers. In many sectors, a significant proportion of technical, environmental or composition data is located upstream in the value chain.

The effectiveness of the system therefore depends as much on the quality of the internal data repository as it does on the ability to industrialise external data collection.

Supplier portals, structured exchange formats, completeness rules, automated controls and follow-up processes become essential. Files occasionally sent by email quickly reach their limits when the system needs to scale.

The DPP requires long-term governance

A Digital Product Passport commits the business well beyond the initial publication of the product.

The organisation must be able to manage:

• successive versions of information;
• changes to components or suppliers;
• certificate validity;
• corrections made after publication;
• information relating to products that have already been placed on the market;
• continued access for the required period.

This time dimension is fundamental.

A commercial product page can be removed from a website when the product is no longer available. A DPP, by contrast, may need to remain accessible to support maintenance, repair, reuse, disassembly or recycling.

The data lifecycle may therefore extend beyond the commercial lifecycle of the product.

For IT departments, this means defining explicit policies for versioning, archiving, availability and reversibility. Reliance on a temporary URL, an isolated application, difficult-to-maintain custom code or a provider without an exit strategy represents an architectural risk.

Persistence is not simply a technical detail. It forms part of the promise of trust underpinning the DPP.

Differentiated access for different stakeholders

The Digital Product Passport is intended for several categories of user: consumers, distributors, repairers, recyclers, market surveillance authorities, customs services and industrial partners.

Their needs are not identical.

A consumer may be looking for information on care, durability or repairability. A repairer must be able to identify spare parts and consult technical instructions. A recycler needs to understand the composition of the product and the relevant treatment instructions. An authority must be able to verify compliance and consult the associated evidence.

Designing a DPP does not therefore mean making all data publicly available.

It means organising different levels of access, distinguishing between open and restricted information, and protecting trade secrets, personal information and sensitive supply-chain data.

The DPP consequently becomes a combined matter of data governance, Identity and Access Management and cybersecurity.

IT departments must anticipate:

• the authentication of certain users;
• the management of roles and permissions;
• the traceability of consultations and changes;
• API security;
• protection against data alteration;
• service availability;
• incident and correction management.

Accurate information that is unavailable, inaccessible to the appropriate stakeholder or exposed without adequate controls does not fulfil the objectives of the Digital Product Passport.

Interoperability as a condition for scalability

The DPP forms part of complex, international and multi-stakeholder value chains.

No information system will be able to operate sustainably as a closed environment. Data will need to be understood and used by partners, platforms, authorities and providers working with different technologies.

This interoperability does not depend solely on the existence of an API.

It requires:

• unique and persistent identifiers;
• documented data models;
• shared vocabularies;
• standardised units and classifications;
• open exchange formats;
• versioning rules;
• semantics that can be understood by receiving systems.

Data identification and sharing standards play a critical role. GS1 notably emphasises the importance of persistent and interoperable identifiers, compatible with web-based access mechanisms such as transitioning to 2D QR codes (GS1 Digital Link).

The question is therefore not simply:
“Can we publish our DPP?”

It is also:
“Will other systems be able to interpret it without requiring bespoke development for every exchange?”

This second question determines whether the system can genuinely scale.

It also supports the case for a modular, Best-of-Breed architecture based on configurable and interoperable solutions. The DPP must not become a reason to concentrate additional functions within a rigid ERP or to multiply bespoke interfaces that are difficult to evolve.

Should businesses wait until all requirements have been finalised?

The detailed DPP requirements will be defined progressively through regulations applying to different product categories.

This evolving framework may create the impression that businesses should wait before starting a project.

However, most of the underlying structural work does not depend on the final list of regulatory attributes.

A business can already:

• map the systems containing its product information;
• identify the owner of each data element;
• audit data quality and traceability for critical information;
• stabilise its product, operator and site identifiers;
• structure the collection of supplier data;
• implement validation and control rules;
• organise the management of supporting documents;
• test the publication of a versioned dataset;
• define an access and permissions architecture;
• select a product family for a pilot.

Starting now does not mean prematurely fixing the model.

It means building a sufficiently flexible foundation to accommodate new attributes, rules and use cases without having to redesign the entire architecture.

This flexibility depends less on the amount of code produced than on the ability of the selected tools to be configured, integrated and updated. A PIM, MDM or specialist market solution can evolve its models and workflows. A bespoke application coded around current requirements may require continuous redevelopment.

How to establish a pragmatic DPP roadmap

A progressive approach helps avoid two opposing pitfalls: treating the DPP as a compliance project managed at the edge of the information system, or immediately launching a large-scale transformation that is lengthy and difficult to prioritise.

A balanced roadmap can be organised around four stages.

1. Assess the maturity of the product data foundation

The first stage involves understanding where the data is held, how it circulates, who is responsible for it and at what level of granularity it is managed.

This analysis makes it possible to identify duplicates, breaks in traceability, dependencies on files, bespoke developments and data without a clearly designated owner.

2. Build an extensible DPP model

The model must distinguish between identity data, technical characteristics, regulatory information, environmental data, supporting documents and traceability information.

It must also support several levels of granularity: model, product reference, batch or individual unit.

The objective is not to code a definitive structure, but to rely on configurable models capable of progressively accommodating new attributes and rules.

3. Industrialise data flows and controls

Data collection, validation and publication must be integrated into repeatable workflows.

Format, consistency, completeness and validity controls should be automated wherever possible. Anomalies must be assigned to the appropriate owner and tracked until they are resolved.

This industrialisation requires systems to work together, rather than attempting to centralise every function within a single tool. The ERP, PLM, PIM, MDM and specialist solutions must each perform their respective responsibilities.

4. Test the system from end to end

A relevant pilot must do more than demonstrate that a QR code opens a web page.

It must confirm that the business can:

• trace each item of information back to its source;
• update data without creating a break in continuity;
• manage several access profiles;
• preserve historical information;
• expose information through APIs;
• update content without changing the identifier;
• guarantee long-term access;
• monitor errors and service availability.

The pilot must also measure the effort required to integrate a new requirement. When every change results in a code modification, a new interface or a major intervention within the ERP, the architecture is not yet sufficiently adaptable.

This end-to-end test is what makes it possible to evaluate the organisation’s true level of maturity.

From regulatory project to strategic asset

The DPP is often presented as an additional regulatory constraint.

However, it can become an accelerator for transformation.

By requiring businesses to identify, structure and document their products more effectively, it can improve numerous existing processes: supplier onboarding, managing regulatory compliance and EU product warranties, after-sales service, maintenance, second-life activities, recycling, anti-counterfeiting measures and communication with consumers.

The same data foundation can support several use cases, provided it has been designed as a platform rather than as a one-off response.

For IT departments, the objective is not to create an architecture dedicated solely to the Digital Product Passport. It is to make the DPP a new, governed and secure view of a product information system that is already capable of supporting the entire business.

The project can therefore become a practical opportunity to validate a Best-of-Breed strategy: retaining the ERP in its transactional role, the PLM for product design management, and the PIM or MDM for information structuring and governance, while organising their collaboration through standardised data flows.

The DPP makes information system quality visible

In the future, a simple scan will provide consumers, repairers or regulators with access to some of the data produced by the business.

This apparent simplicity will rely on a demanding architecture: reliable identifiers, structured data, supplier contributions, documentary evidence, governance rules, secure APIs and lifecycle management.

The DPP will therefore make visible something that has until now remained largely hidden: the maturity of the product information system.

The best-prepared businesses will not necessarily be those that create the first passport.

They will be those that build an architecture capable of producing and maintaining thousands of passports across several markets, for different uses and throughout the entire product lifecycle, without accumulating technical debt with every regulatory change.

We believe that sustainable compliance must be built at the heart of the information system, rather than at its periphery.

It relies on a unified product data repository, clear governance, configurable tools and data that can circulate reliably between complementary systems, markets and stakeholders.

The DPP is not the final destination of this transformation.
It is one of its first indicators.

Your data. Your way. Your Growth.