The DPP standards suite, in plain terms

The Digital Product Passport is not defined by a single technical standard. It is defined by a suite of them, developed by CEN/CENELEC's joint technical committee and each covering a different part of how a passport is exchanged, found, stored, and trusted. Understanding which standard does what — and, just as important, which are actually in force — is the difference between building to the real requirements and building to a marketing summary of them.

The standards and what each one governs

Four standards form the interoperability core:

Data exchange protocols (EN 18216) fix the transport layer. Every passport has to move — from a manufacturer's system to a service provider, to a recycler, to a regulator — and this standard specifies how: RESTful APIs over HTTPS with TLS, structured message formats, and exchange that is authenticated, confidential, and tamper-resistant. It is the lowest common denominator that lets two systems that have never met talk to each other.

Lifecycle APIs (EN 18222) specify exactly which API calls a conformant system must offer — create, read, update, and search a passport, including element-level operations, batch retrieval, versioning queries, and registry submission. Where the exchange-protocol standard says "use REST," this one says precisely which methods, so a refurbisher can read a passport, append a record, and write it back without a bespoke integration for every partner.

System interoperability (EN 18223) addresses the semantics — shared meaning and technical formats so that a recycler or a marketplace can understand your data without custom mapping, across sectors.

Storage, archiving, and persistence (EN 18221) sets requirements for keeping passport data available and trustworthy over long product lifecycles, including backups and migration. For a product that may be in service for a decade or more, the persistence requirements are not an afterthought.

Further standards in the suite address access-rights management, information-system security, and data authentication and integrity — the parts that govern who may see which fields and how a reader can trust that data has not been altered.

The honest status

This is where precision matters. EN 18222:2026 and EN 18223:2026 have been published, having been formally requested by the European Commission under standardisation request M/604. But publication is not the same as legal effect. Until these standards are cited in the Official Journal of the European Union, they do not yet confer presumption of conformity with ESPR — and that citation has not taken place. Additional standards in the suite, covering access rights and security, were still under approval as of mid-2026.

So the accurate position is: the technical baseline exists and is stable enough to build against, but its formal legal status is still maturing. Anyone telling you the standards are "done and binding" is overstating it; anyone telling you to ignore them until they are OJ-cited is asking you to build on shifting ground in the meantime.

What it means in practice

The practical reading for anyone building or selecting a passport system: build to these standards now — REST-over-TLS exchange, the specified lifecycle API methods, versioned records, persistent storage with an audit trail — while keeping the implementation flexible enough to align with the final cited versions when the Official Journal catches up. Conformant in substance today, ready to claim presumption of conformity the day the citation lands. A system that ignores the suite because it is not yet OJ-cited is building on ground that will shift; one that treats the published text as binding is overcommitting to a status it does not yet have.