EN 18246: data authentication, reliability and integrity in product passports

EN 18246 is the European standard for data authentication, reliability and integrity in digital product passports. It answers the question of how a recipient can trust that a passport comes from the right issuer and has not been changed along the way. It is written for economic operators, service providers and everyone who reads passport data by machine, such as recyclers, marketplaces and authorities.

A passport that anyone can imitate is not worth much. A fake QR code on a label can lead to a fake passport page, and data passed between systems can be altered. EN 18246 describes how this is detected and prevented, and it also sets rules for protecting the people who read the public part.

Status: approved but not cited

EN 18246 was approved by CEN on 17 August 2026 and adopted as a Swedish standard (SS-EN 18246:2026) on 16 September 2026. It is not cited in the Official Journal of the European Union. Implementing Decision (EU) 2026/1736 of 14 July 2026 lists six passport standards, and EN 18246 is not among them. CEN and CENELEC wrote on 15 July 2026 that six of the eight standards had been cited.

Under ESPR Article 41(2), only conformity with harmonised standards whose references have been published in the Official Journal gives a presumption of conformity with the requirements of Articles 10 and 11. Following EN 18246 therefore gives no such presumption yet. Anyone referring to it can say they follow it, not that they are presumed to comply with the law because of it.

What the standard covers

According to its published scope, EN 18246 defines requirements and frameworks for secure information processing and communication that protect the integrity, authenticity and reliability of passport data exchange. The aim is to reduce product fraud and counterfeiting through data verification and integrity enforcement.

At its core is a framework for trust and interoperability between multiple actors using a secure electronically signed data construct (ESDC). It is meant to work across sectors and languages, and existing systems for unique product identification are to be taken into account. The scope says the ESDC scheme is combined with existing data constructs rather than replacing them, so that current traceability and authentication systems are not disrupted. A normative Annex A sets out what an ESDC involves (issuer, subject, data and the issuer's signature), and an informative Annex B gives examples and references to implementations.

Out of scope are system architecture, use cases, secure elements in data carriers and cryptographic security features for unique product identifiers. The standard is 27 pages long.

What it requires in practice

Signed data that can be verified

The heavy part of EN 18246 is about proving that a passport and its data are genuine: that they come from the designated economic operator and have not been altered. That requires cryptographic signing tied to certificates. Under clause 4.7, every actor that provides passport data is authenticated with a digital certificate, every change, including creation and deletion, is bound to that actor so it cannot be denied, and changes are logged. The standard names digital signatures, electronic seals, electronic attestations of attributes and ESDCs as examples, and checking a passport must be free of charge for the verifier. For anyone building a passport system it means having a plan for how signatures are created, how keys and certificates are managed and how a recipient verifies them.

The issuersigns the passport data

On the waybetween systems

The recipientverifies the signature

• comes from the designated issuer
• has not been altered, even after leaving the sender
• if anything was changed on the way, the check fails

Public data without a login

The standard also has requirements that can be checked from outside. Under clause 4.3, public passport data is served without authentication. Under clause 5.4.2, it must be readable with any ordinary consumer device, without additional software. A passport that sends the reader to an app store does not meet that.

No tracking of readers

Two requirements matter most in practice for many publishers. Clause 5.1.2 forbids gathering personal information from natural persons who read public passport data, and clause 5.1.5 requires profiling to be prevented where technically feasible. Clause 5.1.3 is more direct still: the passport service shall not use external analytics tools or refer to external components in what it returns. Read together, they describe exactly what an analytics tag does when it sets an identifier on a visitor and follows them across pages. A passport that loads such tags is collecting personal data from someone whose only act was scanning a QR code on a garment.

Protection against scraping, but not against search engines

Clause 5.1.8 says robust anti-scraping mechanisms should be implemented, and in the same clause that the system may allow beneficial search engines to index passport data. A barrier that shuts out search engines is not automatically safer. The requirement connects to EN 18239, which requires protection against mass scraping but rules out logins and geo-blocking for the public part.

How it relates to the law and the other standards

ESPR

In subject matter the standard matches two points in ESPR Article 11, on the technical design and operation of passports:

• Article 11(g): data authentication, reliability and integrity shall be ensured,
• Article 11(h): the passport is designed and operated to ensure a high level of security and privacy and to avoid fraud.

The standard's own Annex ZA is narrower: it links only clause 4.2 to Article 11(a), limited to organisational interoperability, so a presumption of conformity after citation would cover only that. The Article 11(g) requirement is in the law regardless of the standard's status. The registry under ESPR Article 13 touches the same question: the Commission is to specify in the delegated acts which further data is stored in the registry, taking into account the need to allow verification of the passport's authenticity (Article 13(2)(a)).

The Batteries Regulation

The Batteries Regulation has no provision worded like ESPR Article 11(g). Article 78 requires, among other things, that the battery passport be fully interoperable with other digital product passports under ecodesign law (78(a)), and the standards were drafted under a standardisation request covering both ecodesign and batteries.

The other standards

In CEN and CENELEC's description of the workflow, EN 18246 is step 7: ensuring the integrity of passport data for a given product. It is closely tied to EN 18219 on unique identifiers and EN 18220 on data carriers, since a forged code on the product is a common start of a fraud. Secure elements in the carrier itself are, however, outside EN 18246. EN 18221 requires the history to be kept, and EN 18246 is what lets you show that it has not been changed.

Common misunderstandings

"EN 18246 is harmonised like the others"

It is not. It is approved but not cited in the Official Journal, so it gives no presumption of conformity yet.

"Integrity is just encryption"

Encryption in transit protects against interception. Integrity and authenticity mean the recipient can verify who issued the data and that it has not been altered, even after it has left the sender's system. That is signing, not only encryption, and clause 4.1 requires the integrity protection to be independent of the security of the channel the data travels over.

"Analytics on the passport page is a consent question"

The question is not only whether the tracking has consent. Clause 5.1.3 rules out external analytics tools in the passport service, and clauses 5.1.2 and 5.1.5 rule out collecting personal data and profiling on the public part, whatever the consent. How that relates to data protection law is a question for your own legal team.

"The standard requires a security chip in the label"

It does not. Secure elements in data carriers and cryptographic features for identifiers are explicitly out of scope.

How this looks in practice

The open validator in DPP Agent, built by Blippa, checks the three parts of EN 18246 that can be tested from outside: that public data is served without authentication (4.3), that it is readable on an ordinary device (5.4.2) and that the page loads no third-party tracking (5.1.2, 5.1.3 and 5.1.5). See also the overview of the DPP standards and the DPP standards page.