What are the Digital Product Passport requirements?
Digital Product Passport requirements are not one universal list for every product. The EU framework establishes the DPP structure, while delegated acts and other applicable product legislation can specify the data, carrier, presentation, granularity, access, and timing for covered product groups.
The starting legal text is Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation. Its DPP provisions say applicable delegated acts can specify items such as:
- data included in the passport;
- one or more data carriers;
- carrier layout and positioning;
- model-, batch-, or item-level granularity;
- access before a customer is bound by a sales, hire, or hire-purchase contract;
- relevant access rights and product information.
Read the current official Regulation (EU) 2024/1781 text with the delegated act and other law applying to the product. This guide is not legal advice.
Why generic DPP checklists are risky
A generic checklist can mix:
- horizontal framework requirements;
- draft or proposed product fields;
- standards work;
- battery or other sector-specific rules;
- customer procurement requests;
- vendor product features;
- voluntary sustainability claims.
Those sources do not have the same legal status. A useful requirement register records the authority, version, product scope, effective date, and uncertainty for every row.
If a product-specific measure is still in development, the correct state may be pending rather than mandatory.
The requirement hierarchy
Framework regulation
The ESPR establishes the overall ecodesign framework and DPP architecture for products covered through its implementation. It describes the relationship between product requirements, delegated acts, passport data, access, and registry infrastructure.
Product-specific delegated acts
Delegated acts can establish ecodesign and information requirements for a product group. They are the critical source for deciding which fields, levels, carriers, and dates apply to that group.
Other product legislation
Some products may have DPP duties or related data requirements under other EU legislation. Do not assume the ESPR is the only source.
Implementing acts and registry rules
Operational requirements can cover infrastructure, registration, customs interaction, formats, or procedures. Confirm the current official technical documentation.
Harmonised and other standards
Standards can support identifiers, carriers, data exchange, interoperability, security, and related implementation. Record whether a standard is final, cited, required, or voluntarily selected for the project.
Contractual and internal requirements
Customers, marketplaces, quality teams, and sustainability programs may request additional data. Label these as contractual or internal; do not present them as statutory DPP fields.
Product groups and timing
The Commission's implementation work prioritizes product groups rather than imposing one identical date on all products. For example, the Commission's current textile and apparel DPP page says textile-specific requirements will be defined through a future delegated act and will build on horizontal requirements.
That distinction matters. A brand can prepare product identity, supplier evidence, provenance, and governance before every final field is known. It should not publish an invented compliance deadline or claim a draft field is final.
Maintain a dated timeline with:
- official source;
- proposal, consultation, adopted, or effective status;
- product scope;
- transition period;
- organizational decision;
- next review date.
Requirement-register fields
For every requirement, store:
- unique internal code;
- plain-language statement;
- exact official source and article or section;
- source status and version;
- product groups and markets;
- economic operator or actor;
- effective and transition dates;
- passport granularity;
- required value or document;
- allowed vocabulary, format, and unit;
- authoritative internal or supplier source;
- review method;
- access class;
- carrier and publication rule;
- registry requirement;
- retention or availability rule;
- owner;
- current evidence state;
- legal or technical questions.
This register becomes the bridge between law, supplier requests, source systems, and software validation.
Data categories that may need analysis
Actual categories depend on the applicable measure. A discovery exercise may need to investigate:
- product and economic-operator identity;
- model, batch, or item identity;
- materials, components, and substances;
- manufacturing or facility information;
- environmental or performance parameters;
- durability, repair, disassembly, or maintenance information;
- recycled or recyclable content;
- conformity and supporting documentation;
- end-of-life or handling information;
- identifiers, carrier, and access metadata.
This is an analysis list, not a promise that every category applies to every product.
Worked requirement-mapping example
Assume a team is preparing a product family and has three candidate rows:
| Code | Candidate requirement | Source state | Evidence state |
|---|---|---|---|
| ID-MODEL | Stable model identity | Confirmed framework/project need | Available |
| REC-CONTENT | Recycled-content evidence | Product rule pending confirmation | Supplier file pending review |
| CARBON-DECL | Carbon declaration | Customer request, not yet mapped to law | Missing |
The register prevents three errors:
- the customer request is not mislabeled as an ESPR mandate;
- the pending product-rule interpretation is not published as final;
- a received supplier file is not treated as an accepted claim.
Qualified reviewers can update source status without losing the historical decision trail.
How to discover applicable requirements
1. Classify the product
Record product function, composition, market, operator role, model and batch structure, and other facts needed for scope.
2. Identify primary law
Use official legal and Commission sources. Record consolidated status and amendments where relevant.
3. Find the product measure
Determine whether a delegated act or other product law applies, is adopted, or remains under development.
4. Trace implementation sources
Review current implementing acts, registry materials, standards references, guidance, and official consultations.
5. Separate non-legal requirements
Add customer and internal requirements with their own source type.
6. Obtain qualified approval
Have appropriate legal, regulatory, product, sustainability, and technical owners approve the map.
7. Convert requirements into evidence tests
For each row, define the value, source, validation, reviewer, access, and acceptance evidence.
8. Schedule source monitoring
Assign an owner and next review. Do not rely on someone remembering to revisit a bookmark.
Technical requirements need the same discipline
The Commission announced the DPP Registry and test environment launch on 20 July 2026. Technical teams should work from the current official environment and specifications.
For each integration rule, record:
- endpoint or specification version;
- authentication and authorization;
- identifier format;
- payload validation;
- error semantics;
- idempotency and duplicate behavior;
- retry policy;
- evidence retained;
- production versus test boundary.
Successful connectivity does not establish that the data is legally complete.
Requirements quality checklist
- Every row has a descriptive primary source.
- Product scope is explicit.
- Draft and adopted states are separate.
- Effective dates are reviewed.
- Statutory, standard, contractual, and internal rows are labeled.
- Units and vocabularies are controlled.
- Evidence and reviewer are defined.
- Public and restricted data are separated.
- Unknowns remain visible.
- Source changes trigger reassessment.
- Historical decisions are retained.
- No completeness score is called compliance.
Common mistakes
Using a vendor field list as law
Vendor templates can accelerate discovery, but qualified scope must return to primary sources.
Assuming every product needs an item-level passport
The applicable measure can define model, batch, or item granularity.
Treating standards work as final obligation
Record the status and legal relationship of each standard.
Publishing one deadline for all sectors
Product measures and transitions vary.
Forgetting access requirements
The passport is not simply a public webpage. Data access can vary by actor and purpose.
Boundaries
This page cannot determine which requirements apply to a particular product. That requires current product facts, official sources, and qualified analysis. Requirements also change, so every production map needs an owner and date.
To map configured requirements to accepted, pending, and missing supplier evidence, run the EvidencePass sample and use the same page to request a paid product-group requirements review. The review does not provide certification or legal advice.