EU Digital Product Passport Product Group Readiness

ESPR is framework legislation. The Commission sets concrete ecodesign and passport requirements product by product, or horizontally for groups with enough common characteristics. That means a product group is not ready because it has a QR code or a portal; it is ready when the team can show which delegated act applies, which passport level is required, which data fields are mandatory, and which actors can access or update them.

Use the first ESPR working plan and the priority list in ESPR as the watchlist, then maintain a product-group tracker for each affected portfolio. The tracker should distinguish adopted rules, consultations and preparatory studies, internal assumptions, and items intentionally left open until the product-specific delegated act is final.

The binding passport field list is product-group specific, but ESPR already defines the architecture teams should prepare for. Data must be structured, searchable, transferable, based on open standards, and connected to a persistent unique product identifier. It must also be scoped to the model, batch, or item level specified in the delegated act.

A useful readiness model separates the regulated passport data from internal source evidence. For each candidate field, store the value, unit, source system, supplier or internal owner, criteria reference, assurance level, change trigger, and whether the field is public, restricted, authority-only, or withheld as confidential business information.

Many DPP fields will depend on suppliers, component manufacturers, facilities, repairers, recyclers, or conformity bodies. Readiness therefore means knowing which supplier data is needed, where it originates, who can attest it, how it is refreshed, and how it remains available when a supplier, host, or product owner changes.

Supplier intake should collect more than values. For each submitted value, capture the supplier legal entity, facility, product or component identifier, measurement method, reference period, evidence document, assurance level, confidentiality class, and reuse permission. Fields that are useful for internal planning but not grounded in the final delegated act should remain labelled as assumptions.

ESPR requires the passport to connect through a data carrier to a persistent unique product identifier. It also allows the delegated act to choose whether DPP data refers to the product model, batch, or item. That choice changes label design, supplier traceability, serialisation costs, recall handling, and whether lifecycle events such as repair or refurbishment can be attached to one physical product.

Readiness work should therefore avoid hard-coding a universal carrier pattern. Teams can still prepare carrier and resolver tests: whether the carrier will sit on the product, packaging, or accompanying documentation; whether a QR code, data matrix, RFID, NFC, or other carrier is appropriate; whether the carrier resolves to the correct product record; and whether it survives normal use, resale, repair, and recycling contexts.

ESPR expects differentiated access to DPP data. Consumers, businesses, repairers, recyclers, market surveillance authorities, customs authorities, and other actors may need different views of the same passport. Product-group delegated acts specify the access rights, so readiness should focus on classifying data and testing permission logic without pretending the final access matrix is already fixed.

A practical access model has at least four working classes: public product information, business-to-business or lifecycle partner information, authority and customs information, and restricted evidence or confidential business information. The classes should cover both read access and the rights to introduce, modify, or update data.

ESPR requires the Commission to set up a DPP registry that stores at least unique identifiers, and for products released for free circulation, the commodity code. The law sets 19 July 2026 as the registry setup date. Product-group rules and registry implementing arrangements will determine the detailed upload process and any extra registry data.

Teams can prepare now by aligning product identifiers, commodity codes, EORI and operator data, importer records, and customs-release workflows. Registry preparation should be treated as a master-data and border-control handoff, not as a marketing-page feature.

Before a product-specific delegated act is final, the defensible work is architecture and evidence readiness. Do not lock public claims, legal deadlines, penalty language, or mandatory field lists unless the applicable source already says so. Instead, create controls that can absorb the final rule without rebuilding product data from scratch.

The best output is a product-group readiness file that can be reviewed by product compliance, sustainability, master data, supply chain, IT, and customs teams. It should show what is known, what is assumed, what is waiting for the delegated act, and which systems or supplier workflows must change when the rule is adopted.