What is a Digital Product Passport?

What is a Digital Product Passport? When does a DPP become mandatory?

A Digital Product Passport (DPP) is a structured digital record linked to a product through a data carrier and a persistent unique identifier. Under the EU Ecodesign for Sustainable Products Regulation (ESPR), it gives authorised users access to product information in a machine-readable, interoperable form. It is not simply a QR landing page: the applicable product law determines the data, access rights, granularity, retention, and effective date. ESPR Article 9 does not impose one passport deadline on every physical product. A delegated act adopted for a product group specifies that a DPP is required and sets the operational detail. Other EU laws can also require a DPP: the Battery Regulation already does so for certain batteries from 18 February 2027. Always start with product scope and legal status before reading a year as a deadline.

• Adopted law fixes a duty, scope, and effective date.
• An ESPR working-plan year is an indicative target for adopting a measure.
• A vendor roadmap or pilot date is a market claim, not a legal deadline.

What does ESPR already require from the architecture? Which information can a passport contain?

Articles 9 to 11 establish the common DPP architecture. The passport must connect through a data carrier to a persistent unique product identifier; use open standards and interoperable formats; be machine-readable, searchable, and structured; remain accessible for the period specified by the product rule; and be transferable independently of the operator or service provider. These are durable design constraints even while category field lists remain open. The final dataset comes from the applicable product rule, not a universal template. ESPR Annex III identifies common building blocks that can be required: product, operator, and facility identifiers; commodity codes; the data carrier; references to compliance documents; manuals, instructions, warnings, or safety information; and information about the importer or authorised representative. Product acts can add environmental, durability, repair, material, or performance data.

• The carrier can be placed on the product, packaging, or documentation as the delegated act specifies.
• A back-up copy must be available through a DPP service provider when the product is placed on the market.
• Operators cannot design the passport so that changing providers destroys access or exportability.

Who can see and update DPP data? What are operators responsible for?

Access is role-based. A delegated act identifies which customers, economic operators, customs authorities, market-surveillance authorities, repairers, remanufacturers, recyclers, or other actors can read or update each data element. Public transparency and restricted operational data can coexist in one passport architecture. Teams should model access by data field and purpose rather than choosing only between a completely public or completely private page. The economic operator placing a covered product on the market or putting it into service must ensure the required passport exists and the required Registry data is submitted. Passport information must be authentic, reliable, and verifiable, and the responsible parties must keep it accurate, complete, and current. A software provider can perform technical work, but procurement does not remove the operator's responsibility for the submitted data or its legal basis.

How should manufacturer, importer, and distributor roles be mapped? How does the EU DPP Registry fit in?

Start with the economic operator that places the product on the EU market or puts it into service, then map every supporting party around that accountable role. A manufacturer may control design and production evidence; an importer may need to verify that the passport and identifiers exist before market entry; a distributor may need to preserve the carrier and avoid selling a product with visibly incomplete information. Contracting a platform, data pool, authorised representative, or supplier does not make those hand-offs self-executing. Record who creates, checks, approves, registers, corrects, and retains each required data element, including the escalation path when two parties disagree. The EU Registry became operational on 20 July 2026. It stores unique identifiers, registration data, selected metadata, and relevant customs commodity codes rather than the complete decentralised passport. Registration applies when the relevant Union law already requires a DPP for the product. Successful registration can evidence completion of the registration step; it is not a certificate that every product or passport requirement has been met.

Which technical standards now apply? What does interoperability mean for an operator?

Commission Implementing Decision (EU) 2026/1736 references six harmonised DPP standards for parts of the common system, including identifiers, data carriers, interoperability, APIs, exchange protocols, and storage. Following a referenced harmonised standard can support a presumption of conformity for the ESPR requirements it covers. Standards do not replace the delegated act that decides whether a product needs a passport and which product data it contains. Interoperability means more than exposing a public web page. Product identities, data carriers, data models, exchange protocols, APIs, and storage arrangements must work together without trapping the passport inside one supplier's private format. In procurement, ask for the standards and versions implemented, the documented export schema, the way identifiers resolve after a migration, and the evidence that another authorised system can read the data. A standards claim should identify the exact standard and covered function. It should not imply that a technical interface settles product scope, mandatory fields, or the legal accuracy of the values supplied by the operator.

Which categories are moving first? Why is a QR product page not enough?

Batteries are the adopted-law anchor. Under the ESPR 2025-2030 working plan, priority work covers textiles and apparel, furniture, tyres, mattresses, iron and steel, aluminium, plus horizontal measures for repairability and for recycled content and recyclability in electrical and electronic equipment. The plan's years signal intended adoption work; they should not be rewritten as automatic go-live dates. A QR code is only one possible data carrier. A compliant operating model also needs persistent identifiers, structured data, defined access rights, a reliable hosting and backup arrangement, change history, Registry integration where required, and a way to keep information available across product and provider lifecycles. A polished consumer page can be useful, but it proves neither interoperability nor legal completeness on its own. Keep the carrier decision attached to the category rule and its required passport granularity.

What data work is safe to start before final rules? How should DPP data quality be controlled?

Start with work that remains useful across plausible category rules. Inventory product models, batches, and serial identities; name owners for material, component, supplier, facility, repair, and claim evidence; record source documents beside each value; and map how corrections move from source systems into customer-facing data. Treat unknown fields as gaps rather than filling them with unverified marketing language. Treat each passport value as a governed record with a source, owner, status, unit, effective date, and review trigger. Separate supplier-submitted, calculated, estimated, verified, expired, and unknown states so the published view does not flatten materially different evidence. Approval should happen before publication or Registry submission, while corrections should preserve the previous version, reason, approver, and downstream systems affected. Reconcile identifiers across ERP, PIM, product-lifecycle, supplier, and service systems rather than assuming matching labels mean matching products. These controls support the ESPR expectation that passport information be authentic, reliable, verifiable, accurate, complete, and current.

• Map each product family to its legal status and source owner.
• Document which system is authoritative for every candidate data element.
• Define how suppliers attest, correct, and refresh evidence.
• Test export, retention, and provider-exit procedures before signing a long contract.

How should passport changes and retirement be handled? How should DPP software claims be evaluated?

Plan the passport as a lifecycle record, not a launch asset. Define what happens when product data changes, a carrier is damaged, a correction is approved, an operator changes, a product is withdrawn, a provider fails, or the retention period ends. The public and restricted views may need different update paths, but both should resolve to the right product identity and version. Registry events and proof records should be reconciled with the decentralised passport rather than managed as a separate spreadsheet. A tested restore and provider-exit exercise is stronger evidence of continuity than a contractual promise that data can be exported someday. Ask the vendor to connect every compliance claim to a legal text, product scope, effective date, and unresolved dependency. Then test identifier ownership, Registry integration, data export, access controls, evidence storage, version history, supplier workflows, and service continuity. Phrases such as EU-approved, compliant for every product, or passport in minutes should trigger a request for exact sources rather than an assumption of bad faith or proof.

What is the practical decision sequence?

First classify the product and jurisdiction. Second identify whether the relevant source is adopted law, an ESPR framework rule, or a working-plan signal. Third map identifiers, evidence, access, and update ownership. Fourth test the Registry and provider architecture where applicable. Only then turn the legal requirements into a delivery roadmap, vendor brief, or public claim. This sequence keeps preparation moving without presenting open questions as settled compliance. Put the result into a decision record that names the responsible legal entity, product families, relied-on sources, open assumptions, owners, and next review trigger. Procurement, product, compliance, sourcing, and engineering can then work from the same boundary instead of maintaining conflicting interpretations. Reopen the record when a delegated or implementing act changes the scope, dataset, access model, timing, or Registry workflow.