Can a PIM host the digital product passport?

A PIM can supply much of the passport content, but hosting also requires persistent URLs, access control, long-term availability and a back-up copy with a third-party DPP service provider. Many organisations use a dedicated passport layer or service provider for hosting.

Which identifier should a DPP use?

The identifier must meet the delegated act and the harmonised standard on unique identifiers (EN 18219). GS1 identifiers such as GTIN with batch or serial number, expressed through GS1 Digital Link, are one widely used option.

What does the EU DPP registry store?

The registry stores unique identifiers and the information needed to locate and verify passports. It does not store the full passport content.

DPP Data Architecture: Identifiers, Carriers, Hosting, Access

DPP data architecture is the combination of systems, identifiers, data carriers, hosting and access controls that produces a compliant digital product passport and keeps it available for its required lifetime. It typically has five layers: source systems, a passport data layer, unique identifiers with data carriers, hosting with access rights, and registration in the EU DPP registry set up under the Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781).

What are the layers of a DPP architecture?

Each layer has a distinct job and usually a distinct owner. The table shows a common reference model.

Layer	Purpose	Typical systems
Source systems	Create and approve product facts	PLM, ERP, PIM, LCA tools, compliance and supplier portals
Passport data layer	Assemble passport content per product group schema	PIM, PXM suite, dedicated DPP platform
Identifier and carrier	Link the physical product to its passport	Identifier service, label and print systems
Hosting and access	Serve the passport, apply access rights, keep back-ups	DPP service provider or own hosting
Registry	Register identifiers and locations with the EU	EU DPP registry via interface or API

Separating assembly from hosting keeps source systems free to change while passport URLs and content remain stable.

Which data comes from which system?

Passport content draws on several systems, so attribute ownership must be explicit. A typical split:

PIM: product identity, classification, multilingual names and descriptions, images, user and safety instructions, links to documents.
PLM and compliance tools: material composition, substances of concern, repair and disassembly information, test evidence; see PLM to PIM handoff.
ERP and manufacturing systems: batch and serial numbers, production site and date.
LCA tools: carbon and environmental footprint values with method references.
Supplier portals: recycled content certificates and origin declarations.

Ownership and approval rules for each attribute belong in the governance model described in product data governance.

How do identifiers and data carriers work?

The identifier links a physical product to its passport, and the data carrier makes that identifier readable. The delegated act for each product group sets whether the passport applies at model, batch or item level. Item level gives the most detail but multiplies data volumes and requires serialisation in production.

In July 2026 the Commission cited six harmonised standards developed by CEN and CENELEC in the Official Journal:

EN 18216, data exchange protocols;
EN 18219, unique identifiers;
EN 18220, data carriers;
EN 18221, data storage, archiving and persistence;
EN 18222, application programming interfaces for passport life cycle management and searchability;
EN 18223, system interoperability.

Two further standards on access rights were still drafts as of October 2026. Many organisations plan to use GS1 identifiers expressed through GS1 Digital Link, which allows one QR code to resolve to the passport and other content; see GS1 GDSN explained.

How are hosting, access and the registry handled?

The economic operator hosts the passport, directly or through a DPP service provider, and ESPR requires a back-up copy held by a third-party DPP service provider. Access rights separate public data from information reserved for authorities, repairers or recyclers, as specified per delegated act.

The EU DPP registry went live on 20 July 2026. Commission Implementing Regulation (EU) 2026/1778, adopted on 16 July 2026 and in force since 6 August 2026, governs operator verification, registration data and access. The registry stores identifiers and the information needed to find passports, while operators keep the content. Customs authorities use the registered identifier to check imported products.

API design follows the same principles as headless commerce product APIs: versioned schemas, stable endpoints and clear separation between public and restricted data.

What are the main design decisions?

Five decisions shape most DPP programmes:

Granularity: model, batch or item, per product group.
Build or buy: own hosting or a DPP service provider.
Schema management: one configurable passport schema per delegated act, versioned as acts change.
Persistence: availability for the full period required, including after discontinuation or insolvency.
Change control: which source changes trigger a new passport version, and how history is kept.

Battery passports under Regulation (EU) 2023/1542 apply from 18 February 2027 and are the first live test of these decisions.

Practical next steps

Map passport content for the first relevant product group to source systems and owners.
Choose identifier and carrier standards in line with EN 18219 and EN 18220.
Decide on hosting and test registration in the registry environment.
Build passport assembly as an API-driven service fed by PIM and PLM, with versioning and audit trails.

Platforms with published DPP features are profiled in the vendor directory.