EU Digital Product Passport Architecture and Integration

The first architecture decision is the level at which the passport identifies the product. ESPR leaves the exact level to the delegated act for the relevant product group, so teams should not assume that every product will use the same model, batch, or item-level passport design.

The passport data model should reserve fields for the unique product identifier, Global Trade Identification Number or equivalent where relevant, commodity codes, compliance documentation, manuals or warnings, manufacturer and importer information, unique operator identifiers, unique facility identifiers, the responsible Union economic operator, and the backup service provider reference when those elements are required for the product group.

The data carrier should give a scanner a reliable path from the physical product to a usable digital address. ESPR describes machine-readable data carriers such as QR codes or watermarks, preferably on the product where possible, and requires relevant identifiers and data carriers to follow recognised standards where applicable.

For implementation, the carrier should encode or resolve to a URI or equivalent identifier that can return typed links for the relevant user: public passport page, machine-readable data, conformity evidence, repair or recycling endpoints, backup access, and authority interfaces. CIRPASS describes both HTTP URI and decentralized identifier approaches; the common architectural point is that the carrier starts discovery while data can remain in decentralized repositories.

Since 15 July 2026, Commission Implementing Decision (EU) 2026/1736 has cited six harmonised standards for DPP data exchange, unique identifiers, data carriers, storage and persistence, lifecycle APIs, and system interoperability. Conformity with those standards gives a presumption of conformity for the ESPR Articles 10 and 11 requirements they cover. The applicable delegated act still controls product scope, passport level, selected data, carrier placement, access rights, and availability.

The Commission launched the DPP Registry and a testing environment on 20 July 2026, but the detailed passport remains decentralised. The responsible economic operator or a DPP service provider stores passport data; the Registry indexes unique identifiers, registration data, and high-level metadata and stores customs-relevant commodity codes where required. It is not the product master database.

Implementing Regulation (EU) 2026/1778, effective from 6 August 2026, defines the secure interface, registration API, verification platform, user identity and authorisation, semantic repository, and logging. The public web portal remains a separate search-and-compare layer, so teams still need stable, access-controlled endpoints for the detailed passport.

Access control is a first-order passport requirement. ESPR requires easy, free access based on access rights set in the applicable delegated act and restricts rights to introduce, modify, or update data. The architecture should therefore label each field by audience, credential, purpose, update right, and evidence source.

The Batteries Regulation is a useful worked example of access categories: some battery model information is public, some information is limited to persons with a legitimate interest and the Commission, test-report results are limited to notified bodies, market surveillance authorities and the Commission, and individual battery data can be limited to persons with a legitimate interest. Product groups under ESPR may differ, but the architectural pattern is the same: data fields need access classes, not one flat public payload.

Many passport fields depend on suppliers, test labs, repairers, recyclers, or service providers. ESPR allows the Commission to require supply chain actors to provide information needed to verify compliance, and CIRPASS shows why the passport architecture needs update flows as well as read flows.

A defensible implementation gives suppliers structured submission routes, evidence formats, data-quality checks, and update rights. It also defines when a downstream lifecycle event updates the existing passport and when a new product identifier or new passport is needed under the relevant product rules.

Public DPP access, customs access, and restricted professional access solve different problems. Consumers and business buyers need understandable sustainability, circularity, durability, instruction, and compliance information. Customs authorities need the unique registration identifier and commodity code to match registry data when products are released for free circulation. Market surveillance authorities and notified bodies may need deeper compliance evidence.

The architecture should therefore expose different views over the same governed source data. A consumer page can be concise and accessible; the authority and customs integration must be stable, machine-readable, and aligned with the registry and EU Customs Single Window interconnection when applicable.

A DPP architecture is not complete until operational ownership is clear. The responsible economic operator, service provider, data owners, supplier owners, compliance approvers, and IT operators need defined duties for creation, authentication, processing, storage, backup, access control, correction, withdrawal, incident handling, and evidence retention.

Good governance avoids two common failures: a technically working QR code with unverified content, and a compliance data repository that cannot be reached by customers, authorities, or customs through the required passport path.