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.
Supports DPP as the ESPR tool for value-chain product information, traceability, differentiated access, and competent-authority use.
making information available to actors along the entire value chain
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.
ESPR says DPP requirements are specified through delegated acts and access rights, so an EPREL record alone should not be treated as passport compliance.
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.
Defines the DPP scope around product-related data for sustainability, circularity, value retention, recycling, and legal compliance.
sustainability, circularity, value retention for reuse
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.
Article 4 limits the model-registration duty to new models covered by an energy-labelling delegated act and requires registration before market placement.
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.
Defines a digital product passport as structured product-specific data conveyed through a unique identifier.
structured collection of product-specific data
is model-and-label oriented: energy labels identify a model and link via QR code to EPREL for additional technical specifications and information. An energy-label model record should not be treated as an item-level lifecycle passport.
Supports the energy-label QR link to EPREL and the model identifier context on energy-label layouts.
MODEL IDENTIFIER
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.
Lists actors with DPP access and requires access and update rights to follow delegated-act rules.
based on their respective access rights
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.
Current operational guidance for supplier registration and the public and authority-facing EPREL systems.
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.
Defines DPP architecture around a unique product identifier and data carrier.
accessible via electronic means through a Data Carrier
Energy-label QR codes provide access to model information. 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.
Supports the decentralised DPP design, Commission registry, registry contents, and public web portal.
based on a decentralised data system
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.
Names EPREL as an existing Union database/tool that may be linked where feasible.
link the digital product passport to existing Union databases
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. The automated requirement for customs to check the identifier and commodity code against registry data applies when the EU CSW-CERTEX interconnection is operational.
Supports DPP registry customs checks for unique registration identifier and commodity code.
customs authorities may release a product
registration does not by itself establish that the ESPR customs identifier handoff has been completed. Keep the DPP Registry identifier and commodity-code evidence separately.
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.
Supports policy-coherence concerns and reducing duplicate effort when DPP data overlaps with existing databases such as EPREL.
Some data requirements are already fulfilled
data can supply energy-label and model-level information. Map those fields to the applicable DPP rule and obtain separate inputs for any required circularity, repair, substances, lifecycle, supply-chain, or customs-registry fields.
Supports EPREL as a source of energy-label-linked technical information, not a complete DPP substitute.
additional technical specifications and information
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.
Supports labels including data carriers or other means to access additional product information and the DPP.
including means allowing access to the digital product passport
is tied to the energy label: 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.
Supports the continued parallel role of energy labels for energy-related products.
Energy labels are a successful instrument
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.
Supports assessing whether ESPR information should be integrated into an energy label or handled through a separate ESPR label.
incorporate classes of performance
Scope boundary
Digital Product Passport
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.
Supports DPP as the ESPR tool for value-chain product information, traceability, differentiated access, and competent-authority use.
making information available to actors along the entire value chain
EPREL
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.
ESPR says DPP requirements are specified through delegated acts and access rights, so an EPREL record alone should not be treated as passport compliance.
as specified in the delegated act
Product coverage
Digital Product Passport
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.
Defines the DPP scope around product-related data for sustainability, circularity, value retention, recycling, and legal compliance.
sustainability, circularity, value retention for reuse
EPREL
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.
Article 4 limits the model-registration duty to new models covered by an energy-labelling delegated act and requires registration before market placement.
Operational implication
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.
Explains that products can sit under both ESPR label considerations and the energy-labelling framework.
covered by both Regulation (EU) 2017/1369
Data granularity
Digital Product Passport
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.
Defines a digital product passport as structured product-specific data conveyed through a unique identifier.
structured collection of product-specific data
EPREL
is model-and-label oriented: energy labels identify a model and link via QR code to EPREL for additional technical specifications and information. An energy-label model record should not be treated as an item-level lifecycle passport.
Supports the energy-label QR link to EPREL and the model identifier context on energy-label layouts.
MODEL IDENTIFIER
Operational implication
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 granularity and data content depend on the applicable delegated act, so EPREL reuse needs an attribute-level mapping.
what data are to or can be included
Data access and entry rights
Digital Product Passport
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.
Lists actors with DPP access and requires access and update rights to follow delegated-act rules.
based on their respective access rights
EPREL
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.
Current operational guidance for supplier registration and the public and authority-facing EPREL systems.
Operational implication
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.
Supports the need to implement DPP access controls rather than assuming energy-label database access rules apply.
rights to introduce, modify or update data
Identifiers and data carriers
Digital Product Passport
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.
Defines DPP architecture around a unique product identifier and data carrier.
accessible via electronic means through a Data Carrier
EPREL
Energy-label QR codes provide access to model information. 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.
Supports keeping DPP identifier and data-carrier rules separate from energy-label QR implementation.
unique identifiers and data carriers
Infrastructure and integration
Digital Product Passport
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.
Supports the decentralised DPP design, Commission registry, registry contents, and public web portal.
based on a decentralised data system
EPREL
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.
Names EPREL as an existing Union database/tool that may be linked where feasible.
link the digital product passport to existing Union databases
Operational implication
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.
Supports treating the DPP registry and web portal as distinct ESPR infrastructure rather than EPREL replacements.
publicly accessible web portal
Enforcement
Digital Product Passport
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. The automated requirement for customs to check the identifier and commodity code against registry data applies when the EU CSW-CERTEX interconnection is operational.
Supports DPP registry customs checks for unique registration identifier and commodity code.
customs authorities may release a product
EPREL
registration does not by itself establish that the ESPR customs identifier handoff has been completed. Keep the DPP Registry identifier and commodity-code evidence separately.
Supports treating customs-release checks as DPP-registry obligations when these cited sources are used.
EU Customs Single Window
Overlap and reuse
Digital Product Passport
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.
Supports policy-coherence concerns and reducing duplicate effort when DPP data overlaps with existing databases such as EPREL.
Some data requirements are already fulfilled
EPREL
data can supply energy-label and model-level information. Map those fields to the applicable DPP rule and obtain separate inputs for any required circularity, repair, substances, lifecycle, supply-chain, or customs-registry fields.
Supports EPREL as a source of energy-label-linked technical information, not a complete DPP substitute.
additional technical specifications and information
Operational implication
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 fields and access rights are delegated-act dependent, so reuse needs field-level evidence.
access rights at product group level
Labels and information access
Digital Product Passport
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.
Supports labels including data carriers or other means to access additional product information and the DPP.
including means allowing access to the digital product passport
EPREL
is tied to the energy label: 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.
Supports the continued parallel role of energy labels for energy-related products.
Energy labels are a successful instrument
Operational implication
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.
Supports assessing whether ESPR information should be integrated into an energy label or handled through a separate ESPR label.
incorporate classes of performance
Practical decision rule
Practical decision rule
Check whether an applicable ESPR delegated act requires a DPP for the product and what passport level, fields, and access rights it sets.
Check the applicable energy-labelling delegated act and registration requirements for the product model.
If both apply, map reusable model data field by field and preserve separate registration and DPP Registry evidence.
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.
Primary legal source for supplier model registration and the separate public and compliance parts of the product database.
Recommended next step
Map DPP and EPREL data before implementation
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.
Primary source for DPP scope, access rights, unique identifiers, data carriers, registry, web portal, customs checks, and EPREL linkage language.
Primary legal source for DPP requirements, access rights, registry design, and possible linkage to EPREL.
Supports DPP as the ESPR tool for value-chain product information, traceability, differentiated access, and competent-authority use.
Show 17 more
ESPR says DPP requirements are specified through delegated acts and access rights, so an EPREL record alone should not be treated as passport compliance.
Supports item, batch, or product-model granularity for DPP data depending on product-specific rules.
DPP granularity and data content depend on the applicable delegated act, so EPREL reuse needs an attribute-level mapping.
Lists actors with DPP access and requires access and update rights to follow delegated-act rules.
Supports the need to implement DPP access controls rather than assuming energy-label database access rules apply.
Supports the DPP link to unique product identifiers and access through a data carrier.
Supports keeping DPP identifier and data-carrier rules separate from energy-label QR implementation.
Supports the decentralised DPP design, Commission registry, registry contents, and public web portal.
Names EPREL as an existing Union database/tool that may be linked where feasible.
Supports treating the DPP registry and web portal as distinct ESPR infrastructure rather than EPREL replacements.
Supports DPP registry customs checks for unique registration identifier and commodity code.
The same ESPR source ties customs mechanics to the DPP registry, not to EPREL in the available source support.
Supports treating customs-release checks as DPP-registry obligations when these cited sources are used.
Supports linking DPP to existing Union databases where feasible while preserving DPP requirements.
DPP fields and access rights are delegated-act dependent, so reuse needs field-level evidence.
Supports labels including data carriers or other means to access additional product information and the DPP.
Supports the continued parallel role of energy labels for energy-related products.
"link the digital product passport to existing Union databases"
More quoted passages
"European Product Registry for Energy Labelling (EPREL)"
"making information available to actors along the entire value chain"
"as specified in the delegated act"
"specific to the item, batch or product model"
"what data are to or can be included"
"based on their respective access rights"
"rights to introduce, modify or update data"
"linked to a unique product identifier"
"unique identifiers and data carriers"
"based on a decentralised data system"
"publicly accessible web portal"
"customs authorities may release a product"
"data stored in the registry"
"EU Customs Single Window"
"Where feasible"
"access rights at product group level"
"including means allowing access to the digital product passport"
Primary legal source for EPREL supplier registration duties, database structure, access boundaries, and purposes.
Primary legal source for supplier model registration and the separate public and compliance parts of the product database.
Articles 4 and 12 establish supplier registration duties and the public, compliance, and portal parts and purposes of the product database.
Show 2 more
Article 4 limits the model-registration duty to new models covered by an energy-labelling delegated act and requires registration before market placement.
Articles 4 and 12 establish supplier data entry and separate the public and compliance parts and their access rules.
Supports the limited reuse point: some DPP data requirements may already be fulfilled by existing databases such as EPREL, but this is an integration claim rather than a substitution claim.
Supports policy-coherence concerns and reducing duplicate effort when DPP data overlaps with existing databases such as EPREL.