The EU's Digital Product Passport standards finally landed this summer. Most companies are now shopping for the wrong thing.
For two years, the Digital Product Passport existed as an obligation without a shape. The Ecodesign for Sustainable Products Regulation said a passport must exist. It did not say what one should look like on the wire, which meant every conversation about DPP readiness ended in a shrug.
That gap has now closed. In mid-2026, CEN/CENELEC's technical committee JTC 24 published the first six harmonised European standards for the Digital Product Passport, developed under Commission mandate M/604. They are deliberately product-agnostic, and they define how a passport is identified, accessed, exchanged, stored and interpreted. Shortly afterwards, on 20 July 2026, the Commission launched the DPP Registry alongside a separate testing environment, reachable through a secure interface or an API.
The predictable thing happened. Procurement teams across Europe started evaluating passport platforms, comparing QR code generators, and asking vendors whether they are "EN compliant."
These are reasonable questions. They are also, mostly, the wrong ones.
The envelope is the easy part
Read the standards and a pattern emerges quickly. EN 18219 covers unique identifiers. EN 18220 covers data carriers. EN 18216 covers how a passport is fetched over HTTPS. EN 18222 covers the API for finding passports and querying their lifecycle. EN 18223 covers semantic interoperability through linked data.
Every one of these is a solved engineering problem. Generating a GS1 Digital Link URI is straightforward. Rendering a QR code is straightforward. Serving JSON-LD with content negotiation is an afternoon of work for a competent backend team. None of it is trivial to do well, at scale, with versioning and access control, but none of it is where your programme will fail.
Your programme will fail on the part nobody is selling you: the data that goes inside.
What the passport actually asks for
A passport is not a marketing page with a recycling symbol on it. It carries a product's origin, materials, sustainability performance, and compliance data, and it has to travel with that product across its entire lifecycle. Downstream, it will be read by recyclers deciding how to process a component, by customs officers checking a declaration, and by market surveillance authorities checking whether your claims hold.
That means the numbers inside have to be defensible. Not directionally reasonable. Defensible, with a traceable methodology and a source for every material input.
Now consider where those numbers come from. Your own operations account for a slice. The rest sits with your suppliers, and their suppliers. If your recycled content figure is an industry average, your material origin is a category placeholder, and your substance declarations are three-year-old PDFs in a shared drive, no passport platform on earth will save you. It will render your weak data beautifully, in fully conformant JSON-LD, at scale, for every SKU you own.
The bottleneck has a name
Primary supplier data is the hardest problem in product-level sustainability, and it has been for a decade. It is hard for unglamorous reasons: your suppliers are not incentivised to respond, they do not want to learn your software, they have limited technical capacity, and many of them are being asked for slightly different things by every one of their customers.
Any approach that requires a supplier to create an account, complete onboarding, and learn a new interface will achieve a response rate that makes the resulting dataset useless. Any approach that accepts whatever arrives in a spreadsheet will produce data you cannot stand behind when an authority asks how you calculated it.
The organisations that will handle DPP well are the ones that solved supplier data collection before the passport was on the agenda, because they wanted better footprints. For them, the passport is a new output format. For everyone else, it is an eighteen-month data programme wearing a compliance deadline as a disguise.
The half nobody is discussing: passports as an input
Almost all of the DPP conversation treats the passport as something you produce. That framing misses where most of the value will land.
Once your suppliers publish conformant passports, those passports become a structured, machine-readable feed of exactly the data you have spent years chasing by email: composition, weight, material origin, substances, upstream footprints. A passport you receive is primary data you no longer have to request.
This matters more than it first appears, because it inverts the economics. Today, every company in a value chain independently collects overlapping data from the same suppliers, and every supplier answers the same question in a slightly different format for each customer. Passports, if they are genuinely interoperable, collapse that duplication. The work of populating your own passport progressively becomes the work of reading the ones beneath you.
So when evaluating any system, ask not only whether it can issue a passport, but whether it can consume one and turn it into a calculation input. A platform that only writes passports has automated the easy half.
What to actually do this quarter
If you are in a priority sector, the clock is real. Industrial batteries above 2 kWh, EV batteries and LMT batteries require a battery passport from 18 February 2027. Textiles, electronics and construction follow as their delegated acts arrive.
Three things are worth doing now, in order.
Audit your data lineage, not your software. For a single representative product, trace every material and impact figure back to its source. Mark each one as primary, verified, or estimated. The ratio you find is the honest state of your DPP readiness, and it is more informative than any vendor demo.
Fix collection before you fix presentation. Whatever mechanism you use to get data from suppliers is the foundation. If it works, passports are a downstream concern. If it does not, everything above it is decoration.
Build to open standards, not to a vendor. The EN series is itself built on open foundations: GS1 Digital Link for identity, JSON-LD for semantics, W3C Verifiable Credentials for integrity. Anything you commit to should speak those natively, so your data stays portable as the framework continues to move.
A note on what nobody can claim yet
The standards are new, and parts of the framework are still settling. The authentication and integrity standard remains in draft, and elements of the Registry API are still being finalised. This matters when you are reading vendor material, because no organisation currently holds a conformance certificate for the EN series. None exists to hold.
Be sceptical of anyone who implies otherwise. The defensible claim, today, is that a platform is built on the same open standards the EN series is converging on. That is a meaningful statement. "Certified" is not.
Where we sit
Pilario was built around lifecycle assessment and the supplier data that feeds it. Origin exists because we concluded early that primary data collection was the constraint on everything else, and that it had to work for suppliers who would never log into our platform. Lens and RangeLCA exist to turn that data into results that hold up under ISO 14040/44, ISO 14067, PEF and GHG Protocol scrutiny.
We did not build any of it for the Digital Product Passport. We are paying close attention to the EN series now because the passport is, structurally, a publication format for exactly the data our customers already generate and can already defend — and because the reading side of it points directly at the problem we started with.
If you are assessing your own position, we would suggest starting with the data lineage audit above. You can run it without buying anything, and it will tell you more than a procurement process will.