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.

The DPP is the digital access point for product data that EU rules require across the value chain. It supports informed choices, sustainability and circularity decisions, traceability, and compliance checks. The Commission describes it as a digital identity card for products, components, and materials.

ESPR applies broadly to physical goods placed on the EU market or put into service, including components and intermediate products, but Article 1 excludes food and feed, medicinal products, veterinary medicinal products, living plants, animals and microorganisms, products of human origin, products of plants and animals relating directly to future reproduction, and specified vehicles where other sector rules govern the relevant product aspects. Even for an in-scope product, a DPP duty starts only when the applicable delegated act or another Union act requires it; Article 9 also permits product-group DPP exemptions in two defined cases.

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 not a single public database containing every product detail. Passport data remains with the responsible economic operator or a DPP service provider. The Commission's live Registry indexes DPPs through unique identifiers, registration data, and high-level metadata rather than storing the full passport; it also supports customs and market-surveillance checks. The Commission provides a separate testing environment, while public and restricted passport views remain subject to the applicable 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.