DPPData fieldsEU

EU Digital Product Passport Data Requirements and Fields

Build the passport data model from product-group delegated acts, not from a generic universal field list.

Use ESPR Annex III as the planning boundary, then separate public, restricted, authority, customs, and supplier-validated data before publication.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
8

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

The EU Digital Product Passport is a product-specific data layer introduced through ESPR product-group rules. ESPR does not create one universal list of mandatory fields for every product. Instead, delegated acts for covered product groups specify the passport data, carrier, access rights, update rights, level of granularity, and availability period.

Section 1

Start with the delegated act, not a universal DPP schema

For ESPR products, a Digital Product Passport becomes mandatory only through the applicable delegated act for the covered product group. That delegated act must identify the covered product group, ecodesign requirements, verification format, conformity module, manufacturer information requirements, transitional period, and review date.

For passport fields, Article 9 says the delegated act specifies the data included, the data carrier, where the carrier is presented, whether the passport is at model, batch, or item level, who can access which data, who can create or update data, and how long the passport remains available. Treat those points as the control record for your data model.

  • Record the product group and commodity-code scope named by the delegated act.
  • Mark each planned field as required, optional, or not applicable under that product-group act.
  • Define whether the field belongs at model, batch, or item level before suppliers start sending data.
  • Assign update rights separately from read access; ESPR treats access and update permissions as separate design questions.
  • Do not publish field lists copied from another product group unless the relevant delegated act supports them.
Section 2

Use Annex III as a bounded field catalogue

ESPR Annex III lists the kinds of data that delegated acts can require or allow in a passport. It is useful as a master planning checklist, but it is not itself a final product schema.

The grounded categories include product identifiers, GTIN or equivalent identifiers, commodity codes such as TARIC, compliance documentation, manuals and safety information, manufacturer and importer data, unique operator identifiers, unique facility identifiers, the EU-based responsible economic operator, and the passport service provider that hosts the back-up copy.

  • Identifier fields: unique product identifier, GTIN or equivalent, unique operator identifiers, and unique facility identifiers where relevant.
  • Customs and classification fields: commodity codes such as TARIC, plus registry data specified for customs and market-surveillance use.
  • Compliance fields: declaration of conformity, technical documentation, certificates, instructions, warnings, and safety information where the applicable law requires them.
  • Actor fields: manufacturer, importer, EU responsible economic operator, other relevant operators, and the service provider reference for the back-up copy.
  • Ecodesign information fields: only add performance, sustainability, label, or other ecodesign data when the delegated act or other Union law supports that data requirement.
Section 3

Separate public, restricted, authority, and customs access

A useful DPP data model has an access matrix before it has a publication page. ESPR requires free and easy access based on access rights for customers, supply-chain actors, repairers, remanufacturers, recyclers, market surveillance authorities, customs authorities, and other actors identified in the delegated act.

Do not assume that every passport field is public. The Batteries Regulation shows the practical split: some battery model information is public, detailed composition and dismantling information is restricted to persons with a legitimate interest and the Commission, test-report results are limited to notified bodies, market surveillance authorities and the Commission, and individual-battery operating or status data is restricted to persons with a legitimate interest.

  • Public layer: fields that the delegated act or product-specific law makes public for consumers, businesses, or other stakeholders.
  • Restricted value-chain layer: repair, reuse, remanufacturing, dismantling, or composition data that should not be exposed broadly unless the source rule requires it.
  • Authority layer: compliance test results and similar evidence that may be reserved for notified bodies, market surveillance authorities, or the Commission.
  • Customs layer: unique registration identifier, commodity code, and registry data needed for release-for-free-circulation checks when the product is covered.
  • Privacy and security layer: do not store customer personal data in the passport without explicit GDPR-compliant consent.
Recommended next step

Turn DPP field planning into a controlled data catalogue

Use the page to classify each passport field by product group, source rule, access layer, validation evidence, update owner, and customs or authority dependency.

Section 4

Validate supplier data before it enters the passport

Many DPP fields depend on supplier, importer, manufacturer, facility, material, and conformity records. The operating risk is not only missing data; it is publishing data that cannot be tied back to the product level, source rule, evidence owner, and update event.

Supplier validation should therefore test whether the source record supports the exact field, product level, and access layer. For example, composition, recycled-content, carbon-footprint, warranty, durability, or dismantling fields should not be accepted as broad supplier claims when the underlying product rule requires a specific model, batch, item, calculation method, test result, or documentation source.

  • Field provenance: supplier, manufacturer, importer, facility, lab, notified body, or internal system that supplied the value.
  • Product linkage: product model, batch, item, commodity code, identifier, and version that the value belongs to.
  • Evidence type: declaration, technical documentation, certificate, test report, calculation study, bill of materials, instruction, warning, or due-diligence report.
  • Validation checks: required format, units, identifier syntax, calculation method, date or version source, access classification, and approver.
  • Change trigger: bill-of-materials change, supplier change, facility change, test update, conformity-document update, or delegated-act revision.
Section 5

Common field-design mistakes to avoid

The main mistake is turning early DPP planning into a public universal spreadsheet. ESPR deliberately leaves product-group field selection to delegated acts, and product-specific rules such as the Batteries Regulation can create more detailed access tiers.

A better approach is to keep a controlled field catalogue that records the legal source, product group, data level, source system, validation rule, access layer, update owner, and evidence record for each field.

  • Do not label Annex III as a final mandatory field list for all products.
  • Do not expose restricted repair, composition, test, or individual-product data as public content without a grounded access rule.
  • Do not treat registry upload or customs release as proof of product compliance; ESPR says those events are not compliance proof.
  • Do not accept supplier sustainability values without tying them to the relevant model, batch, item, method, and evidence source.
  • Do not mix battery-passport fields into other product groups unless the applicable rule for that product group requires or allows them.
Primary sources

References and citations

single-market-economy.ec.europa.eu
Referenced sections
  • The Commission describes the DPP as a way to store and share product sustainability, durability, environmental, instruction, and conformity information.
"store and share relevant data"
eur-lex.europa.eu
Referenced sections
  • Annex XIII supports the warning not to generalize battery-specific passport data tiers across unrelated product groups.
"Information to be included in the battery passport"
eur-lex.europa.eu
Referenced sections
  • Battery passport provisions and conformity-assessment annexes ground the need to validate calculation, recycled-content, carbon-footprint, and test-report data before use.
"the reliability of data used"
data.europa.eu
Referenced sections
  • Annex III provides the bounded ESPR catalogue of DPP data elements that delegated acts can select from.
"what data are to or can be included"
eur-lex.europa.eu
Referenced sections
  • Articles 10 to 15 support the access-rights, registry, portal, and customs-control distinctions used in this section.
"based on their respective access rights"
eur-lex.europa.eu
Referenced sections
  • Articles 13 and 15 support the caution that registry identifiers and customs release are not proof of compliance.
"not be deemed to be proof of compliance"
eur-lex.europa.eu
Referenced sections
  • Article 9 requires passport data to be accurate, complete, and up to date; Articles 10 to 12 ground identifier, update-right, and data-integrity controls.
"accurate, complete and up to date"
eur-lex.europa.eu
Referenced sections
  • Article 9 grounds the page's core rule that DPP data, carrier, access rights, update rights, granularity, and availability are specified by product-group delegated acts.
"the data to be included in the digital product passport"
Related guides

Explore more topics

Annex III Data Model Planning for EU Digital Product Passports
Plan EU Digital Product Passport data fields, identifiers, access rights, update owners, registry inputs, and evidence records against ESPR Annex III and product-specific delegated acts.
Digital Product Passport vs Digital Twin
Compare EU Digital Product Passports with digital twins: legal access duties, identifiers, public and restricted data, evidence, governance, and reuse limits.
Digital Product Passport vs Paper Product Passports
Compare EU regulated digital product passports with paper, PDF, web, and internal product passports across access, identifiers, data carriers, restricted data, customs checks, registry, and interoperability.
DPP customs access review workflow for ESPR products
Review public, restricted, and customs access for EU Digital Product Passports, including registry handoffs, portal access rights, and release-for-free-circulation evidence.
DPP Data Governance RACI Template for EU Digital Product Passports
Assign accountable owners for EU Digital Product Passport data, access rights, supplier inputs, resolver links, registry uploads, verification checks, and retained evidence.
DPP data-model intake workflow for EU Digital Product Passports
A grounded intake workflow for EU Digital Product Passport data models: product group, delegated-act status, source owner, supplier data, access class, identifiers, carrier, checks, and publication readiness.
DPP Governance, Verification and Audit Controls
Build EU Digital Product Passport governance controls for data owners, supplier evidence, access logs, validation checks, audit records, and product release gates.
DPP QR code vs NFC data carrier choices under EU ESPR
How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.
DPP registry and web portal integration under EU ESPR
Grounded guide to EU Digital Product Passport registry and web portal integration under ESPR, covering identifiers, data carriers, access rights, service providers, and lookup design.
DPP vs Battery Passport: ESPR and Battery Regulation Comparison
Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.
DPP vs EPREL Comparison
Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.
DPP vs GS1 Digital Link: Duties vs Standard
Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.
EU Digital Product Passport access: public, restricted, and customs views
How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.
EU Digital Product Passport API and resolver architecture
Grounded DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.
EU Digital Product Passport Applicability Test
Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.
EU Digital Product Passport architecture and integration
Grounded guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.
EU Digital Product Passport checklist
A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.
EU Digital Product Passport compliance: ESPR requirements
Grounded EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.
EU Digital Product Passport Data Carriers, Access Control, and UX
How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.
EU Digital Product Passport deadlines and compliance calendar
Grounded EU Digital Product Passport calendar for ESPR and battery passport milestones, with product-group dates flagged as dependent on delegated acts.
EU Digital Product Passport FAQ
Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.
EU Digital Product Passport identifier and data carrier design
How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.
EU Digital Product Passport penalties and enforcement
What ESPR says about Digital Product Passport penalties, Member State fine rules, market surveillance, customs checks, and unresolved product-specific delegated acts.
EU Digital Product Passport Product Group Readiness
Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.
EU Digital Product Passport requirements under ESPR
source-linked overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.
EU Digital Product Passport supplier data validation controls
Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.
EU DPP customs access: registry, portal, and restricted data
FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.
EU DPP implementation playbook and vendor selection
Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence.
EU DPP Product-Group Readiness Checklist
A source-grounded checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.
EU DPP QR Code and Data Carrier Implementation Guide
Grounded guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.
EU DPP supplier data validation workflow
A grounded workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.
EU DPP unique identifier requirements: product, operator and facility IDs
FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.
Public vs restricted EU Digital Product Passport data
How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.
What is a Digital Product Passport under ESPR?
A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.
What is the EU Digital Product Passport registry?
FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.
Which products come first for the EU Digital Product Passport?
FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.
Who must create an EU Digital Product Passport?
DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.