All Eight DPP Standards Are Published. Only Six Are Cited.

In May 2026, CEN/CENELEC JTC 24 published six of the eight harmonised standards for Digital Product Passports. We wrote about them at the time, and noted that two were still missing.

They are not missing any more. EN 18239 and EN 18246 were approved by CEN on 17 August 2026 and adopted as SS-EN on 16 September. The set is complete.

That is the part everyone will report. The part that matters more is that the set being complete has not made all eight equal, and the difference is not a technicality.

Six are cited, two are not

Commission Implementing Decision (EU) 2026/1736 cites six standards in the Official Journal:

EN 18239 (access rights management, information system security and business confidentiality) and EN 18246 (data authenticity, reliability and integrity) are not in that list.

Citation in the Official Journal is what turns a European standard into a harmonised standard. A harmonised standard carries presumption of conformity: follow it, and you are presumed to meet the corresponding legal requirement unless somebody proves otherwise. An uncited standard carries no such presumption, however recently it was published and however good it is.

So the two newest standards occupy a peculiar position. They are real, they are buyable, they represent the considered view of the committee that wrote the other six — and following them is a choice rather than a defence. You cannot point at EN 18246 and say you are presumed compliant. Neither can anyone else, which is worth knowing when a competitor claims harmonised conformity across "all eight".

Both will most likely be cited in a later amendment to the Implementing Decision. Until they are, the honest formulation is "we follow it", not "we conform to it".

While we are correcting things: there is no EN 18217

The series is written as EN 18216–18223 almost everywhere, including by people who should know better. It is not a contiguous range.

There is no EN 18217 and no EN 18218. The eight are 18216, 18219, 18220, 18221, 18222, 18223, 18239 and 18246. Writing the range as 18216–18223 both invents two standards that do not exist and omits the two that were published most recently.

If you are citing these in a specification, a tender response or a supplier questionnaire, cite them by number and clause. A range is wrong in both directions.

What can actually be checked from outside

Our validator follows the published set. It runs ten checks across seven of the eight standards, against any passport URL, with no cooperation from the publisher and no account.

Seven, not eight. EN 18239 is about access control, security and confidentiality, and almost nothing in it can be answered by a stranger making one request. We implement it — row-level access per tenant, short-lived tokens rather than shared keys, resolver rate limiting written against §5.2 item 11 — but implementing a standard and testing it from outside are different things, and a check that cannot fail is not a check.

The same restraint applies inside EN 18246. Its heaviest requirements are about proving a passport and its carrier are genuine, which needs cryptographic signing. Nothing signs anything yet — not ours, not anyone's — and a check that no passport on Earth can pass teaches the reader nothing. Three of its clauses can be answered from outside. Those three are the ones we run.

The check most passports will fail

Of those three, one is going to surprise people.

EN 18246 §5.1.2 forbids gathering personal information from natural persons who read public passport data. §5.1.5 requires profiling to be prevented. Read together, they describe exactly what an analytics tag does: set an identifier on a reader, follow them across pages, send it to a third party.

A Digital Product Passport that loads Google Analytics, Meta Pixel, Hotjar, Clarity or Segment is gathering personal information from someone whose only act was scanning a QR code on a jumper. The validator looks for the tracker's host in the page a consumer actually receives, not for a script filename, because each of these ships under half a dozen names.

This one is uncomfortable to ship, so it is worth being plain about our own position: our resolver injects a GA4 tag when a tenant sets a measurement ID. The feature exists, and any tenant who sets one will fail this check in our own validator, on our own pages. That is the only kind of check worth writing. One that exempts the author is marketing.

If you run analytics on your passport pages, the question to take to your legal team is not whether the tracking is consented — it is whether §5.1.2 permits it at all on the public half of a passport.

The constraint inside EN 18239 that makes it hard

EN 18239 §5.2 item 11 requires that access to DPP services "shall be limited in such a way as to prevent attacks or unauthorized mass data scraping".

The obvious implementations are all closed off by other clauses in the same pair of standards:

• An API key or login? EN 18246 §4.3 says public data shall be served without authentication. EN 18239 §5.2(2) says the same and names avoiding discrimination by geographical location as the reason.
• Block by country? EN 18239 §5.2(3) says access shall not be refused based solely on the actor's location or jurisdiction.
• A CAPTCHA wall? Same problem, and it fails §5.4.2 on readability with any consumer device.
• Log IP addresses to spot abusers? An IP address is personal data, and §5.1.2 forbids collecting personal information from readers of public data.
• Block bots? EN 18246 §5.1.8 says robust anti-scraping mechanisms should be implemented, and in the same breath that the system may allow beneficial search engines to index DPP data. A limiter that blocks Googlebot is not safer, it is wrong.

What is left is narrow: throttle by a salted hash of the address, held in memory for the length of one window, never written anywhere. What survives the minute is a count, and a count is not about a person.

That is a real engineering constraint, and it is the sort of thing that only becomes visible once the standards are read together rather than one at a time.

What to do with this

1. Stop writing the range. EN 18216–18223 invents two standards and omits two. Cite by number and clause.
2. Separate "published" from "cited" in your own claims. Six carry presumption of conformity. Two do not, yet. Anyone claiming harmonised conformity across all eight is claiming something that does not currently exist.
3. Look at what your passport pages load. If there is an analytics tag on the public half, EN 18246 §5.1.2 is a conversation you need to have before somebody else starts it.
4. Buy the standards. They are available from SIS and en-standard.eu. Six of them decide whether your implementation is presumed compliant, and none of the summaries in circulation — this one included — is a substitute for the text.

You can run the checks above against any passport URL at dppagent.com/validate, including passports that are not ours. It reports per standard and per clause, and says which findings are partial and why.

---

Sources

Primary sources used in this article:

• Commission Implementing Decision (EU) 2026/1736 — citation of harmonised standards for Digital Product Passports in the Official Journal
• EN 18216 (data exchange protocols), EN 18219 (unique identifiers), EN 18220 (data carriers), EN 18221 (data storage, archiving and data persistence), EN 18222 (APIs for passport lifecycle management and searchability), EN 18223 (system interoperability) — CEN/CENELEC JTC 24, published May 2026
• EN 18239 (access rights management, information system security and business confidentiality) and EN 18246 (data authenticity, reliability and integrity) — approved by CEN 17 August 2026, adopted as SS-EN 16 September 2026
• Regulation (EU) 2024/1781 (ESPR), Articles 4, 9 and 10 — EUR-Lex

Clause references in this article are to the licensed SS-EN 2026 editions. Standards are copyright documents and cannot be reproduced here; the clause numbers are given so the text can be checked against the originals.