.jpeg)
%201.png){kind=logo}
Create your digital product passports in no time and with minimal effort.
On 14 July 2026 the European Commission adopted Implementing Decision (EU) 2026/1736, publishing the first six harmonised standards for the Digital Product Passport. The decision entered into force the next day, when it appeared in the Official Journal. This is the technical backbone the ESPR (Regulation (EU) 2024/1781) needed before any passport could be built with confidence that it would actually be recognised as compliant. Here is what the six standards cover, and why builders and buyers of DPP tooling should care.
What an Implementing Decision on harmonised standards actually does
Under Regulation (EU) 1025/2012 on European standardisation, once the Commission publishes a reference to a harmonised standard, a product that conforms to that standard is presumed to comply with the corresponding legal requirement. That presumption of conformity is the entire point of Implementing Decision 2026/1736: instead of every manufacturer or platform arguing case by case that their passport meets Articles 10 and 11 of the ESPR, they can point to conformity with the published standard and the compliance question is settled.
The six standards were drafted by CEN and CENELEC's joint technical committee JTC 24, working under a standardisation mandate from the Commission.
The six standards, in plain terms
| Standard | Covers | Why it matters in practice |
|---|---|---|
| EN 18216:2026 | Data exchange protocols | How a passport's data moves between systems, including the Registry |
| EN 18219:2026 | Unique identifiers | How a product gets an identifier the Registry and every downstream system can resolve |
| EN 18220:2026 | Data carriers | Requirements for the QR code or other carrier printed on the product |
| EN 18221:2026 | Data storage, archiving, and persistence | How long passport data must remain available and how it is archived after a product's end of life |
| EN 18222:2026 | APIs for lifecycle management and searchability | The technical interface a passport platform uses to update, register, and expose passport data, including to the Registry |
| EN 18223:2026 | System interoperability | How passports issued by different vendors and platforms stay readable and comparable across the market |
Read together, the six standards answer one practical question: can a passport built on Platform A be read, verified, and registered by a system that has never heard of Platform A? Before this decision, the honest answer was "probably, but nobody could prove it." After it, conformity is a checklist.
What changes for companies building their own DPP
Until 15 July 2026, anyone building a passport in house was building against draft standards, with a known retrofit ahead once the final versions landed. We flagged that risk directly in our build vs buy comparison. That specific risk is now resolved, the target no longer moves, but it also raises the bar: an in house build now needs demonstrable conformity with six named standards, not a good faith interpretation of a regulation. For a small internal team, that is a meaningfully bigger scope than building a passport page and a QR code.
What changes for companies buying a platform
Ask directly: is the platform's passport format built to EN 18216 through EN 18223, and can the vendor point to where each standard is implemented? A vendor who cannot answer specifically is asking you to take conformity on faith, right at the moment the Commission removed the need to. This is also the point where the API standard, EN 18222, matters most: it is what the EU Central DPP Registry expects a passport platform to speak when registering a product, and a platform not built to it will need custom integration work that a conformant one skips.
How this connects to the identifier standard and GS1
EN 18219 governs unique identifiers, and GS1 Digital Link is on track to be the practical carrier for that identifier in most sectors, the same link between a QR code and a resolvable product record that underlies GS1's existing standards work. Platforms already built on GS1 Digital Link have a shorter path to conformity with both EN 18219 and EN 18220. We cover which platforms support it today in our GS1 Digital Link comparison.
What to do now
- If you are building in house: get the six standards in front of your engineering team this quarter, before more architecture decisions get made against the old draft assumptions.
- If you are evaluating vendors: add "conformity with EN 18216 to 18223" as a standing question in every vendor call, not an afterthought.
- If you already have a platform in place: ask your vendor for a written statement of conformity. It costs them nothing to provide and it is the paperwork you will want the day an auditor asks.
dpp.cloud's passports are built to all six standards, including the EN 18222 API the Registry expects, so registration and interoperability are not a separate project on top of your DPP implementation. Implementation with an existing PIM typically runs two to three weeks, described in creating a DPP from PIM data.
Next step
If you want a conformity check against the six standards for your current setup, or a vendor built to them from day one, book a 30-minute strategy session.
