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.

ESPR points to a decentralized operating model: the passport is stored by the economic operator responsible for creation or by a passport service provider, while the Commission registry stores at least unique identifiers and, for products released for free circulation, the commodity code. That distinction matters for architecture: the registry is not the product master database, and the public portal is not necessarily the authoritative storage location for every data item.

The Commission web portal is intended to let stakeholders search and compare passport data in line with their access rights. Teams therefore need an integration layer that can publish searchable, comparable, access-controlled data without copying every restricted supplier record into a single public surface.

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.