EU Digital Product Passport requirements combine a common technical framework with product-specific rules. A compliant DPP needs a unique product identity, an accessible data carrier, reliable and current data, defined access rights, required registry records and long-term availability. The exact fields, passport level and deadline depend on the product legislation that applies.
The two layers of DPP requirements
The first layer is the Ecodesign for Sustainable Products Regulation. It sets common principles for identifiers, data carriers, interoperability, registry interaction, access and availability.
The second layer is the legislation for a product group. It answers the operational questions: which products are covered, whether the passport is at model, batch or item level, which fields are mandatory, who can see them and when the obligation starts.
This distinction prevents a common error: treating a proposed industry data model as if it were already the final legal specification.
Core requirement areas
| Requirement area | What a company needs to establish |
|---|---|
| Product identity | A unique, persistent identifier at the required granularity |
| Data carrier | A compliant physical link on the product, packaging or documentation |
| Data completeness | Every mandatory field and supporting evidence for the product group |
| Interoperability | Open formats, standards and exchange methods required by the rules |
| Access control | Public and restricted views aligned to defined user rights |
| Availability | A passport that remains accessible for the prescribed period |
| Registry | Registration of required identifiers and metadata |
| Accuracy | Governance for validation, correction and ongoing updates |
Product and operator identifiers
The DPP must be linked to a unique product identifier. Product-specific rules determine whether that identity represents a model, batch or individual item. The system may also need unique operator and facility identifiers.
Identity design affects cost and architecture. An item-level passport can require far more records and carrier operations than a model-level passport, but choosing a lower granularity is not valid if the applicable rule requires something else.
Data carrier requirements
The data carrier connects the physical product to its digital record. It must remain usable, point to the correct identifier and meet the location and durability conditions in the relevant product rules.
A complete carrier decision considers more than printing a QR code:
- where it must appear and whether packaging is sufficient;
- expected lifetime, abrasion and replacement conditions;
- resolver and domain ownership;
- identifier standards and syntax;
- offline or low-connectivity user scenarios;
- accessibility for consumers and professional users.
Data access and confidentiality
Not every user receives every field. Product rules can define who may access specific information, while the technical system must enforce those permissions without blocking public information that should be easy to obtain.
A useful data-classification exercise separates at least public, value-chain, service/repair, authority and confidential internal information. Access policy should be designed before data is published, not added after a consumer page launches.
Data quality and updates
A passport is only as trustworthy as its sources. Companies need ownership, validation rules and evidence for each regulated field. Where values change during the product lifecycle, the system must identify who can update them and retain the right history.
Supplier declarations alone may not be sufficient for every claim. Map each field to a system of record, evidence type, owner, refresh trigger and escalation path.
Registry and availability
The EU DPP Registry launched in July 2026. Economic operators can use its user interface or API to register required identifiers and metadata. The complete passport data remains decentralised, so registry readiness and passport hosting are separate workstreams.
The ESPR also anticipates continuity when an operator ceases activity or a service provider changes. Contracts should address data portability, export formats, domain and identifier control, service continuity and termination support.
Who is affected inside the company?
- Compliance interprets product rules and owns legal evidence.
- Product and sustainability teams define and validate product attributes.
- Procurement obtains upstream data and sets supplier obligations.
- IT and data teams connect ERP, PIM, PLM and traceability systems.
- Operations manage identifiers and data carriers in production.
- Legal and security set access, retention and vendor terms.
Readiness checklist
- Create an applicability matrix by product and market.
- Track the status of each relevant delegated or sector act.
- Decide a provisional identity and granularity model.
- Map likely fields to systems, suppliers and evidence.
- Classify access and confidentiality.
- Test carrier placement and resolution.
- Define registry, update and continuity processes.
- Pilot with edge cases, not only the cleanest SKU.
Frequently asked questions
What data is mandatory in a DPP?
The mandatory fields depend on the product-specific delegated act or sector legislation. The ESPR provides a framework, not one complete field list for every product.
Must every DPP use a QR code?
A DPP must be accessible through a compliant data carrier, but the applicable product rules and technical standards determine the permitted carrier and where it must appear.
Can a supplier create the passport for a manufacturer?
Suppliers can contribute data and service providers can operate the system, but the economic operator identified by the applicable legislation remains responsible for ensuring the passport is complete and compliant.
Are DPP requirements the same for every product?
No. Product-specific rules determine scope, granularity, data fields, access rights and timing. A battery passport and a future textile DPP should not be treated as identical templates.