Digital Product Passport Standards
Since 15 July 2026, a Digital Product Passport built to the six cited standards (EN 18216 and EN 18219 to 18223:2026) is presumed to conform with ESPR Articles 10 and 11. The presumption matters to manufacturers, brands, importers, and the platforms that build passports for them.
Make EN 18216 and EN 18219 to 18223:2026 your passport build specification.
Who it covers
Anyone building or buying a Digital Product Passport: manufacturers and own-label brands that carry the passport obligation, importers who must make sure it exists for goods made outside the EU, and the platforms and service providers they rely on. Nothing here moves a deadline; it changes how confidently you can build ahead of one.
In detail
ESPR Article 41 is the mechanism behind the Digital Product Passport standards. It says that if you build your passport to a harmonized standard whose reference has been published in the Official Journal, you are presumed to meet the matching ESPR requirements, and authorities must accept that without you proving it another way. On 15 July 2026, Commission Implementing Decision (EU) 2026/1736 cited the first six DPP standards (EN 18216 and EN 18219 to 18223:2026) in the Official Journal, so that presumption is now live for the parts of the passport those standards cover: data exchange, unique identifiers, data carriers, storage and persistence, lifecycle APIs, and system interoperability. It is a safe harbor, not the only route: you may comply another way, but then you carry the burden of showing it.
The six cited standards
- EN 18216, Data exchange protocols: how passport data moves between systems so a passport can be read and updated across the value chain
- EN 18219, Unique identifiers: how the identifiers for the product model, batch, and item are structured
- EN 18220, Data carriers: the carrier that links the physical product to its passport, such as a QR code or DataMatrix, and how it is applied
- EN 18221, Data storage, archiving, and persistence: how passport data is stored and kept available over time, including after the product or operator is gone
- EN 18222, Lifecycle APIs and searchability: the interfaces for creating, updating, and searching passports across their lifecycle
- EN 18223, System interoperability: how different passport systems and the registry work together so passports function across platforms
What to do
- Make EN 18216 and EN 18219 to 18223:2026 your passport build specification, so conformity carries the Article 41 presumption of conformity with ESPR Articles 10 and 11
- Require your DPP platform or service provider to conform to the six cited standards in contracts and RFPs, not as a preference
- Treat the two not-yet-cited standards, EN 18239 (access rights and security) and EN 18246 (data authentication and integrity), as a watch item until they are cited; CEN published both on 15 September 2026
- Budget for standards access: the EN texts sit behind the CEN and CENELEC paywall even though the citation itself is public
Key dates
Locked
Locked
Locked
Signaled
How it connects
- Backs ESPR Articles 10 and 11: the six standards cover the DPP requirements those articles set
- Works with the DPP Registry (Art. 13): the registry indexes passports, the standards define how the passport data itself behaves
- Batteries reuse the same DPP infrastructure; the battery passport on 18 February 2027 is the first category where a compliant passport actually binds
- Not the Authorized Representative provision: that is ESPR Article 28, a common point of confusion with Article 41