EU Digital Product Passport Public vs restricted passport data
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.
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.
Access model
Public vs restricted passport data
Compare the main DPP visibility categories teams need to separate before publishing, sharing, or registering passport data.
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.
Annex XIII lists battery model information accessible to the public.
accessible to the public
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.
Article 14 establishes the public web portal for search and comparison under access rights.
publicly accessible web portal
Registry and customs flows use unique identifiers, unique registration identifiers, and commodity codes for verification and release-for-free-circulation controls.
Article 9 requires DPP data to be accurate, complete, and up to date.
accurate, complete and up to date
Restricted data governance focuses on authentication, purpose limitation, update permissions, integrity, security, privacy, and protection of confidential business information.
Article 14 establishes the public web portal for searching and comparing DPP data.
search for and compare
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.
Article 11 requires free and easy access based on respective access rights.
free of charge and easy access
Battery access examples
Public passport data
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.
Annex XIII lists battery model information accessible to the public.
accessible to the public
Restricted passport data
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.
Article 14 establishes the public web portal for search and comparison under access rights.
publicly accessible web portal
Restricted passport data
Registry and customs flows use unique identifiers, unique registration identifiers, and commodity codes for verification and release-for-free-circulation controls.
Article 9 requires DPP data to be accurate, complete, and up to date.
accurate, complete and up to date
Restricted passport data
Restricted data governance focuses on authentication, purpose limitation, update permissions, integrity, security, privacy, and protection of confidential business information.
Article 14 establishes the public web portal for searching and comparing DPP data.
search for and compare
Restricted passport data
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.
Battery passport Annex XIII provides a concrete example of field-level access tiering.
accessible only to persons with a legitimate interest
Search this module
Find a question or answer quickly
5 of 5 questions
Question 1
What is the rule for public versus restricted DPP data?
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.
Public data should support customer access, comparison, circularity decisions, and other public uses named in the product rule.
Restricted data should be limited to the actors that need it for repair, reuse, recycling, conformity, market surveillance, customs, or another specified role.
Update rights are separate from read rights: ESPR requires rights to introduce, modify, or update passport data to be restricted according to access rights.
Do not publish confidential business information simply because it sits in the passport data model; ESPR expressly requires differentiated access and protection of confidential business information.
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.
specific access rights at product group level
Question 2
Which access categories should a DPP team design for?
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.
Public model data: consumer-facing and comparison data, such as the categories made public for battery models.
Restricted legitimate-interest data: operational detail such as dismantling, spare parts, safety measures, or individual item status where the sector rule grants access.
Authority and notified-body data: conformity evidence such as test report results when the rule reserves it for notified bodies, market surveillance authorities, and the Commission.
Customs data: identifiers and commodity codes used to verify imported products against the DPP registry, not a general public disclosure channel.
The CEN-CENELEC guidance describes public access without logins and restricted access through software roles or authentication.
software user roles can be set
Recommended next step
Turn DPP access rules into an evidence matrix
Map each passport field to its legal source, role-based visibility, update rights, registry handling, and customs evidence before exposing public DPP data.
How do the registry, web portal, and customs checks differ?
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.
Registry: at least unique identifiers, plus commodity code for products intended for release for free circulation.
Web portal: public search and comparison, limited by each stakeholder's access rights.
Customs: electronic verification of the unique registration identifier and commodity code begins only when the separate EU CSW-CERTEX interconnection is operational.
Evidence implication: keep registry upload records, the returned unique registration identifier, commodity-code mapping, and the access-rights matrix together.
Confirms the 20 July 2026 Registry launch, current testing environment, registration channels, and decentralised storage of complete product data.
Question 4
What evidence should teams keep?
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.
A DPP data inventory mapped to the applicable or sector rule.
An access-rights matrix by field, actor, purpose, read permission, update permission, and authentication method.
A confidential-business-information review for data proposed for public display.
Registry evidence: uploaded identifiers, commodity code where relevant, and the returned unique registration identifier.
Customs evidence: process controls for making the unique registration identifier available when a covered product is released for free circulation.
Change-control evidence showing who created, modified, or updated each restricted passport field.
Primary legal source for DPP data, access rights, update rights, registry, web portal, and customs controls.
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.
Articles 13 to 15 establish the registry, public web portal, and customs-control linkage for DPP identifiers and commodity codes.
Show 24 more
Articles 10 and 11 require open, interoperable data, protection of personal data, restricted update rights, data integrity, security, and privacy.
ESPR is the primary source for DPP data access, update rights, registry handling, and customs controls.
Article 9 requires delegated acts to specify DPP data and actor access.
Article 9 also requires delegated acts to specify who may create or update passport data.
Article 10 ties data access to product-group access rights.
Article 11 requires free and easy access based on respective access rights.
Article 14 establishes the public web portal for search and comparison under access rights.
Articles 13 and 15 govern registry and customs identifier checks.
Article 15 says customs release is not proof of compliance with ESPR or other Union law.
Article 9 requires DPP data to be accurate, complete, and up to date.
Article 11 requires restricted update rights, data integrity, security, privacy, and fraud prevention.
Recital 32 frames DPP access without endangering confidential business information.
Article 9 requires the passport to remain available for at least the expected lifetime of the product.
Article 15 ties automatic customs verification to the EU CSW-CERTEX interconnection and gives that interconnection a separate timetable.
The registry and customs controls are phased separately from passport access and data-retention rules.
Article 14 establishes the public web portal for searching and comparing DPP data.
Articles 69, 71, and 74 cover market-surveillance measures, formal non-compliance, and penalties.
The enforcement chapter separates corrective action, formal non-compliance, and penalties from the access-rights rules.
The public portal and registry are separate systems with different functions.
The registry, customs checks, and enforcement files can use the same underlying product data for different purposes.
Articles 13 to 15 and 67 show how registry and customs data can be reused in different workflows.
Article 14 gives the public portal a search and comparison function.
Articles 9 to 11 and 13 to 15 cover access rights, update rights, registry use, and customs controls.
The decision rule should follow the legal function of the field rather than a generic template.
"based on their respective access rights"
More quoted passages
"specific access rights at product group level"
"the registry shall store the commodity code"
"data authentication, reliability and integrity"
"actors that are to have access"
"create a digital product passport or update"
"specified in the applicable delegated act"
"free of charge and easy access"
"publicly accessible web portal"
"unique registration identifier"
"not be deemed to be proof of compliance"
"accurate, complete and up to date"
"rights to introduce, modify or update data"
"without endangering the protection"
"at least the expected lifetime"
"from the moment that interconnection is operational"
"the first subparagraph of this paragraph shall apply from the moment the registry is operational"
"search for and compare"
"effective, proportionate and dissuasive"
"formal non-compliance"
"retrieve and use the data included in the digital product passport"
Technical guidance used for role-based access design, public access without login, registry/searchability distinctions, and DPP information exchange management.
The CEN-CENELEC guidance describes public access without logins and restricted access through software roles or authentication.
The guidance describes the central registry as a lookup database for identifiers and commodity codes and distinguishes it from the DPP web portal.
Show 3 more
The guidance links restricted DPP data to logins or authentication and says public data should be available without personal data collection.
The guidance says public data should be available without logins and personal data collection.
The guidance links restricted data to software roles, logins, or authentication.
"publicly available and which information on a restricted basis"
More quoted passages
"software user roles can be set"
"lookup database with the identifiers and commodity codes"