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.
Use this FAQ to 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.
Public DPP data is the information that customers and other stakeholders should be able to find without a private access gate. Restricted DPP data is information that only named actors should see or update, such as repairers, recyclers, market surveillance authorities, customs authorities, notified bodies, or persons with a legitimate interest where a sector rule says so. The exact access map is not universal: ESPR requires product-group delegated acts to specify the data, the actors with access, and the actors allowed to create or update passport data.
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 delegated act 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 delegated act 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 delegated act can set a longer period where needed. | The registry must be operational by 19 July 2026, and customs checks start only when the registry-to-customs connection is operational. | Treat publication timing, registry timing, and customs timing as separate implementation milestones. |
| Enforcement | Public data issues are mainly publication-quality issues: missing fields, unclear labels, or data that should have been public but was not presented accessibly. | Restricted data issues can trigger market-surveillance action, formal non-compliance findings, and penalties when access controls or update rights are not respected. | Enforcement is about compliance checking and penalties, not about deciding which fields are public. |
| 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 delegated act makes it public. | If a field supports repair, conformity, customs, or surveillance work, check whether the delegated act 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 delegated act 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 delegated act can set a longer period where needed.
The registry must be operational by 19 July 2026, and customs checks start only when the registry-to-customs connection is operational.
Treat publication timing, registry timing, and customs timing as separate implementation milestones.
Public data issues are mainly publication-quality issues: missing fields, unclear labels, or data that should have been public but was not presented accessibly.
Restricted data issues can trigger market-surveillance action, formal non-compliance findings, and penalties when access controls or update rights are not respected.
Enforcement is about compliance checking and penalties, not about deciding which fields are public.
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 delegated act makes it public.
If a field supports repair, conformity, customs, or surveillance work, check whether the delegated act 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 delegated act. 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.
The practical rule is therefore to build an access matrix before publishing the passport. Each data field should be marked as public, restricted to defined value-chain actors, restricted to authorities or notified bodies, registry-only, customs-relevant, or not yet supported by the applicable product rule.
Articles 9 to 11 require delegated acts to define passport data, actor access, update rights, and essential technical safeguards.
Recital 33 explains why DPPs need differentiated access by data type and stakeholder typology.
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 is not the same thing as the public DPP web portal. The registry is a Commission-managed system that securely stores at least unique identifiers, and for products released for free circulation it also stores the commodity code. Economic operators upload the required registry 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.
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"