Public, Restricted, Authority: Who Is Actually Allowed to Read Your Product Passport

Most first attempts at a Digital Product Passport publish everything. The reasoning is understandable and it sounds like the right instinct: transparency is the point of the regulation, we have nothing to hide, so put the whole record on the page and let anyone who scans the code read it.

That is not a more generous passport. It is your supplier facility list, your due diligence documentation and your conformity file, published permanently to anyone with a phone, including the competitor who has been trying to find out who makes your product for four years.

It is also not what the regulation asks for. Article 10 of ESPR, Regulation (EU) 2024/1781, requires the passport to differentiate what each audience may read. Differentiated access is a requirement, not an option you can decline by being open.

Three audiences, not two

The tier model that both ESPR and the battery dataset work with has three levels, and the middle one is the one people forget.

Public. Anyone who scans the carrier. A consumer in a shop, a journalist, a competitor, a bot.

Legitimate interest. Repairers, remanufacturers, recyclers, second life operators, and the Commission. These are the people the circular economy actually runs on, and the whole reason the passport exists is that they currently cannot get the data they need.

Authority. Notified bodies, market surveillance authorities, customs, and the Commission.

Regulation (EU) 2023/1542, the Batteries Regulation, splits its Annex XIII dataset across exactly these three audiences, which is useful because it is the one dataset you can read rather than predict. It is adopted law, and it applies from 18 February 2027 to LMT batteries, electric vehicle batteries and rechargeable industrial batteries above 2 kWh.

What actually sits in each tier

Working from the battery dataset, because it is the concrete one:

Public. The unique battery identifier. The manufacturer. The battery category and model. The date and place of manufacture. Chemistry and materials including critical raw materials. Recycled content, declared per recovered metal rather than as one blended figure. Hazardous substances. Carbon footprint. Expected lifetime and performance parameters. Separate collection and end of life information, including what the end user is meant to do with the battery.

Notice how much of that is public. This is not a regulation that lets you publish a product name and call it a passport. Hazard information in particular is public because it exists to be read by whoever ends up handling the thing, which may be somebody who never bought it.

Legitimate interest. The manufacturing facility identifier. State of health and state of charge. Dismantling and safe removal information.

Each of those three is restricted for a different reason, and the reasons are worth separating.

Facility level detail is restricted because it is commercially sensitive. Which plant makes your product is often the single most valuable fact about your supply chain, and the granular supply chain data is reserved for restricted audiences rather than published.

State of health is restricted because it is per unit operational data about a specific physical battery in somebody's possession, and it serves second life, remanufacture and recycling operators specifically.

Dismantling information is restricted because it is addressed to repairers, remanufacturers and recyclers rather than to consumers. It is not secret. It is aimed, and a consumer prying open a traction pack because the passport told them how is a safety outcome nobody wanted.

Authority. Conformity documentation and test reports. The supply chain due diligence report.

These are the documents an inspector asks for. They are not consumer reading, and publishing them does not make you more transparent, it makes your regulatory file searchable.

Why publishing everything is a one way door

The asymmetry here is what makes this worth getting right the first time.

A field you withheld and should have published is a complaint, a correction, and a fix that ships the same afternoon. A field you published and should have withheld is on somebody's server, in a crawler's index, and in a competitor's spreadsheet within a week. There is no unpublish.

So over restricting is the safe direction to be wrong in, and a well built passport takes it. Where the assignment of a specific field between the two restricted tiers is a reading rather than a quotation from the text, the honest move is to say so and hold it at the tighter tier until the act says otherwise.

The same logic applies to product groups with no adopted delegated act at all. If a field's access split is not yet fixed in law, publishing it now on the assumption that it will be public later is a bet you cannot undo if you are wrong.

The rule that stops the whole model collapsing

Here is the implementation detail that decides whether a tier model is real or decorative.

A tier is a grant. It can never be claimed in a request.

A URL like passport.example.com/01/09506000134352?tier=authority is an anonymous stranger asserting who they are. If that string elevates what the page shows, you have not built access tiers, you have built a page with a query parameter that turns off the redaction. Tiers have to come from an authenticated decision about who this person is, made somewhere that can actually establish it, and the code that renders the passport should have no way to parse a tier out of user input at all. If you find yourself wanting that function, what you want is authentication.

The nesting question comes up here too. Should an authority automatically see everything a repairer can see? The dataset treats the two as distinct audiences rather than as nested ones, but nesting them is the right call in practice, because you should compare the failure modes rather than the labels. An authority seeing a dismantling note it did not strictly need is harmless. An authority denied data during an inspection is not.

Withholding has to be visible

This is the part almost everyone gets wrong, and it is the difference between a passport that reads as well built and one that reads as sloppy.

When a consumer scans a battery and three fields are restricted, there are two ways to render that. One is to omit them silently, so the page shows what it can. The other is to show what it can and say, plainly, that three further fields are restricted to repairers, remanufacturers and recyclers.

Silent omission fails twice. It looks like an incomplete passport, so a diligent consumer or a journalist concludes you did not fill it in, and the natural next step is a complaint to a market surveillance authority about a passport that is missing data. And it hides the regulation working correctly. Differentiated access is a designed feature. A viewer being told "these fields exist and are available to recyclers" is the system doing exactly what Article 10 asked for.

So a redacted passport should report how many points were withheld and under which tier they sit. The absence is explained rather than merely present.

The half redacted field trap

One more mistake, and it is a subtle one that produces the worst possible outcome.

A single conceptual field often occupies more than one column in a real system. State of health is a good example: it is a health reading, a charge level, and the date the reading was taken. Three stored values, one restricted data point.

If your redaction logic knows only about the health reading, it strips that and serves the charge level and the timestamp to an anonymous scan. You have now half redacted a restricted field, which is worse than either publishing it or withholding it. A field that is fully withheld reads as a rule being applied. A field where two of three parts are visible reads as a deliberate disclosure, and anyone assembling data from your passports gets most of what the restriction was meant to protect.

Every column a data point can write has to be listed as belonging to that point. This is a boring piece of bookkeeping and it is the one that decides whether your access model works on the fields that actually matter.

And the reverse mistake

There is a symmetrical failure worth naming, because it is invisible until it does damage.

If a field is stored but never mapped to the data point it belongs to, two things break at once. It scores nothing, so your coverage report understates what you hold. And redaction does not know it exists, so it is served to whoever asks. A column added without its mapping is both invisible to you and visible to everyone else, which is the worst combination available.

The practical rule that falls out of this: decide a field's tier before you wire up its storage, not after. The tier is the more consequential half of the decision and it is the one that is hard to reverse.

What to do with this

If you are scoping passport work now, the access model deserves a decision earlier than it usually gets one. Concretely:

1. Sort your fields into the three tiers before you build anything. The sorting is a business decision about disclosure, not a technical one, and it should be made by people who understand what publishing a supplier facility means commercially.
2. Default to restricted when the text does not settle it. You can loosen later. You cannot tighten later.
3. Make sure nothing in your stack can be talked into a tier. No query parameter, no header a client can set, no "internal" flag that a crawler eventually finds.
4. Render the withholding. Count it, name the tier, show it to the viewer.
5. Check that every part of a multi part field is covered by the same rule. The timestamp and the units are part of the field.

Our own Digital Product Passport tooling implements exactly this model: three tiers, an access decision that comes from a grant rather than from anything in the request, restricted points stripped before the page is built, and a viewer who is told how many fields were withheld and under which tier. Every field carries the regulation and the article that places it where it is, so you can check the reading rather than trust a number.

For the wider picture, the plain explainer on what a Digital Product Passport is covers the legal position and the datasets, and the piece on the QR code covers how a scanner reaches the passport in the first place.

One closing note we repeat everywhere, because it matters most on this subject. What tooling can report is data coverage against a named, cited dataset. It is not a conformity assessment, it does not replace the procedures a regulation requires, and it is not legal advice. We cite the instrument and the article so your own counsel can check the reading against the text.