EU Digital Product Passport Product-Group Readiness Checklist

Start with the legal status of the product group. ESPR is framework legislation: concrete ecodesign and information requirements are set later through product-specific or horizontal delegated acts. The Commission page states that the first ESPR and Energy Labelling Working Plan was adopted in April 2025 and that product rules will be developed through planning, impact assessments, Ecodesign Forum consultation, and specific consultations.

Mark a product group as implementation-ready only when an adopted product rule supplies the operative scope and DPP requirements. Draft consultation material and working-plan priorities support monitoring and preparation, not a live passport specification. Label each status so engineering and supplier teams can distinguish binding requirements from open design inputs.

Article 9(4) also allows the Commission to exempt a product group where DPP technical specifications are unavailable or another Union-law digital information system achieves the required access and authority-verification objectives. Treat an exemption as valid only when the adopted act states it; a company cannot self-exempt by pointing to an internal database or voluntary product page.

Create a field inventory before designing screens or supplier forms. ESPR Annex III lists the types of passport data that delegated acts can draw from, including product information required by Article 7, the unique product identifier, GTIN or equivalent identifiers, commodity codes, compliance documentation, instructions and safety information, manufacturer and importer information, operator and facility identifiers, and the passport service provider reference.

For each candidate field, name the system of record, update owner, evidence source, public/confidential status, and whether the value applies at model, batch, or item level. Leave fields in a pending state when the delegated act has not yet selected them.

A product group is not ready if the manufacturer cannot obtain controlled, updateable data from suppliers and downstream actors. ESPR requires passport data to be accurate, complete, and up to date, and Article 9 allows the delegated act to specify who may create or update the passport and what data each actor may introduce or update.

Convert this into supplier controls. Each field should have a named supplier source, evidence format, validation rule, confidentiality classification, and change-notification trigger. This is especially important for substances, material origin, recycled content, repair information, and facility or operator identifiers.

Do not treat a QR code, NFC tag, or web URL as the passport by itself. ESPR requires the passport to be connected through a data carrier to a persistent unique product identifier. The delegated act specifies the carrier, layout, positioning, and whether the passport is established at model, batch, or item level.

The readiness check should prove that identifiers can remain unique, verifiable, and durable across packaging changes, product variants, domain changes, service-provider changes, and market surveillance or customs checks.

The readiness checklist should classify every field by access class before it is loaded into a passport system. ESPR requires access to be regulated by the essential requirements in Articles 10 and 11 and by product-group access rights in the applicable delegated act. It also lists audiences that may need access, including customers, economic operators, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, and trade unions.

Use access classes to avoid two common errors: hiding information that the delegated act makes available to a class of actors, or exposing business-sensitive and personal data beyond the allowed purpose.

Registry readiness is separate from the public passport page. The Commission launched the DPP Registry and a testing environment on 20 July 2026. It indexes DPPs with unique identifiers, registration data, and high-level metadata rather than storing the full passport; for products intended for release for free circulation, the applicable rules also use commodity-code data.

Treat a product group as registry-ready only when the team can enrol the responsible organisation, generate valid identifiers, bind them to the correct commodity codes where relevant, submit the required payload through the Registry interface or API, and reconcile the result with the passport resolver and internal product master data. Testing the platform does not establish that a product-group DPP duty already applies.