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, the person placing a covered product under the customs procedure for release for free circulation must provide or make available the unique registration identifier. Customs authorities may release the product only after verifying at minimum that this identifier and the commodity code correspond to registry data. The registry is to be interconnected with EU CSW-CERTEX through the EU Single Window Environment for Customs for automated exchange with national customs systems.

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.

The strongest audit trail links access design to operating controls: credential lifecycle, supplier data intake, versioning, registry upload, data carrier tests, portal tests, customs test records, and exception handling. This makes the page useful for product compliance, IT architecture, trade compliance, and audit teams working from the same DPP record.