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.
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.
1
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.
Grounds the vendor-selection focus on a product-centric architecture using identifiers, resolvers, decentralized DPP data repositories, and role-based data flows.
Everything starts from the simple case that a person or machine reads an identifier on a tangible good.
2
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.
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.
connected through a data carrier to a persistent unique product identifier
Supports practical design choices for DPP identifier granularity, data carriers, portal access, access security, and data availability.
3
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.
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
4
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.
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.
5
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.
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.
Supports vendor due diligence questions for data trust, data-carrier authentication, restricted access, verification systems, and personal-data protection.
verification systems should be in place to improve trust
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 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"
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"
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."
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.
Confirms that the production Registry and testing environment launched on 20 July 2026 and that technical documentation and implementation guidance are available.