EU Ecodesign for Sustainable Products Regulation Ecodesign Requirement Types
This page helps separate ESPR performance requirements, information requirements, product parameters, and DPP dependencies before a product-specific delegated act applies.
The page stays at framework level: it explains how requirement types are set and evidenced without inventing product-group limits, dates, penalties, or final DPP fields.
ESPR does not create one universal checklist for every product. It creates a framework for product-specific or horizontal ecodesign requirements, set mainly through delegated acts, that can take the form of , information requirements, or both. Teams should therefore track the requirement type, the product parameter it uses, the delegated act that makes it operative, the DPP or data-carrier channel used to publish information, and the technical evidence needed to verify compliance.
1
Section 1
What are the ESPR ecodesign requirement types?
ESPR ecodesign requirements divide into two legal types: and information requirements. Both are tied to product aspects and are laid down for covered product groups in delegated acts adopted under Article 4.
A team should not treat the framework regulation alone as a finished product rule. The operative requirement set depends on the relevant delegated act, which must define the covered product group, the applicable ecodesign requirements, verification methods, conformity-assessment module, technical-documentation elements, and transition details.
set minimum or maximum levels, or non-quantitative requirements, for relevant product parameters.
Information requirements require product information, including DPP and substances-of-concern information unless an exception applies.
Product parameters come from Annex I and include durability, repairability, recyclability, resource use, recycled content, carbon footprint, environmental footprint, waste generation, functional performance, and related sustainability parameters.
Delegated acts determine which requirements actually apply to a product group and how compliance information must be verified.
A DPP requirement is part of the information-requirement architecture, not a standalone substitute for meeting .
How do performance requirements differ from information requirements?
control product characteristics directly. Article 6 says products must comply with performance requirements laid down in the applicable delegated act, and those requirements are based on Annex I product parameters.
Information requirements control what must be made available about the product and how it is supplied. Article 7 includes DPP requirements and substances-of-concern tracking as minimum elements, and it can also require performance information, user and repair information, treatment-facility information, and other information that influences sustainable choices or product handling.
Performance evidence should map the product to the threshold, level, test method, calculation method, or non-quantitative condition in the delegated act.
Information evidence should map each required statement to its source data, update owner, language or access channel, and publication format.
Information requirements may be set for a product parameter even when no performance requirement is set for that same parameter.
Substances-of-concern information is not a generic marketing claim; Article 7 specifies tracked data such as substance identity, product location, concentration information, safe-use instructions, and end-of-life information.
Where a DPP exists, Article 7 requires the relevant information to be provided in the DPP and, where necessary, through other forms such as the product, packaging, label, manual, website, or application.
How do delegated acts control the requirement set?
The delegated act is the hinge between ESPR's framework language and product-level obligations. Article 8 requires delegated acts to specify the covered product group, ecodesign requirements, relevant Annex I parameters for which no requirement is necessary, methods or standards, digital-tool requirements where relevant, information needed for compliance verification, conformity assessment, manufacturer information, transitional period, and review date.
This matters operationally because the same Annex I parameter can drive different outputs. A delegated act might set a performance threshold, require disclosure, require a DPP data element, require a label, or decide that no ecodesign requirement is needed for that parameter for the product group.
Track the product group definition and commodity-code scope before assigning obligations.
Record each Annex I parameter considered and whether the delegated act sets a performance rule, information rule, both, or no requirement.
Separate legal applicability from data readiness: a DPP schema decision does not prove the product meets a performance requirement.
Tie each compliance method to the test, measurement, calculation standard, harmonised standard, or common specification named in the delegated act.
Avoid publishing dates or product-group requirements until the relevant delegated act or working-plan source supports them.
A DPP is part of the information-requirement system. 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 act and DPP requirements, where that requirement applies.
Article 10 connects the DPP through a data carrier to a persistent unique product identifier. The delegated act specifies the data, carrier placement, model-batch-item level, access rights, update roles and availability period. Implementing Decision (EU) 2026/1736 now publishes harmonised standards for data exchange protocols, unique identifiers, data carriers, storage and persistence, lifecycle APIs and system interoperability. Those standards support the horizontal Article 10 and 11 requirements; they do not select a product group's DPP content.
Do not design a fixed DPP field list for all ESPR products; Annex III lists possible data elements and the delegated act selects what is required for the product group.
Keep DPP granularity explicit: model, batch, or item level changes evidence ownership and update logic.
Keep data-carrier placement explicit because Article 10 allows the product, packaging, or accompanying documentation as specified by the delegated act.
Plan access rights separately for public users, value-chain actors, market surveillance authorities, and customs authorities.
Treat data accuracy, completeness, currency, interoperability, security, privacy, and fraud prevention as DPP design controls, not just website-display details.
What evidence should support each requirement type?
Evidence should mirror the requirement type. For , keep the product data, measurements, calculations, test reports, and comparison against the delegated-act requirement. For information requirements, keep the source data, publication channel, DPP field mapping, substance-tracking data where required, and proof that the information remains accurate and accessible.
Annex IV describes internal production control and technical documentation. It expects documentation that allows conformity assessment against the delegated act, including design and manufacturing information, standards or technical specifications used, design calculations, examinations, measurements, test reports and a copy of Article 7 information. For a DPP, record which parts of the 2026 harmonised standards are applied and which Article 10 or 11 requirements they cover; a standards declaration does not prove the product meets separate .
For performance rules, maintain a trace from Annex I parameter to delegated-act requirement to test or calculation result.
For information rules, maintain a trace from required statement to source data, publication channel, language/access decision, and update owner.
For DPP rules, maintain a trace from delegated-act field requirement to model, batch, or item identifier, access right, data-carrier placement, and backup or service-provider control.
For market-surveillance readiness, keep the technical documentation and declaration-of-conformity package aligned with the delegated act and available for authority requests.
For unsupported claims, record the gap instead of turning framework-level ESPR language into product-specific requirements.
Publishes EN 18216, EN 18219, EN 18220, EN 18221, EN 18222 and EN 18223. Conformity creates a presumption only for Article 10 and 11 requirements covered by the applied standard.
ETSI source from the cited sources support evidence implications for DPP information models, including expected evidence and references to conformity evidence.
Commission overview confirming that ESPR establishes a framework for setting requirements on specific product groups and can also support horizontal rules.
Annex IV describes technical documentation for internal production control and requires evidence such as measurements, test reports, and copies of Article 7 information.
"technical documentation shall specify the applicable requirements"