EU Digital Product Passport Public, Restricted, and Customs Access

Start by separating four views. The public view is the information a customer or other unauthenticated visitor can reach through the data carrier, online listing, or EU web portal. Restricted operational views are for actors such as manufacturers, importers, distributors, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, and other actors named in ESPR Article 11. Authority and customs views must support the legal duties of competent national authorities, the Commission, and customs authorities.

The exact data fields for each product group are not fixed by this generic page. ESPR says access to passport data is regulated by the essential requirements and by the specific access rights set in the applicable delegated act. Treat the delegated act as the binding source for field-level visibility, write-access, and product-model, batch, or item granularity.

A workable DPP access matrix should list each role, the data categories it can read, whether it can add or update any data, the credential or approval needed, and the system that enforces the rule. Public data should not depend on account creation. Restricted views should be tied to authenticated roles, and update rights should be narrower than read rights.

ESPR Article 11 requires free and easy access based on access rights, restricts the right to introduce, modify, or update passport data, and requires data authentication, reliability, integrity, security, privacy, and fraud prevention. Those requirements make access design an audit topic, not only a front-end design choice.

Customs access is not the same as a public product page. ESPR Article 13 creates a Commission-managed DPP registry that stores at least unique identifiers and, for products intended for release for free circulation, the commodity code. The economic operator placing the product on the market or putting it into service uploads the required registry data and receives a unique registration identifier, but ESPR states that this registry response is not proof of compliance.

For customs controls under ESPR Article 15, a person placing a product covered by an Article 4 delegated act under release for free circulation must provide or make available the unique registration identifier once the registry is operational. The registry reached that status on 20 July 2026. The separate rule that customs may release the product only after electronically checking the identifier and commodity code applies when the EU CSW-CERTEX interconnection becomes operational; Article 15 allows up to four years after the Article 13(5) implementing act enters into force for that interconnection.

The public web portal and the product data carrier are different handoffs. ESPR Article 14 requires a publicly accessible web portal where stakeholders can search for and compare DPP data in a manner consistent with their access rights. ESPR Article 10 requires the DPP to be connected through a data carrier to a persistent unique product identifier, and the data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act.

Operationally, the data carrier should resolve to the right DPP endpoint for the specific product model, batch, or item. The portal, resolver, and DPP service should return public data without unnecessary friction, challenge restricted users for credentials, and avoid exposing restricted data through predictable URLs, cached files, search snippets, or unauthenticated APIs.

The evidence file should prove that each audience sees the right data and that customs can verify the registry handoff. Keep evidence at field level rather than only storing a screenshot of the public DPP page. Reviewers should be able to trace each field from delegated-act requirement or internal classification to owner approval, source system, publication state, restricted access rule, and test result.

Link access design to credential lifecycle, supplier data intake, versioning, registry upload, data carrier tests, portal tests, customs test records, and exception handling. Product compliance, IT architecture, trade compliance, and audit teams should work from the same DPP record.