EN 18216: data exchange protocols and formats for digital product passports

EN 18216 is the European standard for how the data in a digital product passport travels between systems: which protocols are used, which data formats must be supported, and how the same passport can be read by a person and by a program. It concerns anyone who builds or runs a passport system, meaning manufacturers, brands and their passport service providers, and anyone who wants to read passports automatically, such as recyclers, marketplaces and authorities.

It is one of six harmonised standards for product passports that CEN approved on 3 May 2026; SIS adopted the Swedish edition on 27 May 2026. The Commission published their references in the Official Journal of the European Union on 15 July 2026, so following the standard now gives a presumption of conformity with the corresponding requirements of the Ecodesign for Sustainable Products Regulation (ESPR). This article explains what the standard covers, what it means in practice and how it fits with the rest of the series. For the whole picture, see the overview of the DPP standards.

What the standard covers

The full reference is EN 18216:2026 Digital product passport – Data exchange protocols. It was drafted by the joint technical committee CEN-CLC/JTC 24 in response to the Commission's standardisation request M/604 (Implementing Decision C(2024) 5423 of 31 July 2024, as amended by M/604 Amd 1). The Swedish edition, SS-EN 18216:2026, runs to 19 pages.

According to the scope statement that SIS publishes, the standard defines protocols and data formats for secure and efficient data exchange. Protocols are the rules and procedures systems follow when they communicate. Data formats define how the information is structured so that the receiving system can understand and process it. Together they are meant to make data human- and machine-readable, structured, searchable and transferable through an open, interoperable network without vendor lock-in. That is close to word for word what ESPR requires in Article 10(1)(d).

The scope lists five areas:

• Secure communication: protocols that protect data against unauthorised access, so that only authorised parties reach protected information.
• Interoperability: protocols and formats that integrate with existing systems and work across sectors.
• Ease of use: solutions that are easy to implement, in particular on mobile devices.
• Data integrity: information that holds up along the whole value chain, through to the product's end of life.
• Documentation and discoverability: protocols and formats that are available to people without specialist knowledge.

The standard deliberately builds on protocols and formats already used under other EU legislation, to keep costs down for businesses. At the CEN and CENELEC webinar on 25 June 2026, EN 18216 was described as widely adopted, secure protocols, endpoints and formats that allow voluntary extensions and are system-agnostic and vendor independent.

What it requires in practice

The text itself is copyright and sold through the national standards bodies. The details below come from the licensed SS-EN edition as we read it when building DPP Agent's validator. Check them against your own copy before you build to them.

Transport

Clause 4 deals with the transport layer. Passport data is exchanged over HTTPS. TLS 1.2 is the minimum and TLS 1.3 or later is strongly recommended. TLS 1.0, TLS 1.1 and all SSL versions are prohibited. At the HTTP level, HTTP/2 is the minimum, older versions shall not be used, and HTTP/3 is recommended. APIs should follow a RESTful style, which is a recommendation rather than a requirement.

For most teams this is a question of hosting rather than code. Current cloud platforms and CDNs offer TLS 1.3 and HTTP/2 by default. Anyone running their own servers needs to check the configuration and switch off old protocol versions.

Data formats

Clause 5 makes JSON, as defined in ISO/IEC 21778, the common baseline that must always be supported. XML and JSON-LD may be offered in addition, and the passport shall also be rendered as HTML. Both are selected through content negotiation. Choosing JSON as the lowest common denominator means that any program able to read JSON can read any passport, whoever published it.

Content negotiation

Which format is returned is decided by HTTP content negotiation as described in RFC 9110, that is, by the Accept header of the request. The same address can then answer in two ways. A phone scanning the QR code gets a web page. A program sending Accept: application/json to the same address gets the passport data as JSON.

A phone scans the QR code

One passport addressthe one in the QR code

Web pageHTML, accessible under EN 301 549

A program sends Accept: application/json

Passport data as JSONmust always be supported (clause 5)

This is the requirement that many early passports miss. A passport that can only be read as a web page may look complete to a consumer, but a recycler or an authority that wants to read thousands of passports automatically has nothing to work with.

Accessible HTML

When the passport is returned as HTML, the page has to follow W3C standards and the European accessibility standard EN 301 549. A passport is therefore also an accessibility question: heading structure, contrast, alternative text and language attributes all matter.

A checklist

1. Does the passport address answer over HTTPS with TLS 1.2 or later, with older versions switched off?
2. Does the server support HTTP/2?
3. Does the same address return JSON when the request sends Accept: application/json?
4. Does the response say that its content depends on Accept (the Vary: Accept header), so that caches do not mix up HTML and JSON?
5. Has the HTML version been checked against EN 301 549?

Point 4 is good HTTP practice under RFC 9110 rather than something we have read as a requirement of EN 18216, but without it a cache can hand the web page to a program that asked for JSON.

How EN 18216 relates to the other standards and the law

ESPR Article 10(1)(d) says that all data in the passport shall be based on open standards, developed with an interoperable format, and, as appropriate, be machine-readable, structured, searchable and transferable through an open interoperable data exchange network without vendor lock-in. Article 11(a) requires the passport to be fully interoperable with other product passports as regards the technical, semantic and organisational aspects of end-to-end communication and data transfer.

Implementing Decision (EU) 2026/1736 of 14 July 2026 states that the six standards satisfy the requirements of Articles 10 and 11, and it entered into force on publication on 15 July 2026. Under ESPR Article 41(2), a passport that conforms to such a standard is presumed to meet Articles 10 and 11 to the extent the standard covers them. For EN 18216, Annex ZA lists which: Article 10(1)(d), Article 11(a) (the exchange protocols and data formats only) and Article 11(h).

Within the series, EN 18216 is the layer the others stand on. CEN and CENELEC described it at the webinar as a prerequisite for data exchange and processes over the internet. The division of work looks like this:

• EN 18219 sets the identifier, the address the request goes to.
• EN 18220 sets the data carrier, such as the QR code that carries the address.
• EN 18222 sets which API calls exist. They run over the protocols EN 18216 specifies.
• EN 18223 sets what the data means: data model, semantics and serialisation.
• EN 18221 sets how the passport is stored, archived and kept alive through a back-up.

Security around the exchange has two standards of its own, EN 18239 on access rights and EN 18246 on data authentication. Both were approved by CEN on 17 August 2026 (SIS adopted them on 16 September 2026) but are not cited in the Official Journal, so they give no presumption of conformity yet.

For batteries, Regulation (EU) 2023/1542 sets similar requirements. Article 77(5) says the information in the battery passport shall be based on open standards, in an interoperable format, transferable without vendor lock-in, machine-readable, structured and searchable. Article 78(a) requires the battery passport to be fully interoperable with the product passports required under ecodesign law. The standardisation request also covered batteries, but Decision 2026/1736 publishes the references in support of ESPR, so it gives no presumption of conformity under the Batteries Regulation.

Common misunderstandings

"A good web page is enough"

No. JSON is the common baseline that must always be supported. The HTML page is required too, but it does not replace JSON.

"JSON-LD is mandatory"

Not under EN 18216 as we read it. JSON-LD is one of the formats that may be offered on top of JSON. Offering it can be sensible, because linked data makes the meaning of fields explicit, but the requirement is JSON.

"A download link to a JSON file amounts to the same thing"

The standard points to content negotiation on the request as the mechanism. A separate file at another address means a program first has to know where the file is, which is exactly the problem content negotiation solves.

"Harmonised means mandatory"

Harmonised standards are voluntary, as CEN and CENELEC also state. The benefit of following them is the presumption of conformity. Anyone choosing a different solution has to show for themselves that the ESPR requirements are met.

"EN 18216 decides what goes into the passport"

No. According to CEN and CENELEC the standards are transverse and product agnostic. What data a passport carries is set in the delegated acts for each product group, under ESPR Article 9(2)(a) and Annex III.

How this looks in practice

In DPP Agent, developed by Blippa, every passport address answers as a web page and as JSON or JSON-LD depending on the Accept header, and responses carry Vary: Accept. The address printed in the QR code is used by the consumer and by the machine alike. The validator at dppagent.com runs the same check against any passport: it asks for JSON with Accept: application/json and reports the result against EN 18216 clause 5.