Artifact GuideEU

EU Digital Product Passport (DPP) Requirements

The rules you must implement: availability, identifiers, data carriers, access rights, security, registry and customs readiness.

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

DPP compliance is a technical and operational program: product identifiers, data carriers, open standards and interoperability, differentiated access rights, audit evidence, registry integration and customs workflows. Use this page as a baseline requirements spec you can map to systems and owners. In current practice, that baseline now sits alongside the first ESPR working plan for 2025-2030 and the Commission's follow-on work on DPP service-provider rules.

Section 1

Article 9 - When a DPP is required (market access rule)

For product groups covered by delegated acts, the rules can require that products can only be placed on the market or put into service if a DPP is available in accordance with the delegated act and Articles 10 and 11.

The regulation also sets an explicit quality requirement: DPP data must be accurate, complete and up to date.

Delegated acts must specify: the data fields (Annex III), data carrier(s), layout/positioning, granularity (model/batch/item), pre-purchase access (including distance selling), access rights, who can create/update, update arrangements, and availability period (at least expected lifetime).
DPP requirements must support: easy actor access/understanding, compliance verification by authorities, and improved traceability.
Exemptions are possible where technical specs are not available or other EU digital systems already achieve the objectives.

Section 2

Article 10 - Essential requirements (IDs, carriers, open standards, privacy)

Article 10 sets the core technical requirements that should shape your system design and vendor selection.

These requirements push DPP toward open standards and interoperability, explicitly aiming to avoid vendor lock-in.

Persistent unique product identifier connected through a data carrier; carrier must be physically present on the product, packaging, or accompanying documentation.
Standards-based identifiers and carriers: comply with standards referenced in Annex III (or equivalent standards until harmonised references are published).
Open standards + interoperability: data should be machine-readable, structured, searchable and transferable through an open interoperable data exchange network without vendor lock-in.
Personal data: customers' personal data must not be stored in DPP without explicit consent in line with GDPR.
Commercial enablement: the economic operator must provide dealers/online marketplaces a digital copy of the carrier or unique identifier to support customer access where physical access is not possible.

Recommended next step

Operationalize EU Digital Product Passport (DPP) Requirements across ESG workflows

ESG Compliance can take EU Digital Product Passport (DPP) Requirements from turning the requirements into assigned actions 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.

ESG workflow

Open ESG Compliance for EU Digital Product Passport (DPP) Requirements

Start from EU Digital Product Passport (DPP) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow.

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) Requirements.

Explore next step

Section 3

Article 11 - Technical design and operation (access rights, security, longevity)

Article 11 is the operational backbone: access rights, storage models, lifecycle linking, and security requirements.

Design for longevity: DPP must remain available for the product-group specified period, including after insolvency or cessation of activity.

Interoperability requirement: DPP must be fully interoperable with other DPPs (technical, semantic and organisational aspects of end-to-end communication and data transfer).
Access requirement: relevant actors must have free of charge and easy access based on their access rights in delegated acts.
Storage + lifecycle: stored by responsible economic operator or DPP service providers; new DPPs must link to prior DPPs; data modification rights are restricted per access rights.
Trust + security: authentication, reliability and integrity; high level of security and privacy; fraud avoidance.
Service provider constraint: if a DPP service provider stores/processes DPP data, it must not sell/reuse/process the data beyond what is necessary for the service unless specifically agreed.

Section 4

Article 12 - Unique identifiers (operators and facilities)

Beyond the product identifier, ESPR anticipates unique operator and facility identifiers that can be referenced in the DPP.

If an identifier is not available, the operator creating/updating the DPP may request it on behalf of the actor, after confirming it does not already exist.

Unique operator identifiers (manufacturer and other operators) and unique facility identifiers must comply with standards referenced in Annex III (or equivalent standards).
Plan governance for identifier issuance and lifecycle management (including the possibility of issuing agencies and operator-created identifiers via delegated acts).
Ensure identifiers are stable and resolvable, and record changes over time (ownership transfer, facility changes, operator role changes).

Section 5

Articles 13-15 - Registry, portal and customs controls

ESPR introduces EU-level systems and customs workflows that DPP implementations should plan for early.

This is where DPP becomes more than "information": it becomes a compliance control surface.

Registry: by 19 July 2026, the Commission must set up a digital registry storing at least unique identifiers (and commodity codes for release-for-free-circulation products).
Web portal: the Commission must set up a publicly accessible portal to search and compare DPP data consistent with access rights.
Customs: once the registry is operational, products under release for free circulation require providing the unique registration identifier; customs may verify identifier + commodity code electronically and automatically.

Section 6

Current implementation layer: working plan and service-provider rules

The legal requirements in Articles 9-15 are now being translated into the actual DPP operating model through the first ESPR working plan and the Commission's work on service-provider governance.

That matters because implementation timing, storage responsibilities, and provider controls are now part of practical DPP compliance planning.

First ESPR working plan: adopted by 19 Apr 2025 and released for the 2025-2030 period, giving the first product-group rollout signal.
Service-provider consultation: launched 9 Apr 2025 and closed 1 Jul 2025, focused on storage, management, and possible certification rules for DPP service providers.
Program implication: design your DPP so it remains compliant if the Commission tightens provider requirements, continuity expectations, or certification conditions.

Section 7

Annex III - DPP data elements (what delegated acts can require)

Annex III lists the classes of data that delegated acts can require in the DPP. Use it to build your canonical data model and identify source systems.

The fields cover identity, compliance documentation, manuals, and operator metadata (including importer EORI and service provider references).

Identity and classification: unique product identifier, commodity codes (e.g., TARIC), and GTIN (ISO/IEC 15459-6 or equivalent).
Compliance evidence: declaration of conformity, technical documentation, certificates, and other compliance information under EU law.
User information: manuals, instructions, warnings and safety information where required.
Operator metadata: manufacturer and other operator identifiers, importer info (including EORI), facility identifiers, and service provider back-up references.

Section 8

Implementation checklist (turn requirements into shipped work)

Treat DPP requirements as a product spec: what must exist, for which actors, at which lifecycle stage, and with what evidence.

The fastest path is a CPS-style mapping: requirement -> system component -> owner -> acceptance criteria -> evidence.

Map Annex III fields to master data, PLM, compliance docs, packaging/label systems, ERP and importer workflows.
Choose identifier and carrier standards; implement resolver and offline fallback for distance selling use cases.
Design access control and audit logging aligned to delegated act actor rights; keep public data accessible without forced apps or personal data collection.
Plan registry integration: unique identifiers upload, unique registration identifier retrieval, and customs data flows.
Select vendors against Article 10/11 constraints: open standards, interoperability, no vendor lock-in, and service provider non-reuse constraints.

Primary sources