DPPCustoms accessEU

EU Digital Product Passport customs access review workflow

A workflow for checking which DPP data is public, restricted, or available to customs authorities before an ESPR-covered product is imported or released.

Use it to align access rights, registry evidence, portal expectations, and customs release checks. The Commission launched the DPP Registry on 20 July 2026; product-specific registration duties still depend on the applicable EU legislation.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

This workflow helps product, trade compliance, and DPP implementation teams review customs access for an EU Digital Product Passport under the Ecodesign for Sustainable Products Regulation (ESPR). It covers the passport data carrier and unique product identifier, stakeholder access rights set in product-specific delegated acts, the Commission registry, the planned public search portal, and customs checks for . The Registry became operational on 20 July 2026, but a product must be registered only when the applicable ESPR delegated act or other Union legislation requires a DPP and registration.

Section 1

Classify DPP data by access route

Start by separating DPP data into three access routes. Public data is the information stakeholders may read through the product's passport access path and, when available, search or compare through the Commission web portal, subject to the product's access rights. Restricted data is DPP information available only to named actor types under product-specific access rights. Customs access is the authority route for customs duties, including risk management, customs controls, and .

Do not treat the passport as one public document. ESPR requires access to DPP data to be regulated by delegated-act access rights, and it requires free and easy access for listed actors, including customs authorities, based on those respective access rights.

  • Public: fields accessible through the product passport and, when available, searchable or comparable through the Commission portal, within the access rights set for the product group.
  • Restricted: supplier, operator, service-provider, or lifecycle data that needs login, credentials, or role-based access because it is not meant for every stakeholder.
  • Customs: registry and DPP data customs authorities may retrieve and use for duties under Union law, including customs controls and .
  • Not classified yet: any data element whose access rule depends on a product-specific delegated act that is not yet available for the product group.
Section 2

Check the registry and portal handoffs

The registry handoff is not the same as publishing the whole passport. The live Registry stores unique identifiers, registration data, and high-level metadata rather than the full DPP. Commission Implementing Regulation (EU) 2026/1778, published on 17 July 2026 and in force since 6 August 2026, sets rules for registration through a secure user interface or API, automated checks, and generation of a unique and persistent registration identifier.

The public search portal is a separate ESPR service. Article 14 requires the Commission to provide it for searching and comparing DPP data according to product-group access rights; the Commission's July 2026 DPP timeline says that portal is planned for a later launch. Do not record a successful Registry lookup as a public-portal test.

  • Confirm the passport is connected through a data carrier to a persistent unique product identifier.
  • Confirm the product, packaging, or accompanying documentation carries the data carrier location required by the applicable delegated act.
  • Confirm the registry submission covers the required identifier, the model, batch, or item granularity, higher-level identifiers where required by Implementing Regulation (EU) 2026/1778, and the commodity code for products intended for .
  • Keep the unique registration identifier and downloadable proof of registration. Proof of registration shows that the registration duty was fulfilled; it does not establish that the product or the substantive DPP data complies with Union law.
  • Treat public-portal readiness as a separate test until the portal is available, and limit search or comparison fields to the access rights set for the product group.
Recommended next step

Test DPP customs access before import release

This workflow helps check access rights, registry identifiers, portal exposure, and customs handoff evidence before ESPR-covered products reach release-for-free-circulation review.

Section 3

Review customs release readiness without inventing customs fields

For customs release readiness, stay inside the ESPR mechanics. From the Registry's operational launch on 20 July 2026, a person placing a product covered by an ESPR delegated act under the customs procedure for must provide or make available its unique registration identifier. For other products, the same mechanism applies only where the applicable Union legislation requires that customs handoff.

The minimum customs match is the unique registration identifier and commodity code against Registry data. Article 15 makes the electronic and automatic verification obligation depend on the interconnection becoming operational, so teams should confirm the current customs-system route instead of assuming that Registry availability alone proves the automated customs exchange is active. Customs release is not proof of compliance with ESPR or other Union law.

  • Ready: the product is covered by an applicable delegated act and has a DPP available under Articles 9 to 11.
  • Ready: the registry upload exists and the unique registration identifier is available to the importer, broker, or filing team that will provide it to customs.
  • Ready: the commodity code used for customs release is aligned with the commodity code stored in the registry for that product.
  • Blocked: no delegated-act basis identifies the required DPP data or access rights for the product group.
  • Blocked: the review asks for extra customs field mechanics not based on ESPR, such as unverified filing columns, broker scripts, or penalty thresholds.
Section 4

Keep access-control evidence

Close the review with evidence that proves the access model is deliberate. The evidence should show which actor type can see, create, update, or retrieve each field; how public portal data differs from restricted data; and how customs receives the registry identifier needed for .

The evidence should also show that DPP data remains accurate, complete, up to date, reliable, and protected. ESPR requires data authentication, reliability, integrity, security, privacy, and fraud avoidance, and it restricts rights to introduce, modify, or update DPP data based on delegated-act access rights.

  • Access matrix: actor type, field group, action allowed, source of the access right, and whether the field is public, restricted, or customs-accessible.
  • Registry evidence: upload timestamp or record reference, unique product identifier, unique registration identifier, commodity code for release-for-free-circulation products, and owner of the record.
  • Public-access evidence: public passport fields, restricted fields suppressed from public view, and unauthenticated-user test results. Add Commission portal search and comparison evidence when that channel is available for the product.
  • Customs handoff evidence: who provides the unique registration identifier, where the identifier is stored for filing support, and how commodity-code alignment is checked.
  • Change-control evidence: who may introduce, modify, or update DPP data and how reliability, integrity, security, privacy, and fraud controls are tested.
Primary sources

References and citations

eur-lex.europa.eu5 citations
Referenced sections
  • Primary legal source for DPP access rights, registry records, the public web portal, customs controls, and release-for-free-circulation limitations.
  • Supports the public, restricted, and customs access split because ESPR requires DPP access to follow product-group access rights and lists customs authorities among actors with access based on those rights.
  • Supports the registry and portal handoff steps, including unique identifiers, commodity code storage for release for free circulation, and the public portal constrained by access rights.
Show 2 more
  • Supports the customs release readiness criteria: provide the unique registration identifier, verify it with the commodity code against the registry, and avoid treating release as proof of compliance.
  • Supports the access-control evidence list because ESPR restricts DPP update rights by access rights and requires data authentication, reliability, integrity, security, privacy, and fraud avoidance.
"release for free circulation"
More quoted passages
"respective access rights"
"unique registration identifier"
"data authentication, reliability and integrity"
cencenelec.eu3 citations
Referenced sections
  • Standards-body source supporting the practical design focus on data carriers, portal contents, information exchanges, and DPP applications.
  • Supports treating the DPP implementation as a design exercise covering data carriers, portal contents, information exchange, and applications.
  • Supports using a DPP design record for implementation decisions involving data carriers, portal contents, and information exchanges.
"data carrier, information portal contents"
More quoted passages
"information exchanges and applications"
eur-lex.europa.eu2 citations
Referenced sections
  • Registry access, verification, registration, identifier, versioning, logging, and proof-of-registration rules, published on 17 July 2026 and in force since 6 August 2026.
  • Sets Registry verification, registration, versioning, logging, and proof-of-registration rules. It was published on 17 July 2026 and entered into force on 6 August 2026.
single-market-economy.ec.europa.eu2 citations
Referenced sections
  • Official confirmation that the Registry and its testing environment launched on 20 July 2026.
  • Confirms the Registry's operational launch on 20 July 2026 and the availability of a production interface, testing environment, API integration, technical documentation, and registration support.
single-market-economy.ec.europa.eu2 citations
Referenced sections
  • Commission source for DPP implementation context, including availability to consumers, businesses, and relevant public authorities and possible inclusion of conformity documents.
  • Supports the implementation context that the DPP is intended to be available to consumers, businesses, and relevant public authorities, and may host additional information such as instructions or conformity documents.
"relevant public authorities"
More quoted passages
"consumers, businesses and relevant public authorities"
commission.europa.eu2 citations
Referenced sections
  • Commission overview describing the DPP as a digital identity card for products, components, and materials that stores information supporting sustainability, circularity, and legal compliance.
  • Supports the plain-language explanation that the DPP is a digital identity card storing product sustainability information, circularity information, and legal-compliance information.
"digital identity card for products"
single-market-economy.ec.europa.eu
Referenced sections
  • Confirms that the Registry is live and explains that it stores identifiers, registration data, and high-level metadata rather than the complete passport.
Show all related guides (37)

DPP registry and web portal integration under EU ESPR

EU Digital Product Passport Registry and web portal integration guide based on official sources: identifiers, carriers, access rights, providers, and lookup design.

DPP vs Battery Passport: ESPR and Battery Regulation Comparison

Compare the ESPR Digital Product Passport framework with the EU Batteries Regulation battery passport by scope, timing, data, access rights, identifiers, registry, governance, and evidence.

DPP vs EPREL Comparison

Compare the EU Digital Product Passport with EPREL: product-passport scope, energy-label database role, access model, identifiers, data carriers, and overlap limits.

DPP vs GS1 Digital Link: Duties vs Standard

Compare EU Digital Product Passport requirements with GS1 Digital Link: legal scope, identifiers, data carriers, access rights, registry, portal, customs checks, and implementation consequences.

EU Digital Product Passport access: public, restricted, and customs views

How ESPR Digital Product Passport access should be split across public users, restricted actors, authorities, customs, the EU registry, and the web portal.

EU Digital Product Passport API and resolver architecture

DPP architecture guidance for data carriers, product identifiers, resolver lookup paths, access rights, registry integration, and interoperability without premature protocol mandates.

EU Digital Product Passport Applicability Test

Check whether an ESPR delegated act or battery passport rule may require a Digital Product Passport, which operator owns it, and what evidence to keep.

EU Digital Product Passport architecture and integration

Guide to EU Digital Product Passport architecture: data carriers, identifiers, access rights, registry, portal, supplier flows, customs checks, and governance.

EU Digital Product Passport checklist

A concrete EU Digital Product Passport readiness checklist covering product-group scope, passport fields, identifiers, data carriers, access rights, supplier evidence, registry preparation, and publication controls.

EU Digital Product Passport compliance: ESPR requirements

EU Digital Product Passport compliance guide covering ESPR passport data, identifiers, data carriers, access rights, registry readiness, supplier validation, and evidence.

EU Digital Product Passport Data Carriers, Access Control, and UX

How to choose DPP data carriers, identifiers, access rights, and scanning UX under ESPR Articles 9-14, with QR, NFC, RFID, registry, and customs constraints.

EU Digital Product Passport data requirements and fields

How to plan Digital Product Passport data fields under ESPR: delegated-act scope, Annex III data categories, access rights, customs data, and supplier validation.

EU Digital Product Passport deadlines and compliance calendar

EU Digital Product Passport calendar covering the live DPP Registry, ESPR product-rule milestones, and fixed battery passport dates.

EU Digital Product Passport FAQ

Direct answers on EU Digital Product Passport scope, creators, product groups, registry, customs checks, access rights, identifiers, data carriers, and governance.

EU Digital Product Passport identifier and data carrier design

How to design Digital Product Passport identifiers, QR or other data carriers, resolver links, registry records, access paths, and evidence without overclaiming the EU rules.

EU Digital Product Passport penalties and enforcement

How EU Digital Product Passport breaches can lead to national penalties, corrective action, market restrictions, and customs holds under ESPR or battery law.

EU Digital Product Passport Product Group Readiness

Prepare product groups for EU Digital Product Passport rules by tracking ESPR delegated-act status, data fields, suppliers, identifiers, access rights, and registry handoffs.

EU Digital Product Passport requirements under ESPR

Overview of EU Digital Product Passport requirements under ESPR: product-specific delegated acts, data fields, identifiers, carriers, registry, access rights, supplier data validation, and open points.

EU Digital Product Passport supplier data validation controls

Build a supplier data validation file for EU Digital Product Passports: source owner, product link, access class, data model fit, evidence quality, approval record, and release gate.

EU DPP implementation playbook and vendor selection

Select Digital Product Passport vendors against ESPR requirements for identifiers, data carriers, access rights, decentralized storage, registry readiness, portal access, and verification evidence.

EU DPP Product-Group Readiness Checklist

A checklist for preparing a product group for an EU Digital Product Passport delegated act, covering data fields, suppliers, identifiers, carriers, access rights, and registry readiness.

EU DPP QR Code and Data Carrier Implementation Guide

Guidance for using QR codes and other data carriers in EU Digital Product Passport programs, including unique identifiers, access, resolver testing, and evidence.

EU DPP supplier data validation workflow

A workflow for checking supplier data before it is used in an EU Digital Product Passport, covering product linkage, evidence, owners, access class, and approval records.

What is a Digital Product Passport under ESPR?

A visitor-friendly explanation of EU Digital Product Passports under ESPR: product data, identifiers, data carriers, access rights, registry, web portal, and delegated acts.

DPP QR code vs NFC data carrier choices under EU ESPR

How to choose QR code, NFC, or another data carrier for an EU Digital Product Passport without assuming ESPR mandates one universal carrier.

EU DPP customs access: registry, portal, and restricted data

FAQ on customs access under the EU Digital Product Passport: what customs can verify, how the registry and public portal differ, and how access rights limit DPP data.

EU DPP unique identifier requirements: product, operator and facility IDs

FAQ on how ESPR Digital Product Passport identifiers connect products, economic operators, facilities, data carriers, resolvers and registry evidence.

Public vs restricted EU Digital Product Passport data

How to separate public, restricted, authority, and customs access in EU Digital Product Passport designs under ESPR and battery passport rules.

What is the EU Digital Product Passport registry?

FAQ on the ESPR Digital Product Passport registry: what it stores, who uploads data, how identifiers work, and what teams should avoid assuming.

Which products come first for the EU Digital Product Passport?

FAQ on EU Digital Product Passport product priority: batteries have a separate passport rule, while ESPR product groups depend on the working plan and delegated acts.

Who must create an EU Digital Product Passport?

DPP responsibility under the EU ESPR: how manufacturers, importers, distributors, suppliers, service providers, and delegated acts fit together.