- 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"
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.
Structured answer sets in this page tree.
Cited legal and guidance references.
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.
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.
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.
Use the page to classify each passport field by product group, source rule, access layer, validation evidence, update owner, and customs or authority dependency.
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.
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.
"store and share relevant data"
"Information to be included in the battery passport"
"the reliability of data used"
"what data are to or can be included"
"based on their respective access rights"
"not be deemed to be proof of compliance"
"accurate, complete and up to date"
"the data to be included in the digital product passport"