Who Sees What in a Digital Product Passport: Access Rights, Customs and Confidential Business Data

A Digital Product Passport is often pictured as a QR code that opens a public web page. That picture is wrong in a way that matters for compliance. ESPR is built around role-based access: different people see different parts of the passport, and some data is never meant to reach the public at all. If you are designing a passport now, the access model is as important as the data model.

Who gets which view

The European Commission's DPP page describes a system where different users access the information relevant to them by scanning the data carrier. The groups it names are:

• Consumers, who get key product information to support purchasing decisions.
• Repairers and recyclers, who retrieve the information relevant to their activities.
• Public authorities, who verify compliance and support market surveillance.
• Customs, who can check the unique registration identifiers of imported products.

The Commission overview does not spell out the confidentiality rules in detail. That detail comes from the product-specific delegated acts, each of which defines which data fields sit in which access tier. In other words, there is no single universal list of who may see what; it is set category by category.

What the standards do and do not settle

The CEN/CENELEC technical committee JTC 24 developed eight system-level standards for DPPs. According to the idpp.net standards guide, six were published on 27 May 2026 and two are still expected around autumn 2026. The two outstanding ones are the ones that matter here: FprEN 18239 on access rights, security and confidentiality, and FprEN 18246 on data authentication, trustworthiness and integrity.

The guide stresses that these standards define how the system works rather than what data appears in a passport. So even when both are final, they will give you the mechanisms for tiering and authenticating access, but not the decision about which fields are public. Until they are published, teams can design against the draft titles but should not claim conformity.

Confidential business information

Manufacturers worry, reasonably, that a passport will expose supplier identities, formulations or cost structure. The practical answer is classification. Sort every candidate data field into one of three buckets: required for the public, required for authorities or professionals only, and not required at all. Only the first two belong in the passport, and the second bucket is where access control earns its keep. If a delegated act requires a field to be public, a confidentiality argument will not remove it, so the time to engage is during the consultation on the act, not after adoption.

Customs is the quiet access role

Customs is the access right most likely to be overlooked, because it works differently. Rather than reading your passport content, customs checks that a product's identifier is registered. That ties access to registration: a product that is not in the registry cannot be verified at the border. Full customs system integration is anticipated around 2029, according to registration guidance published by euverify, so this is a planning item rather than an immediate blocker.

What to do now

Build the passport so that access tiers are a property of each field, not an afterthought bolted onto a finished page. Ask any DPP service provider how they implement role-based access and which authentication model they support, and whether they plan to align with FprEN 18239 and 18246 once those are final. Finally, keep an inventory of the data you consider commercially sensitive, so that when a delegated act lands you can compare it to your own classification within days instead of months.

The honest summary is that the framework for access exists, the technical standards for it are nearly complete, and the field-by-field answers will arrive one product group at a time.