DPPVendor selectionEU

EU Digital Product Passport Implementation Playbook and Vendor Selection

This playbook helps evaluate DPP platforms, integrators, and data-service providers against the architecture and evidence requirements that matter under ESPR.

The focus is system selection: identifiers, carriers, data model, access control, registry and portal readiness, and verification evidence.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

A DPP vendor should not be selected only because it can host a product page or print a QR code. Under ESPR, the passport depends on a persistent unique product identifier, a data carrier, product-group access rights, storage by the responsible economic operator or a , Registry registration, and evidence that passport data is accurate and up to date. The Commission Registry became operational on 20 July 2026, so vendor demonstrations can now use its production or testing interfaces; public search-portal readiness remains a separate requirement.

Section 1

Start with the DPP architecture the vendor must support

Shortlist vendors only after confirming which parts of the DPP system they will operate. The component map should separate the product identifier, physical data carrier, resolver or link layer, data repository, access-control services, backup or continuity arrangements, and interfaces to enterprise resource planning (ERP), product lifecycle management (PLM), product information management (PIM), supplier data, market-surveillance, and customs workflows.

ESPR uses a decentralised model: detailed passport data remains with the responsible economic operator or its , while the Commission Registry indexes identifiers, registration data, and high-level metadata. A vendor that proposes a closed central database should explain how it avoids vendor lock-in, preserves interoperability, and keeps the economic operator able to export, update, and transfer passport data.

If the vendor will act as the , verify that it is an independent third party authorised by the responsible economic operator. The contract should prevent sale, reuse, or processing of passport data beyond the service unless the economic operator specifically agrees, and it should preserve passport availability and a recoverable backup after insolvency, liquidation, or cessation of activity.

  • Require a component map showing which party controls identifier issuance, resolver configuration, data storage, access policy, backups, and registry submission.
  • Require open export of passport data and metadata so the economic operator can move data to another service provider or backup service.
  • Require the contract to identify the role, permitted processing, backup ownership, restoration tests, termination assistance, data return, deletion rules, and continuity period.
  • Require APIs or data-exchange patterns for ERP, PLM, PIM, supplier portals, conformity documentation, and lifecycle-event updates.
  • Reject proposals that treat the DPP as a static marketing microsite without machine-readable data, access-right handling, or update controls.
Section 2

Identifier and data-carrier criteria

The first vendor gate is identifier discipline. ESPR defines the DPP around a unique product identifier that enables a web link to the passport, with operator and facility identifiers used where relevant. The applicable delegated act will determine the product granularity, so the system must support model, batch, and item-level choices without forcing a redesign.

The data carrier must be physically present on the product, packaging, or accompanying documentation as specified for the product group. Vendor demos should prove that the carrier resolves reliably to the right passport, supports native scanning where needed, and can handle updates to online data without requiring replacement of every physical carrier unless the carrier itself changes.

  • Ask how the platform records the product identifier level: model, batch, item, serialised item, or product-plus-serial combination.
  • Ask whether the vendor supports product, operator, facility, and registration identifiers as distinct fields rather than one overloaded SKU.
  • Test the carrier options against the product surface, packaging constraints, expected product lifetime, scan environment, and consumer access needs.
  • Require a resolver test showing the scanned carrier reaches the correct public data and, for authorised users, the correct restricted links.
Section 3

Data model and interoperability checks

A DPP vendor must show how it will model product information, not just where it will store files. The platform should distinguish regulatory data, supplier-provided attributes, calculated sustainability metrics, certificates, conformity documents, lifecycle events, and links to external records. It should also preserve provenance: who supplied each value, when it was changed, and which method or evidence supports it.

Interoperability is a selection criterion because ESPR expects data transfer through an open interoperable exchange network without vendor lock-in. Ask vendors to demonstrate machine-readable exports, schema versioning, controlled vocabularies, validation rules, and mapping from existing ERP, PLM, PIM, and supplier systems into the passport data model.

  • Require a data dictionary with field name, definition, source system, owner, update rule, access class, and evidence link.
  • Require validation rules for required fields, units of measure, allowed values, product-group applicability, and missing supplier data.
  • Require an export sample in the proposed machine-readable format and a mapping back to the source system records.
  • Require change history for passport values so later corrections do not erase the evidence behind earlier published values.
Section 4

Access-control and portal-readiness checks

The vendor must support different views for consumers, customers, repairers, recyclers, market-surveillance authorities, customs authorities, and other authorised actors. Public DPP data should be easy to access, while restricted data needs role-based access, authentication, and rules for who may introduce, modify, or update passport data.

ESPR also requires a publicly accessible Commission web portal for search and comparison in line with access rights. Because product-group delegated acts and implementation arrangements will add detail, vendors should prove that portal and registry integrations are configurable rather than hard-coded.

  • Require an access-rights matrix by actor, data field, action type, authentication requirement, and audit-log event.
  • Require a consumer scan journey that does not require unnecessary app downloads, accounts, or personal data for public information.
  • Require a restricted-access demo for repairer, recycler, authority, or customs use cases, including failed-authentication behavior.
  • Require a live or test-environment demonstration of Registry enrolment, registration through the secure interface or API, automated validation, unique registration identifier handling, registration updates, and downloadable proof of registration.
  • Keep portal discovery and automated EU customs exchange as separate roadmap items. The Registry is operational, but the public comparison portal and customs interconnection have their own implementation stages.
Section 5

Verification evidence and vendor due diligence package

DPP implementation evidence should prove more than platform configuration. Keep a vendor due diligence package that shows why the selected system can maintain reliable passport data over the product lifecycle and respond to supplier corrections, product changes, authority questions, service-provider failure, and future delegated-act changes.

Require vendors to show how data assertions are verified, signed where appropriate, versioned, backed up, and linked to source evidence. Where a product group later requires particular information, calculation methods, or conformity evidence, the selected system should be able to attach the supporting documents and expose them only to the actors entitled to see them.

  • Vendor architecture record: components, hosting model, resolver design, data repository ownership, backup, export, and continuity plan.
  • Provider-role record: independent-third-party status, written authorisation, processing purpose, agreed secondary uses if any, backup custody, exit obligations, and evidence that data remain available after operator or provider failure.
  • Identifier and carrier record: identifier scheme, granularity, carrier technology, physical placement assumptions, scan tests, and resolver test results.
  • Data-model record: field dictionary, source-system mapping, validation rules, provenance fields, change log, and machine-readable export sample.
  • Access-control record: actor roles, public and restricted fields, authentication method, write permissions, credential handling, and audit logs.
  • Registry record: verified-operator enrolment, interface or API test, registered granularity and identifier hierarchy, commodity code where relevant, backup-provider link where relevant, automated validation result, unique registration identifier, proof of registration, and update log.
  • Portal and customs roadmap: public search and comparison behavior, access-right mapping, and the separate EU customs interconnection needed for automated checks.
  • Verification record: supplier attestations, certificates, conformity documents, calculation methods, third-party verification where used, digital signatures or equivalent integrity controls, and correction workflow.
Recommended next step

Evaluate your DPP vendor shortlist against the architecture

This DPP vendor-selection guide helps test platform claims against identifiers, carriers, data models, access rights, registry readiness, and verification evidence before implementation work is locked in.

Primary sources

References and citations

eur-lex.europa.eu6 citations
Referenced sections
  • Primary legal source for DPP definitions, data carriers, unique identifiers, access rights, decentralized storage, Commission registry, public web portal, and customs checks.
  • Supports the requirement that DPPs use identifiers, data carriers, access rights, decentralized storage, a registry, and a public web portal.
  • Defines data carrier, unique product identifier, unique operator identifier, and unique facility identifier, and requires the DPP to connect through a data carrier to a persistent unique product identifier.
Show 3 more
  • Supports the need for accurate, complete, up-to-date DPP data and open interoperable data transfer without vendor lock-in.
  • Supports the access-rights, registry, web-portal, and customs-readiness requirements used as vendor-selection gates.
  • Supports the evidence package around registry upload, access rights, customs use, and the warning that receiving a unique registration identifier is not proof of compliance.
"digital product passport"
More quoted passages
"based on a decentralised data system"
"connected through a data carrier to a persistent unique product identifier"
"accurate, complete and up to date"
"search for and compare data included in digital product passports"
"shall not be deemed to be proof of compliance"
cencenelec.eu4 citations
Referenced sections
  • Design guidance source for practical DPP choices including portal setup, identifier granularity, data-carrier choices, access security, data availability, and verification.
  • Supports practical design choices for DPP identifier granularity, data carriers, portal access, access security, and data availability.
  • Supports practical access-control questions for public and restricted DPP information, authentication, data-carrier security, and portal access.
Show 1 more
  • Supports vendor due diligence questions for data trust, data-carrier authentication, restricted access, verification systems, and personal-data protection.
"Guidelines to create a Digital Product Passport"
More quoted passages
"software user roles can be set to determine for restricted data who has access"
"verification systems should be in place to improve trust"
doi.org3 citations
Referenced sections
  • Architecture source for product-centric DPP design, resolver patterns, decentralized repositories, role-based access flows, registry interaction, and backup concerns.
  • Grounds the vendor-selection focus on a product-centric architecture using identifiers, resolvers, decentralized DPP data repositories, and role-based data flows.
  • Supports evidence expectations for resolver links, decentralized repositories, credential-based access, machine-readable data, and backup or continuity scenarios.
"DPP System Architecture"
More quoted passages
"Everything starts from the simple case that a person or machine reads an identifier on a tangible good."
"different information will be provided"
eur-lex.europa.eu2 citations
Referenced sections
  • Registry implementation rules used to test vendor support for verification, registration, APIs, automated checks, logs, versions, and proof of registration, entering into force on 6 August 2026.
  • Provides vendor-test criteria for identity verification, interface and API registration, automated checks, identifier hierarchy, versioning, logs, and proof of registration; it enters into force on 6 August 2026.
etsi.org2 citations
Referenced sections
  • Technical source for evaluating whether a vendor can represent sustainability and circularity information in a structured information model.
  • Supports information-model evaluation for circularity and sustainability data, including machine-readable structure and alignment to standards.
"An information model for digital product information on sustainability and circularity"
Show all related guides (37)

DPP Governance, Verification and Audit Controls

Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates.

DPP registry and web portal integration under EU ESPR

EU Digital Product Passport Registry and web portal integration guide based on official sources: identifiers, carriers, access rights, providers, and lookup design.

DPP vs Battery Passport: ESPR and Battery Regulation Comparison

Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.

DPP vs EPREL Comparison

Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.

DPP vs GS1 Digital Link: Duties vs Standard

Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.

EU Digital Product Passport access: public, restricted, and customs views

How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.

EU Digital Product Passport API and resolver architecture

DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.

EU Digital Product Passport Applicability Test

Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.

EU Digital Product Passport architecture and integration

Guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.

EU Digital Product Passport checklist

A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.

EU Digital Product Passport compliance: ESPR requirements

EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.

EU Digital Product Passport Data Carriers, Access Control, and UX

How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.

EU Digital Product Passport data requirements and fields

How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation.

EU Digital Product Passport deadlines and compliance calendar

EU Digital Product Passport calendar covering the live DPP Registry, ESPR product-rule milestones, and fixed battery passport dates.

EU Digital Product Passport FAQ

Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.

EU Digital Product Passport identifier and data carrier design

How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.

EU Digital Product Passport penalties and enforcement

How EU Digital Product Passport breaches can lead to national penalties, corrective action, market restrictions, and customs holds under ESPR or battery law.

EU Digital Product Passport Product Group Readiness

Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.

EU Digital Product Passport requirements under ESPR

Overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.

EU Digital Product Passport supplier data validation controls

Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.

EU DPP Product-Group Readiness Checklist

A checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.

EU DPP QR Code and Data Carrier Implementation Guide

Guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.

EU DPP supplier data validation workflow

A workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.

What is a Digital Product Passport under ESPR?

A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.

DPP QR code vs NFC data carrier choices under EU ESPR

How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.

EU DPP customs access: registry, portal, and restricted data

FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.

EU DPP unique identifier requirements: product, operator and facility IDs

FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.

Public vs restricted EU Digital Product Passport data

How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.

What is the EU Digital Product Passport registry?

FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.

Which products come first for the EU Digital Product Passport?

FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.

Who must create an EU Digital Product Passport?

DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.