Artifact GuideEU

EU Digital Product Passport (DPP) What It Is (and Why It Matters)

A product-specific dataset accessible via a data carrier - built to support sustainability, circularity, and compliance.

Grounded in ESPR (Regulation (EU) 2024/1781) Articles 9-15 and Annex III.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Mar 4, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Mar 4, 2026

Overview

A Digital Product Passport (DPP) is not a marketing microsite. Under ESPR (Regulation (EU) 2024/1781), it is a set of product-specific data - defined in product-group delegated acts - that must be accessible electronically through a data carrier (for example a QR/ID) and designed for differentiated access across the value chain. In practical terms, the DPP rollout is now shaped by the first ESPR working plan for 2025-2030 and the supporting EU registry and service-provider rules that are still being operationalised.

Section 1

The legal definition and where DPP requirements live

Under ESPR, a DPP is a set of data specific to a product that includes the information specified in the applicable delegated act adopted under Article 4 and that is accessible via electronic means through a data carrier.

In practice, DPP is a framework capability: the Commission sets product-group rules (delegated acts) that specify what data must be included, at what granularity (model/batch/item), who can access which fields, and who can create or update the data.

ESPR Chapter III (Articles 9-15) sets core DPP obligations: availability, essential requirements, registry, web portal and customs controls.
Product-specific delegated acts (Article 4) define the actual DPP content and access rights per product group.
Annex III provides the universe of DPP data elements that delegated acts can require (IDs, compliance docs, manuals, operator IDs, facility IDs, etc.).
The first ESPR working plan, released in April 2025 for the 2025-2030 period, is the current policy signal for which product groups will move first.

Recommended next step

Use EU Digital Product Passport (DPP) What It Is (and Why It Matters) as a cited research workflow

Research Copilot can take EU Digital Product Passport (DPP) What It Is (and Why It Matters) from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Research workflow

Open Research Copilot for EU Digital Product Passport (DPP) What It Is (and Why It Matters)

Start from EU Digital Product Passport (DPP) What It Is (and Why It Matters) and answer scope, timing, and interpretation questions with cited outputs.

Explore next step

Talk to Sorena

Talk through EU Digital Product Passport (DPP)

Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) What It Is (and Why It Matters).

Explore next step

Section 2

Who the DPP is for (and why access must be differentiated)

DPP is designed to serve many actors: customers, economic operators (manufacturer/importer/distributor/dealer), repair and circularity operators, market surveillance and customs authorities, and other stakeholders.

Because DPP data includes both public consumer-facing information and restricted compliance/technical information, DPP must support differentiated access rights by stakeholder type.

Customers: easy, free access to the information they need before purchase (including distance selling).
Circularity operators: repair/refurbish/recycle information and identifiers to support life extension and end-of-life operations.
Authorities: faster compliance verification, authenticity checks, and improved traceability and market surveillance.

Section 3

What data is inside a DPP (Annex III, in plain language)

DPP data fields are product-group specific, but the regulation already enumerates the kinds of data that may be required.

A practical way to understand DPP data is to split it into four layers: identity, compliance, usage/circularity, and operator/facility metadata.

Identity layer: unique product identifier, commodity codes (e.g., TARIC), and (where applicable) a Global Trade Identification Number (GTIN).
Compliance layer: declaration of conformity, technical documentation, and conformity certificates where applicable under EU law.
Usage/circularity layer: user manuals, instructions, warnings and safety information (where required) and additional ecodesign information defined by delegated acts.
Operator/facility layer: manufacturer/operator identifiers, importer info (including EORI), facility identifiers, and reference to the DPP service provider hosting the back-up copy.

Section 4

Model vs batch vs item level: why granularity is a key design decision

A DPP can be established at model, batch or item level depending on product-group rules. This directly affects architecture and cost: item-level DPP implies unique identifiers per unit; model-level implies shared identifiers with shared data.

Delegated acts must specify the level and the definition of that level for the product group.

Model-level DPP: faster to implement; best when product units share identical regulated characteristics.
Batch-level DPP: useful when manufacturing context affects compliance-relevant characteristics.
Item-level DPP: strongest traceability; highest implementation complexity and lifecycle update needs.

Section 5

Data carrier + unique identifiers: the bridge between physical and digital

A DPP must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, packaging, or accompanying documentation, as specified by product-group rules.

A DPP is designed to work with open standards and interoperability - to avoid vendor lock-in and to enable end-to-end traceability.

Data carrier examples: QR/2D codes, RFID/EPC, or other standardised carriers depending on the product and context.
Identifiers and carriers must comply with standards referenced in Annex III (or equivalent standards until harmonised references are published).
Personal data: the regulation explicitly restricts storing customers' personal data in the DPP without explicit consent under GDPR.

Section 6

EU systems: registry, web portal, and customs controls

ESPR requires EU-level infrastructure to support DPP authenticity checks and automated controls.

For implementation teams, this translates into: (1) registry integration, (2) public and restricted data views, and (3) customs/market surveillance readiness.

Digital product passport registry: the Commission must set up a registry that stores at least unique identifiers (with commodity codes for release-for-free-circulation products).
Web portal: a public portal should allow searching and comparing DPP data consistent with access rights.
Customs: for covered products placed under release for free circulation, the unique registration identifier must be provided when the registry is operational, and customs may verify it electronically.

Section 7

What is happening now: service-provider rules and rollout governance

The legal framework already allows DPP data to be stored by responsible economic operators or by DPP service providers, but the operating model is still maturing.

This is why storage architecture, backup access, continuity, and provider certification questions are not theoretical design issues. They are part of the Commission's active implementation agenda.

On 9 Apr 2025, the Commission launched a public consultation on how DPP data should be stored and managed by service providers and on whether a certification scheme is needed.
That consultation closed on 1 Jul 2025 and feeds the future rules for effective DPP system functioning.
If you depend on a DPP platform vendor, you should treat provider controls and migration rights as part of core compliance design.

Section 8

How to start: week-one deliverables that de-risk implementation

A DPP program succeeds when it produces engineering-grade artifacts early: data maps, owners, identifier strategies, and evidence packages.

Use these deliverables to avoid building a portal that cannot satisfy delegated acts, access rights, and audit requirements later.

DPP scope memo: product group(s), expected delegated act triggers, and the DPP granularity (model/batch/item) assumptions.
Annex III data map: fields -> source systems -> owners -> update frequency -> retention policy.
Identifier + carrier strategy: unique product identifier scheme, carrier choice, and fallback access for distance selling.
Access control model: public vs restricted fields; actor types; authentication approach; audit logging.
Evidence pack skeleton: declaration of conformity, technical documentation references, and how you keep DPP data accurate, complete and up to date.

Primary sources