Do not treat the DPP as one public web page. ESPR expects access to be differentiated by data type and stakeholder role, with product-specific delegated acts deciding who can see or update each data set.
This FAQ helps classify public consumer data, restricted value-chain data, authority-only evidence, registry records, and customs information without exposing confidential business information.
Structured answer sets in this page tree.
Cited legal and guidance references.
There is no universal public-versus-restricted field list for every EU Digital Product Passport. Under ESPR, the applicable product-group specifies the passport data, who may read each field, and who may create or update it. Separate legislation can use a different access model: the Batteries Regulation, for example, defines public, authority-only, and legitimate-interest categories.
Compare the main DPP visibility categories teams need to separate before publishing, sharing, or registering passport data.
Data intended for customer, stakeholder, search, and comparison use under the applicable or sector rule.
Data limited to specific actors, authorities, notified bodies, customs uses, or legitimate-interest users according to the applicable rule.
| Dimension | Public passport data | Restricted passport data | Operational implication |
|---|---|---|---|
| Scope boundary | The product-group or sector rule decides which DPP fields are public. | The same rule decides which actors can access restricted data and which actors can create or update it. | Do not make access decisions from a generic DPP template; cite the product rule for each field. |
| Covered actors | Public DPP data should be reachable through the data carrier or public portal without unnecessary login or personal data collection. | Restricted DPP data should use role-based access, login, authentication, or digital credentials suitable for the actor and data sensitivity. | Build separate public and restricted views rather than hiding all data behind one account wall or exposing all fields on one public page. |
| Trigger | Battery model information such as material composition, carbon footprint information, recycled content, rated capacity, voltage, power capability, lifetime, warranty period, and waste-battery management information is listed as publicly accessible. | Battery detailed composition, spare-part source details, dismantling information, safety measures, test report results, and individual-battery state data are assigned to narrower access groups. | Use the battery model as proof that DPP access is field-specific, not simply public versus secret. |
| Core obligations | Public portal visibility is for search and comparison according to access rights; it is not the customs verification record. | Registry and customs flows use unique identifiers, unique registration identifiers, and commodity codes for verification and release-for-free-circulation controls. | Keep public content governance separate from registry upload controls and customs broker handoff controls. |
| Evidence record | Public data governance focuses on accuracy, completeness, accessibility, comparison, stable links, and avoiding unnecessary personal data collection. | Restricted data governance focuses on authentication, purpose limitation, update permissions, integrity, security, privacy, and protection of confidential business information. | A complete DPP evidence file needs both a publication review and an access-control review. |
| Timing and deadlines | The passport should stay available for at least the expected lifetime of the product, and the can set a longer period where needed. | The Registry launched on 20 July 2026. Automatic customs matching starts only when the separate registry-to-customs interconnection is operational. | Treat passport publication, Registry registration, and automatic customs verification as separate implementation milestones. |
| Enforcement | A missing or inaccessible public field can make the passport inconsistent with the applicable . | Improper access or update rights can also breach the or ESPR's technical requirements. Authorities can require corrective action, while penalties are set under Member State rules. | Use the to classify the field, then test both publication and access controls against that classification. |
| Overlap and reuse | The same data field can be public in the portal and still need to be stored in the registry or cited in technical documentation. | Restricted fields can be reused across registry checks, customs checks, and market-surveillance files without becoming public by default. | Reuse the field, not the access rule: one field can serve several processes under different visibility rules. |
| Practical decision rule | If a field helps consumers compare products, start by checking whether the makes it public. | If a field supports repair, conformity, customs, or surveillance work, check whether the limits access or update rights. | Classify each field by its primary use first, then confirm the access rule in the applicable legal text. |
The product-group or sector rule decides which DPP fields are public.
The same rule decides which actors can access restricted data and which actors can create or update it.
Do not make access decisions from a generic DPP template; cite the product rule for each field.
Public DPP data should be reachable through the data carrier or public portal without unnecessary login or personal data collection.
Restricted DPP data should use role-based access, login, authentication, or digital credentials suitable for the actor and data sensitivity.
Build separate public and restricted views rather than hiding all data behind one account wall or exposing all fields on one public page.
Battery model information such as material composition, carbon footprint information, recycled content, rated capacity, voltage, power capability, lifetime, warranty period, and waste-battery management information is listed as publicly accessible.
Battery detailed composition, spare-part source details, dismantling information, safety measures, test report results, and individual-battery state data are assigned to narrower access groups.
Use the battery model as proof that DPP access is field-specific, not simply public versus secret.
Public portal visibility is for search and comparison according to access rights; it is not the customs verification record.
Registry and customs flows use unique identifiers, unique registration identifiers, and commodity codes for verification and release-for-free-circulation controls.
Keep public content governance separate from registry upload controls and customs broker handoff controls.
Public data governance focuses on accuracy, completeness, accessibility, comparison, stable links, and avoiding unnecessary personal data collection.
Restricted data governance focuses on authentication, purpose limitation, update permissions, integrity, security, privacy, and protection of confidential business information.
A complete DPP evidence file needs both a publication review and an access-control review.
The passport should stay available for at least the expected lifetime of the product, and the can set a longer period where needed.
The Registry launched on 20 July 2026. Automatic customs matching starts only when the separate registry-to-customs interconnection is operational.
Treat passport publication, Registry registration, and automatic customs verification as separate implementation milestones.
A missing or inaccessible public field can make the passport inconsistent with the applicable .
Improper access or update rights can also breach the or ESPR's technical requirements. Authorities can require corrective action, while penalties are set under Member State rules.
Use the to classify the field, then test both publication and access controls against that classification.
The same data field can be public in the portal and still need to be stored in the registry or cited in technical documentation.
Restricted fields can be reused across registry checks, customs checks, and market-surveillance files without becoming public by default.
Reuse the field, not the access rule: one field can serve several processes under different visibility rules.
If a field helps consumers compare products, start by checking whether the makes it public.
If a field supports repair, conformity, customs, or surveillance work, check whether the limits access or update rights.
Classify each field by its primary use first, then confirm the access rule in the applicable legal text.
Under ESPR, a digital product passport must contain the data specified in the applicable product-group . That delegated act must state which actors have access to which data, who can create or update passport data, and how long the passport remains available.
Build an access matrix before publishing the passport. Mark each data field as public, restricted to defined value-chain actors, restricted to authorities or notified bodies, registry-only, customs-relevant, or unsupported by the applicable product rule.
Articles 9 to 11 require delegated acts to define passport data, actor access, update rights, and technical safeguards; the recitals explain the need for differentiated access without exposing confidential business information.
A useful DPP access design separates the public portal experience from the restricted operational layer. Public data should be reachable without unnecessary login friction. Restricted data should require authentication or equivalent controls tied to the actor's role.
The battery passport shows why this matters. Annex XIII to the Batteries Regulation divides passport content into public model-level information, information for persons with a legitimate interest and the Commission, information only for notified bodies, market surveillance authorities and the Commission, and individual-battery data for persons with a legitimate interest.
Annex XIII gives a concrete battery passport example with public, legitimate-interest, authority-only, and individual-battery access tiers.
The CEN-CENELEC guidance describes public access without logins and restricted access through software roles or authentication.
Map each passport field to its legal source, role-based visibility, update rights, registry handling, and customs evidence before exposing public DPP data.
The ESPR Registry and the public DPP web portal serve different functions. The Registry went live on 20 July 2026 and stores identifiers and required registration metadata. Under ESPR it stores at least unique identifiers, and for products intended for release for free circulation it also stores the commodity code. Economic operators upload the required data, and the Registry returns a unique registration identifier.
The web portal is the public search and comparison layer. It must allow stakeholders to search and compare passport data consistently with the access rights set in delegated acts. Customs controls use the registry and passport data for risk management, customs controls, and release for free circulation.
Articles 13 to 15 establish the registry, public web portal, and customs-control linkage for DPP identifiers and commodity codes.
The guidance describes the central registry as a lookup database for identifiers and commodity codes and distinguishes it from the DPP web portal.
Confirms the 20 July 2026 Registry launch, current testing environment, registration channels, and decentralised storage of complete product data.
Keep evidence that proves the access decision for each data field. A visitor, auditor, authority, supplier, repairer, or customs broker should be able to see why a field was public, restricted, authority-only, customs-relevant, or excluded from publication.
The evidence should also show who can change passport data. Read access for a recycler, repairer, authority, or customer does not automatically mean write access.
Articles 10 and 11 require open, interoperable data, protection of personal data, restricted update rights, data integrity, security, and privacy.
The guidance links restricted DPP data to logins or authentication and says public data should be available without personal data collection.
ESPR is the primary source for DPP data access, update rights, registry handling, and customs controls.
Battery passport Annex XIII provides a concrete example of field-level access tiering.
"restricted data who has access"
"accessible only to persons with a legitimate interest"
"based on their respective access rights"