A company should be able to change its Digital Product Passport provider without rebuilding every passport or replacing the data carriers already attached to its products.
The Ecodesign for Sustainable Products Regulation requires DPP data to be transferable through an open, interoperable data exchange network without vendor lock-in.
But what needs to remain portable for a company to move its Digital Product Passports to another system without disrupting access, data integrity or continuity?
DPP data portability is the ability to transfer product passport information from one system or provider to another without losing its structure, meaning or connection with the physical product.
Vendor lock-in occurs when a company cannot practically move its data or continue operating its passports without remaining dependent on a particular provider.
Both terms are also defined in Renoon’s Digital Product Passport glossary.
A portable DPP should retain:
The objective is not simply to recover the content displayed to consumers. It is to preserve a usable product record that another system can interpret, manage and update.
Data portability is an essential requirement under Article 10 of the ESPR. DPP data must be based on open standards, use interoperable formats and be transferable through an open, interoperable data exchange network without vendor lock-in.
The main technical reference supporting this requirement is EN 18216:2026 – Digital Product Passport – Data exchange protocols. It specifies the protocols and formats that allow DPP information to be exchanged securely between different systems.
It works alongside
The references to these harmonised standards have been published in the Official Journal of the European Union. Following them provides a presumption of conformity with the ESPR requirements they cover, although other technical approaches may also demonstrate compliance.
Using standard protocols and formats, however, does not automatically make a complete Digital Product Passport portable. Portability also depends on how identifiers, data relationships, evidence, permissions and system connections are implemented.
For a broader explanation of the European technical framework, read the dedicated article.
A spreadsheet can be useful for transferring individual fields, but it may not represent the complete structure of a Digital Product Passport.
For example, an export may contain a material name without preserving:
Documents, supplier records, lifecycle events and relationships between datasets may also be stored separately.
Portability therefore depends on transferring both the data and the context required to interpret it. Before changing providers, companies should understand which information can be exported, in which format and whether another system can import it without extensive manual reconstruction.
The data carrier attached to a product connects it to a persistent unique product identifier. That connection should continue to function even if the technology used to store or publish the passport changes.
Changing providers should not automatically require a company to replace every QR code already applied to products. Whether existing data carriers can be retained depends on how the identifier and its resolution mechanism were configured.
Migration becomes more difficult when:
Companies should therefore establish from the beginning who controls the identifiers, domains and resolution rules used to connect physical products with their passports.
This is particularly important because the ESPR requires each DPP to remain accessible for at least the expected lifetime of the product. For textiles, a May 2026 external study prepared for the JRC uses ten years after the product is placed on the market as a reference, but the final requirement will be defined in the delegated act.
Under the ESPR, the relevant economic operator remains responsible for ensuring that the required Digital Product Passport is available and that the relevant identifiers are registered. The complete passport data is stored in a decentralised manner by the economic operator or by a DPP service provider acting on its behalf.
The EU DPP Registry does not replace this infrastructure or store the complete passport. It acts as an indexing service and stores identifiers and the registration information required by the applicable legislation.
Selecting an external provider therefore does not transfer the company’s regulatory responsibility. The economic operator must be able to maintain access to the information and ensure that passports remain available for the period established by the applicable rules.
The ESPR also requires a backup copy to be made available through a DPP service provider and provides for passport availability even if the responsible economic operator becomes insolvent, is liquidated or ceases operating in the EU.
The European Commission is also preparing a delegated act that will define specific requirements for DPP service providers and may introduce a conformity assessment or certification scheme. Until it is adopted, the detailed provider-specific obligations are not yet final.
Portability should be assessed before implementation, not only when a company decides to migrate.
Companies can ask prospective providers:
These questions should cover both the technical architecture and the commercial agreement. A system may support open formats while still making migration difficult through contractual restrictions, inaccessible infrastructure or incomplete exports.
The CIRPASS-2 OpenDPP Catalogue brings together open-source resources intended to support more interoperable Digital Product Passport implementations.
One example is the Open DPP Packager, which packages passport records into inspectable files containing structured documents, relationships, events, resources and integrity information. Its purpose is to make a DPP handover readable and checkable outside the system that created it.
The tool does not host passports, verify claims or certify regulatory compliance. It nevertheless illustrates an important principle: a portable passport needs to carry its structure and relationships, not only a copy of the visible data.
Changing DPP providers should be treated as a controlled system migration, not as the recreation of a collection of webpages.
Companies need to preserve the connection between physical products, identifiers and structured records while maintaining access, evidence and update processes. The earlier these requirements are defined, the easier it becomes to change technology, integrate new systems or respond to future regulatory requirements.
Renoon supports companies in structuring Digital Product Passport data, connecting existing systems and establishing processes that preserve data control, interoperability and continuity over time.
Speak with our team about building a scalable Digital Product Passport infrastructure.
.png)
.png)
.avif)
.png)
