ESPR delegated acts FAQ for product-rule monitoring and Digital Product Passport planning

Delegated acts are how the Commission supplements the ESPR with binding product-group rules. Article 4 empowers the Commission to set ecodesign requirements by delegated act, and Article 8 lists the minimum content those acts must specify.

For a covered product group, a delegated act can define the product group, set performance or information requirements, identify test or calculation methods, specify conformity assessment, set manufacturer information obligations, and include transitional and review dates. The delegated act is therefore the place to check the exact product rule, not only the framework Regulation.

The ESPR does not make every possible ecodesign duty immediately specific for every product. Article 5 says ecodesign requirements are set for a specific product group and may be differentiated within that group. Article 18 requires a working plan that prioritises product groups and horizontal measures.

This means the practical obligation analysis starts with the product group and the working-plan or delegated-act status. A team can identify that ESPR may be relevant to a product category, but it should not invent a deadline, threshold, conformity module, label content, or product-specific data field unless the applicable delegated act or another grounded source states it.

Monitor four layers: the ESPR working plan, Ecodesign Forum and consultation activity, adopted delegated acts, and any related standards or common specifications needed for testing, measurement, calculation, or DPP operation.

The monitoring output should be a product-group watch record, not a generic compliance memo. For each product group, record the source URL, publication status, affected products, requirement type, application timing if stated, open consultations, and internal owners for product design, sustainability data, conformity assessment, labels, DPP, procurement, and market access.

The DPP impact is product-specific. ESPR Article 9 says products can be placed on the market or put into service only if a DPP is available in accordance with the applicable delegated acts and the DPP rules. The same article says those delegated acts specify the data, data carrier, layout and positioning, model-batch-item level, pre-contract access, access rights, update responsibilities, update arrangements, and availability period.

Annex III lists possible DPP elements, but it does not by itself finalize every product group's passport. Teams can prepare their DPP architecture around stable ESPR concepts such as unique identifiers, open and interoperable data, access rights, back-up copies, and no customer personal data without consent. They should wait for the applicable delegated act before freezing product-specific mandatory fields.

The current public grounding supports the ESPR framework, the delegated-act mechanism, the working-plan approach, the first priority product groups listed in the Regulation, DPP architecture concepts, and example categories of DPP information. It does not justify inventing product-specific application dates, penalties, conformity modules, passport field lists, or measurement thresholds for every product group.

When a business question needs those details, the answer should identify the missing source and the monitoring channel. If no applicable delegated act has been adopted for the product group, the most accurate answer is that the product-specific obligation is not yet fully determined from the available sources.