What is a Digital Product Passport?

The ESPR is a framework regulation. It creates the legal machinery for ecodesign requirements and the Digital Product Passport, but it does not make every passport field identical across all products. The product group delegated act adopted under ESPR determines whether a DPP is required for that product group and what the passport must contain.

For a visitor trying to understand the concept, the simplest description is this: the DPP is the digital access point for product data that EU rules want available across the value chain. It is meant to support more informed choices, sustainability and circularity decisions, traceability, and compliance checks. The Commission describes it as a digital identity card for products, components, and materials.

A DPP starts with a physical product and a data carrier. The carrier points to or enables access to the passport by using a persistent unique product identifier. ESPR requires passport data to use open standards and interoperable formats where appropriate, so the information can be machine-readable, structured, searchable, and transferable without vendor lock-in.

The architecture is deliberately not a single public database containing every product detail. ESPR states that passport data is stored by the economic operator responsible for creating it or by passport service providers. The Commission registry stores at least unique identifiers and supports enforcement, customs, and authenticity checks. A public web portal is also required so stakeholders can search and compare passport data according to their access rights.

The DPP is only useful if people and systems can reliably connect the physical product to the right record. ESPR therefore separates the carrier from the identifier. The carrier is the physical or digital medium that can be read by a device; the unique product identifier is the string that identifies the product and enables the passport link.

ESPR also recognises unique operator identifiers and unique facility identifiers. These help identify actors and locations in the value chain where relevant. Access is not all-or-nothing: the delegated act must specify which actors can access which passport data, who can create or update data, and the detailed arrangements for introducing or updating it.

The most important implementation point is that ESPR does not give every product group the same DPP specification. The applicable delegated act must decide the operational details for the covered product group. That is why a DPP programme should not lock in a final field list, carrier placement, access matrix, or model-batch-item choice before the product-group rule is known.

The delegated act can specify the passport data, one or more data carriers, the layout and positioning of the carrier, whether the passport is at model, batch, or item level, customer access before sale, actor-by-actor access rights, who may create or update data, update arrangements, and how long the passport must remain available. The availability period must correspond to at least the expected lifetime of the specific product.

Teams can prepare the foundation without pretending that final product-group obligations are already known. The practical work is to make product data traceable, identify where sustainability and compliance attributes live, decide how product, operator, and facility identifiers are governed, and design access controls that can separate public, business, and authority-facing information.

A useful readiness plan distinguishes stable ESPR architecture from product-specific choices. Stable architecture includes identifiers, carrier resolution, structured data, access control, back-up availability, registry readiness, and auditability. Product-specific choices include mandatory field lists, carrier placement, model-batch-item level, who can update each field, and the exact lifetime for availability.