The Digital Product Passport is a horizontal product-information mechanism under the Ecodesign for Sustainable Products Regulation. is the product database established by Article 12 of Regulation (EU) 2017/1369 for energy-labelled product models. Since 1 January 2019, a supplier must register a new model covered by an energy-labelling delegated act before placing a unit of that model on the Union market. An EPREL model record, energy label, QR code, or registration number does not by itself satisfy an ESPR DPP obligation.
Comparison matrix
DPP vs EPREL: what each system is for
Read the rows as implementation boundaries: DPP governs passport architecture and access under ESPR; remains tied to energy labelling and product-database functions.
A product passport under ESPR for product-related sustainability, circularity, traceability, compliance, access-rights, and registry use, with details set by product-specific delegated acts.
Second framework
EPREL
The European Product Registry for Energy Labelling, referenced as an existing Union database/tool and as the target of energy-label QR access for relevant energy-labelled products.
DPP is the ESPR mechanism for making product information available across the value chain. It is expected to improve access to relevant information, end-to-end traceability, and competent-authority work without exposing confidential business information beyond the access rights set for the product group.
is the European Product Registry for Energy Labelling. Its public part provides product information, energy labels, and product information sheets; its compliance part contains specified technical documentation and is accessible to market surveillance authorities and the Commission.
DPP requirements arise under ESPR delegated acts for product groups. Depending on the product-specific rule, the passport can contain sustainability, circularity, traceability, and compliance information.
applies to models covered by energy-labelling delegated acts. The supplier enters the prescribed model information before placing a unit of a new model on the market; the product database does not apply to every product merely because it is energy-related.
Start by asking whether the product is covered by an ESPR delegated act requiring a DPP, whether it is energy-labelled, or both. The overlap is product-specific, not automatic.
DPP data is product-passport data. ESPR says the passport can be specific to the item, batch, or product model, with the level selected in the product-specific delegated act. ETSI describes DPP information as product-specific data conveyed through a unique identifier.
cited support is model-and-label oriented: energy labels identify a model and link via QR code to EPREL for additional technical specifications and information. The provided source support does not support treating EPREL as an item-level lifecycle passport.
Map DPP data at the granularity required by the ESPR delegated act. Reuse model data only where the same attribute, product group, and access need are explicitly supported.
DPP access is role-based. ESPR names customers, manufacturers, importers, distributors, dealers, repairers, recyclers, market surveillance authorities, customs authorities, and others, but access is controlled by the rights set in the delegated act. Rights to introduce, modify, or update data are also restricted.
separates public model information from compliance information. Suppliers enter the prescribed data; the public system exposes labels and product information sheets, while market surveillance authorities and the Commission have access to the compliance part.
Build DPP access and update rights from the applicable ESPR delegated act. Build registration and access workflows from the Energy Labelling Regulation and current EPREL operating rules; do not copy one system's permissions into the other.
DPP must be linked to a unique product identifier. Where appropriate it can also link to unique operator and facility identifiers. ESPR requires the passport to be connected through a data carrier and requires that carrier to be physically present on the product, its packaging, or accompanying documentation, as specified by the applicable delegated act.
appears in the source support through energy-label QR access. The JRC label material describes QR codes on energy labels as links to EPREL; it does not establish EPREL as the DPP data carrier or passport identifier system.
DPP is designed as a decentralised data system set up and managed by economic operators, with a Commission-managed registry storing at least unique identifiers and, for customs release, commodity codes. The Commission also has to provide a public web portal for searching and comparing passport data according to access rights.
is an existing Union database/tool that ESPR says the Commission should consider linking to the DPP where feasible. That makes EPREL a possible linked system, not the same as the DPP registry.
Architect integrations as links between systems. Do not collapse the DPP registry, DPP web portal, economic-operator passport data stores, and into one internal data model.
DPP has explicit customs mechanics in ESPR. Once the registry is operational, a person placing a covered product under release for free circulation must provide or make available the unique registration identifier, and customs checks the identifier and commodity code against registry data.
The provided source support does not establish equivalent customs mechanics for EPREL. EPREL may remain relevant to market information for energy-labelled products, but customs-release claims should be tied to the DPP registry when relying on these sources.
DPP can potentially reuse existing product information where the delegated act permits it and the data fits the required passport field, granularity, access level, freshness, and identifier mapping.
data may be a useful source for energy-label and model-level information, but the source support does not support using EPREL as a complete DPP data source for circularity, repair, substances, lifecycle, supply-chain, or customs-registry fields.
Reuse data as a mapped input, not as a compliance shortcut. Keep a field-by-field trace showing the source, passport field, access rule, and update owner.
DPP can sit behind an ESPR label or other product information route. ESPR says labels can include data carriers or other means to access additional information, including the DPP.
is strongly tied to the energy label in the source support: the JRC material describes energy labels with QR codes linking to EPREL, and ESPR says energy labels remain a successful instrument for energy-related products.
For an energy-related product, decide whether ESPR information can be supplementary information on the energy label, whether a separate ESPR label is needed, and whether DPP access belongs on or near that label.
DPP is the ESPR mechanism for making product information available across the value chain. It is expected to improve access to relevant information, end-to-end traceability, and competent-authority work without exposing confidential business information beyond the access rights set for the product group.
is the European Product Registry for Energy Labelling. Its public part provides product information, energy labels, and product information sheets; its compliance part contains specified technical documentation and is accessible to market surveillance authorities and the Commission.
DPP requirements arise under ESPR delegated acts for product groups. Depending on the product-specific rule, the passport can contain sustainability, circularity, traceability, and compliance information.
applies to models covered by energy-labelling delegated acts. The supplier enters the prescribed model information before placing a unit of a new model on the market; the product database does not apply to every product merely because it is energy-related.
Start by asking whether the product is covered by an ESPR delegated act requiring a DPP, whether it is energy-labelled, or both. The overlap is product-specific, not automatic.
DPP data is product-passport data. ESPR says the passport can be specific to the item, batch, or product model, with the level selected in the product-specific delegated act. ETSI describes DPP information as product-specific data conveyed through a unique identifier.
cited support is model-and-label oriented: energy labels identify a model and link via QR code to EPREL for additional technical specifications and information. The provided source support does not support treating EPREL as an item-level lifecycle passport.
Map DPP data at the granularity required by the ESPR delegated act. Reuse model data only where the same attribute, product group, and access need are explicitly supported.
DPP access is role-based. ESPR names customers, manufacturers, importers, distributors, dealers, repairers, recyclers, market surveillance authorities, customs authorities, and others, but access is controlled by the rights set in the delegated act. Rights to introduce, modify, or update data are also restricted.
separates public model information from compliance information. Suppliers enter the prescribed data; the public system exposes labels and product information sheets, while market surveillance authorities and the Commission have access to the compliance part.
Build DPP access and update rights from the applicable ESPR delegated act. Build registration and access workflows from the Energy Labelling Regulation and current EPREL operating rules; do not copy one system's permissions into the other.
DPP must be linked to a unique product identifier. Where appropriate it can also link to unique operator and facility identifiers. ESPR requires the passport to be connected through a data carrier and requires that carrier to be physically present on the product, its packaging, or accompanying documentation, as specified by the applicable delegated act.
appears in the source support through energy-label QR access. The JRC label material describes QR codes on energy labels as links to EPREL; it does not establish EPREL as the DPP data carrier or passport identifier system.
DPP is designed as a decentralised data system set up and managed by economic operators, with a Commission-managed registry storing at least unique identifiers and, for customs release, commodity codes. The Commission also has to provide a public web portal for searching and comparing passport data according to access rights.
is an existing Union database/tool that ESPR says the Commission should consider linking to the DPP where feasible. That makes EPREL a possible linked system, not the same as the DPP registry.
Architect integrations as links between systems. Do not collapse the DPP registry, DPP web portal, economic-operator passport data stores, and into one internal data model.
DPP has explicit customs mechanics in ESPR. Once the registry is operational, a person placing a covered product under release for free circulation must provide or make available the unique registration identifier, and customs checks the identifier and commodity code against registry data.
The provided source support does not establish equivalent customs mechanics for EPREL. EPREL may remain relevant to market information for energy-labelled products, but customs-release claims should be tied to the DPP registry when relying on these sources.
DPP can potentially reuse existing product information where the delegated act permits it and the data fits the required passport field, granularity, access level, freshness, and identifier mapping.
data may be a useful source for energy-label and model-level information, but the source support does not support using EPREL as a complete DPP data source for circularity, repair, substances, lifecycle, supply-chain, or customs-registry fields.
Reuse data as a mapped input, not as a compliance shortcut. Keep a field-by-field trace showing the source, passport field, access rule, and update owner.
DPP can sit behind an ESPR label or other product information route. ESPR says labels can include data carriers or other means to access additional information, including the DPP.
is strongly tied to the energy label in the source support: the JRC material describes energy labels with QR codes linking to EPREL, and ESPR says energy labels remain a successful instrument for energy-related products.
For an energy-related product, decide whether ESPR information can be supplementary information on the energy label, whether a separate ESPR label is needed, and whether DPP access belongs on or near that label.
Use Digital Product Passport when the facts match the left-side scope, trigger, and evidence rows.
Use when the facts match the right-side scope, trigger, and evidence rows.
Reuse controls only where the comparison rows show the same actor, obligation, timing, and evidence basis.
1
Section 1
How to use the comparison
This page is relevant when an energy-labelled product is also being assessed for ESPR/DPP readiness. The comparison is designed to prevent a common architecture mistake: treating , an energy-labelling product database, as though it were the full DPP infrastructure.
ESPR says the Commission should consider linking DPP information requirements to existing Union databases and tools such as where feasible. Plan for linkage rather than substitution. EPREL registration remains a model-level supplier duty with separate public and compliance information, while a DPP must follow the product-specific rules for identifiers, data carriers, access rights, registry upload, availability, security, and passport data.
Use fields as candidate inputs only after mapping the exact DPP field, product granularity, access right, and update owner.
Keep the energy-label QR journey and the DPP data-carrier journey distinct until the product-specific rules and technical design prove they can converge.
Use the Energy Labelling Regulation and current Commission guidance for supplier verification, registration, public fields, compliance fields, and operational deadlines; keep DPP customs claims on the ESPR registry path.
Build a field-level matrix for product identifiers, label data, passport fields, access rights, registry fields, and source ownership before merging DPP and EPREL workstreams.