How DPP will change your supplier contracts

Hello Sustainability Managers!

Last call for the “AI for Sustainability” Masterclass (Early birds), sign up HERE

Now, I want to start with something that happened on 15 July and got almost no coverage outside a handful of standards bodies, because I think it matters more than the headline dates everyone quotes. The European Commission cited six new European standards in the Official Journal, under Implementing Decision (EU) 2026/1736. These are the CEN and CENELEC standards that define, in technical detail, how a Digital Product Passport is actually built, not what data your product needs to disclose, that part still comes from your sector’s delegated act, but the basis underneath it: how a product gets an identifier, how that identifier is carried on the product itself, how the data behind it gets stored, exchanged and kept alive over time.

I have bought the standards and read through what’s on these six documents this week and one of them in particular changes how I’d advise anyone writing a supplier contract right now. So today I want to do two things: walk through what actually shifted with the registry and this OJEU citation, and then get into the one standard that I think has real, immediate implications for procurement, not just for your engineering team.

What’s actually new since the registry went live

Quick recap for anyone catching up. The Commission switched on the EU Central DPP Registry the following day, 20 July, with a live environment and a separate test environment for economic operators to try workflows without touching real data. That part I covered before. What’s new is the standards layer sitting underneath it.

CEN and CENELEC’s Joint Technical Committee 24, working under the Commission’s standardisation request M/604, was tasked with turning the ESPR’s legal language into something an engineering team could actually build against. They produced eight standards in the EN 18200 series. Six of them, EN 18216, EN 18219, EN 18220, EN 18221, EN 18222 and EN 18223, were published in May 2026 and then formally cited as harmonised standards in the Official Journal on 15 July. The other two, covering access rights and data authentication, were still going through formal vote as of mid-July and aren’t cited yet.

That citation matters more than it sounds. Under EU Regulation 1025/2012, once a harmonised standard is cited in the Official Journal, following it correctly gives you what’s called a presumption of conformity. You don’t have to independently prove to a regulator that your system meets the legal requirement, building to the cited standard does that for you. So as of 15 July, there is now a concrete, checkable technical target for six of the eight pieces of DPP infrastructure, rather than a legal principle you’re left to interpret on your own.

The one that actually rewrites your contracts: EN 18219

Of the six, EN 18219, Digital Product Passport, Unique Identifiers, is the one I’d put in front of your legal team this week rather than filing under “engineering will handle it.” It’s a 43 to 64 page document depending on which national mirror you’re reading, and it defines the rules for assigning identifiers to products, to the economic operators handling them, and to the facilities they pass through.

The standard requires identifiers to satisfy six properties: global uniqueness, persistence, syntax, granularity, interoperability and openness. Most of those are self-explanatory, but two of them are where the contractual problem actually lives. Granularity means you have to decide, per product line, whether your identifier operates at the model level, the batch level or the individual item level and that decision changes what data has to be trackable back to a single unit versus a production run. Persistence means the identifier has to remain valid and resolvable for as long as the product exists, which for furniture or industrial equipment could mean decades, well past the length of most supplier contracts you currently have on file.

The standard also allows two different ways to generate that identifier: agency-based issuance, where you use an existing scheme like a GS1 identifier or self-issuing systems, where you or your supplier generate and manage the identifier yourselves under the standard’s rules. Here’s where it stops being an IT decision.

If a component supplier is the one assigning the identifier for a part that ends up in your product and that supplier’s contract with you ends in three years, who is responsible for that identifier still resolving correctly in year eight, when a recycler scans it at end of life? Right now, for most companies, the honest answer is nobody, because nobody wrote that obligation down anywhere.

Where the formalities actually bite

This is the part I wanted to spend this whole newsletter on it rather than folding it into a broader roundup. Under Article 13 of the ESPR, the manufacturer registers the passport or the importer does it for goods made outside the EU. That’s one name, one legal entity, holding responsibility for a record built from data that mostly lives with other companies. Everything downstream of that fact needs to show up in your paperwork, and right now it mostly doesn’t.

A supplier agreement written for DPP compliance needs to answer a handful of questions that a standard “comply with applicable law” clause never touches. Who is actually generating the unique identifier for this component, you or the supplier and under which of the two schemes EN 18219 allows?

What happens to that identifier’s resolvability if this contract ends, does it transfer to you, does the supplier remain obligated to keep hosting it, or does someone need to migrate the record before the relationship ends?

Who warrants the accuracy of the material composition and sourcing data the supplier hands over, and what happens if that data turns out to be wrong after a market surveillance authority has already inspected your product?

Does your supplier’s own contract with their sub-suppliers require the same data, in the same format, or does your obligation quietly stop being enforceable two tiers down?

It’s the kind of clause structure procurement teams already use for IP ownership or data protection, just pointed at a new kind of data. The reason it hasn’t happened yet is mostly that DPP has been treated as a design and materials topic, something for the sustainability function to manage inside product development, when the actual mechanics of who owns, generates and maintains the record sit squarely inside contract law and procurement, not product design.

If you’re renegotiating any supplier agreement this year for other reasons, this is the moment to add an identifier governance clause and a data continuity clause alongside whatever else is already on the table. Waiting until your category’s delegated act forces the conversation means doing it under deadline pressure, with suppliers who may have already signed different terms with someone else who asked first.

That’s what I wanted to get into this time. I’ll come back to the two standards still in vote, access rights and data authentication, once they’re actually cited, since I’d rather explain what’s confirmed than speculate on drafts. If your legal or procurement team has already started drafting identifier clauses, I’d genuinely like to see how you’ve framed it, feel free to reply.

Talk soon,

Gianluca