EU Digital Product Passport Data Requirements and Fields

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 official source categories include product identifiers, Global Trade Identification Number (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.

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.

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 leaves product-group field selection to delegated acts, and product-specific rules such as the Batteries Regulation can create more detailed access tiers. The live Commission Registry does not replace that product schema: it stores identifiers, registration data, and high-level metadata while the detailed passport remains decentralised.

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.

The six EN 182xx:2026 standards cited by Commission Implementing Decision (EU) 2026/1736 address data exchange, identifiers, carriers, persistence, APIs, and interoperability. They can provide a presumption of conformity for the ESPR Articles 10 and 11 requirements they cover, but they are not a product-group field list. Keep the delegated act or separate Union legislation as the source for mandatory content and access rights.