ESPR Is In Force. It Does Not Tell You What To Put In A Passport.

Two statements about the Ecodesign for Sustainable Products Regulation are both true, and holding them at the same time is the whole skill.

The first: ESPR, Regulation (EU) 2024/1781, entered into force on 18 July 2024. It is law. It is not a proposal, not a draft, not a direction of travel.

The second: for almost every product group, it currently tells you nothing about what data your passport must contain, how granular it must be, who is allowed to read which parts of it, or by when.

Both of those follow from the same fact. ESPR is a framework.

What a framework regulation actually does

A framework builds machinery and then delegates the filling of it. Chapter III of ESPR is the passport machinery, and its article spine is worth memorising, because commentary on this regulation routinely misnumbers it and a wrong article number is how a confident claim survives a first check. Read from the consolidated text (CELEX 02024R1781-20240628):

• Article 9. Digital product passport.
• Article 10. Requirements for the digital product passport.
• Article 11. Technical design and operation of the digital product passport.
• Article 12. Unique identifiers.
• Article 13. Digital product passport registry. It says: by 19 July 2026, the Commission shall set up a digital registry.
• Article 14. Web portal for data in the digital product passport.
• Article 15. Customs controls relating to the digital product passport.

Read that list and notice what is not in it. There is no article that says which fields a jacket, a fridge or a chair must carry. There is no annex listing them. The framework describes a passport that is reached through a data carrier bound to a persistent unique identifier, that identifies the responsible economic operator, and that differentiates access between audiences. It does not describe a dataset, because datasets arrive product group by product group, in delegated acts.

What is legally undetermined until a delegated act lands

For a product group with no adopted delegated act, four things are open, and each one is expensive to guess wrong:

The mandatory field list. Nobody can hand you the required fields for a group whose act does not exist. A field list presented for such a group is somebody's reading of preparatory work. That can be a genuinely useful reading. It is not a requirement, and the difference should be visible on the screen rather than buried in terms of service.

The granularity. Model, batch or item. This is not a detail, it is the entire shape of your data programme. A per item passport for a high volume product line is a different system from a per model one, with different serialisation, different carrier printing and a different cost per unit. Committing to the wrong one early is the most expensive mistake available in this field.

The access rights split. ESPR Article 10 requires the passport to differentiate who sees what. Which side of that line a given field falls on is decided by the delegated act. Publishing supplier facility identifiers before the act says to is not a reversible mistake, because you cannot unpublish a supply chain.

The transition period. Delegated acts carry their own lead time between adoption and application. So even after an act is adopted, the date you plan against is the date in that act, not the date of adoption and not the date a newsletter announced it.

The registry exists as an instrument, and it is a directory

Article 13 obliges the Commission to set up a registry, and Commission Implementing Regulation (EU) 2026/1778 lays down how it operates. Two properties of it are widely misdescribed.

It is a directory, not a data store. Article 8(9) has the Commission hold identifiers, a commodity code and a reference to the passport service provider. The passport content itself stays with the economic operator or its service provider. So no registry submission relieves you of hosting and keeping accurate the actual data.

And the registration identifier is minted by the Commission, at Article 8(8). It is unique and persistent and it comes back from the registry. Any tool that shows you a registration identifier it generated itself is showing you a forged regulatory reference. Ours stays empty until a registry returns one, and our registry module prepares a record and validates it without submitting anything at all, because we hold no credentials for the interface at Article 3(b) and have not read its request schema. Preparing is what we do, so preparing is what we say.

Three questions that separate a real obligation from a pitch

You do not need to be a lawyer to audit a DPP claim. You need three questions, asked in order, and a willingness to sit through the silence.

1. Which instrument? Not "the EU DPP regulation". The name and number: Regulation (EU) 2024/1781, or Regulation (EU) 2023/1542, or a delegated act with its own number. If the answer is a category of law rather than an instrument, there is nothing to check.

2. Which article? A named article, and a claim that matches what the article says. This is where most pitches end, because the article either exists and says something narrower than the claim, or does not exist.

3. What date did it enter into force, and what date does it apply from? Those are two different dates. ESPR entered into force on 18 July 2024, and for most product groups nothing applies to you as a consequence yet, because the delegated act that would apply has not been adopted.

Run those questions across the claims you have been sent this quarter. Some examples of what fails.

"The EU DPP becomes mandatory in 2027." Mandatory for whom? The one product group with a passport obligation on a 2027 date is batteries, under Regulation (EU) 2023/1542 Article 77, and even there the scope is specific: LMT batteries, electric vehicle batteries, and rechargeable industrial batteries above 2 kWh. A blanket 2027 is a battery deadline wearing everyone else's clothes.

"Here are the 40 required DPP fields." For which product group, under which act? If the act is unadopted, these are candidate fields. Collecting them may still be smart. Being scored against them as if they were law is not.

"We make you DPP compliant." Compliance with which instrument, assessed by whom? Software can hold data and evidence its provenance. It cannot perform a conformity assessment, and a claim to compliance from a data tool is a claim it has no mechanism to keep.

What we do instead

Our position is deliberately narrower than the market's, and we would rather lose a deal on it than win one that unwinds.

Every data point we score carries three things. A legal status: specified, meaning an instrument in force names it, or candidate, meaning it is expected and is not law today. The two never blend into one flattering percentage. An access tier, because a point with no tier eventually defaults to public somewhere downstream. And a basis, a verbatim justification citing the instrument and article, which is never empty and never decorative.

There is a rule enforced in our code, not just in our copy: a profile whose dataset is not adopted may not carry an obligation date. There is no branch anywhere in the product that writes a deadline for such a group, and a test asserts none appears. Inventing a deadline to manufacture urgency is the exact failure this design exists to prevent, so it is designed out rather than reviewed for.

That means our answer for most product groups today is short and slightly disappointing: here is the framework level, here is what every candidate dataset so far agrees on, collecting it early carries no regret, and not holding it today breaks no rule. It is less exciting than a countdown clock. It has the advantage of being true when the delegated act finally lands.

You can see the field level version of that, with the citation behind each point, on our Digital Product Passport page.