In 2026, CEN/CENELEC finalised eight European Standards — the EN 1821x series — that define how every EU Digital Product Passport is identified, carried, exchanged, stored, secured and authenticated. Here is what each standard does, how they fit together, and what they mean if you place products on the EU market.
The Digital Product Passport now has a rulebook for how it actually works. In 2026, the European standards body CEN/CENELEC finalised eight European Standards (EN) — the EN 1821x series — that define the common machinery behind every Digital Product Passport (DPP) placed on the EU market. They were written by CEN/CLC Joint Technical Committee 24 ("Digital Product Passport — Framework and System"), and they are the part of the DPP that most coverage skips: not what a battery or a T-shirt has to disclose, but how any passport is identified, carried, exchanged, stored, secured and trusted.
This is a field guide to those eight standards — what each one governs, how they fit together as a single system, and what it means if you place products on the European market. Regen Studio sat inside this work, in the JTC 24 security and interoperability working groups and on the Dutch NEN mirror committee, so the reading below is grounded in the drafts themselves.
The Digital Product Passport system has three layers. Sectoral acts (ESPR, batteries, textiles, detergents, construction) define what each product must disclose. The eight JTC 24 system standards define how any passport is built, moved, stored and trusted. A physical product carries a unique identifier on a QR or RFID data carrier, which resolves against the central EU DPP Registry; the registry holds identifiers and metadata while the passport content itself stays decentralised with the operator or a DPP service provider.
What just happened
The eight DPP system standards went through CEN/CENELEC public enquiry in mid-2025, reached formal vote in early 2026, and are now ratified and becoming available as European Standards through the national standards bodies (in the Netherlands, as NEN-EN). One important nuance for compliance teams: "available" is not the same as "harmonised." An available EN can be bought and implemented today, but it only confers a presumption of conformity with the law once it is cited as a harmonised standard in the Official Journal of the European Union under the relevant mandate. That citation step, for the DPP standards, is still ahead. So the right posture now is: build to these standards, but track the harmonisation status before you rely on them for legal presumption.
The eight standards are horizontal. They are deliberately product-agnostic, so the same identifier scheme, the same QR code, the same API and the same signature work whether the product is a battery, a garment, a detergent or a construction product. That is the whole point: write the plumbing once, and let every ESPR delegated act and sectoral regulation reuse it.
The eight standards at a glance
| Standard | Official title | What it governs | Group |
|---|---|---|---|
| EN 18219 | Digital product passport — Unique identifiers | How products and operators are uniquely and persistently identified | WG2 · Identity |
| EN 18220 | Digital product passport — Data carriers | How the identifier is physically carried on the product (QR, Data Matrix, RFID) | WG2 · Identity |
| EN 18216 | Digital product passport — Data exchange protocols | The transport layer for moving passport data between systems | WG4 · Interop |
| EN 18222 | Digital Product Passport — Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability | The exact API methods to read, create, update and search passports | WG4 · Interop |
| EN 18223 | Digital Product Passport — System interoperability | The shared data model and semantics every passport conforms to | WG4 · Interop |
| EN 18221 | Digital product passport — Data storage, archiving, and data persistence | Keeping the passport available — and versioned — for the product's whole life | WG4 · Interop |
| EN 18239 | Digital Product Passport — Access rights management, information system security, and business confidentiality | Who can read or write what, and how trade secrets are protected | WG3 · Security |
| EN 18246 | Digital product passport — Data authentication, reliability and integrity | Proving a passport is genuine and has not been tampered with | WG3 · Security |
JTC 24 organised the work into four working groups: a strategic advisory group (WG1), unique identifiers and data carriers (WG2), security (WG3), and the interoperability framework (WG4). The eight standards above map onto WG2, WG3 and WG4.
What each standard does
Identify & carry
EN 18219 · EN 18220 — the bridge from a physical product to its digital passport (WG2)
EN 18219Unique identifiers. Before anything else, a passport needs a name that is globally unique, never reused, and stable across the product's life. EN 18219 codifies five permitted product-identifier schemes — web-enabled structured paths (such as a GS1 Digital Link URI), self-issued Identification Links (IEC 61406), Decentralized Identifiers (W3C DIDs), RFID/2D product identifiers, and Digital Object Identifiers (DOIs) — plus four operator-identifier schemes including the GLEIF Legal Entity Identifier. The deliberate design choice is choice: a multinational can keep its GS1 estate, while a cooperative can self-issue a DID, and both still resolve into the same system.
EN 18220Data carriers. The identifier has to physically reach a phone at the shelf, the repair bench or the recycling line. EN 18220 governs how it is encoded onto the product — 2D symbols (QR Code, Data Matrix) and RFID (HF, NFC and UHF/RAIN) — with rules on placement, marking and quality. The baseline guarantee that matters to a shopper: at least one carrier must be free to use and readable with an ordinary smartphone, no app download required.
Move, structure & store
EN 18216 · EN 18222 · EN 18223 · EN 18221 — the interoperability framework (WG4)
EN 18216Data exchange protocols. Every passport has to move — from the manufacturer's system to a service provider, to a recycler, to a regulator. EN 18216 fixes the transport layer: RESTful APIs over HTTPS with TLS, structured message formats, and authenticated, confidential, tamper-resistant exchange. It is the lowest common denominator that lets two systems that have never met talk to each other.
EN 18222Lifecycle APIs. Where EN 18216 says "use REST," EN 18222 says exactly which calls. It specifies the API methods to create, read, update and search passports — element-level operations, batch retrieval, versioning queries and registry submission — so a refurbisher can read a passport, append a repair record, and write it back without a bespoke integration for every partner.
EN 18223System interoperability. A battery passport and a textile passport carry different facts but share a structure. EN 18223 defines that shared data model — the container, its metadata, and how each data element links to a machine-readable definition in a semantic repository — so customs systems, repairers and, increasingly, AI agents can interpret any passport without manual mapping. This is the standard that makes the data meaningful, not just transportable.
EN 18221Storage, archiving & persistence. A passport must stay reachable for the life of the product — potentially a decade or more — and keep its history. EN 18221 makes the operator responsible for ongoing availability, requires a backup via a DPP service provider, and mandates archived versions so a regulator can see what was claimed in 2027 versus today. It is deliberately storage-technology-neutral, which keeps the cost reachable for small operators.
Secure & trust
EN 18239 · EN 18246 — access control and provenance (WG3)
EN 18239Access rights, security & business confidentiality. Not all passport data is public. EN 18239 separates open data (recyclability, repair instructions) that anyone can read from controlled data (sourcing, trade secrets) that needs authenticated, role-based access aligned with eIDAS levels of assurance — and frames it inside recognised information-security management practice. It is the standard that lets a manufacturer be transparent and protect what is genuinely confidential.
EN 18246Data authentication, reliability & integrity. A counterfeit battery is a safety hazard; a falsified origin claim is fraud. EN 18246 ensures a passport can be proven genuine and tamper-evident through an electronically signed data construct, implementable with W3C Verifiable Credentials, an Electronic Attestation of Attributes (EAA) under eIDAS, a Visible Digital Seal (ISO 22376) or a Digital Signature data structure (ISO/IEC 20248). With full audit logging of every change, tampering can be both detected and attributed. This is where the "trusted" in a trusted DPP is actually earned.
How the system fits together
The clearest way to read the DPP is as three layers. Sectoral acts define the content — the Battery Regulation says what a battery passport must contain, an ESPR delegated act says the same for textiles or furniture, and so on. The eight JTC 24 standards define the system — identity, carriers, exchange, structure, storage, access and authentication, once, for everyone. And the central EU DPP Registry is the coordination point — it holds the identifier and metadata of every passport, while the passport content itself stays decentralised with the operator or a service provider.
That decentralised-but-coordinated design is the quiet genius of the architecture. The Commission does not run a giant database of every product's data; it runs a registry of pointers, and the JTC 24 standards make sure that whatever sits behind each pointer is identifiable, reachable, interoperable and verifiable. We unpack the registry side in our companion piece, The EU DPP Registry explained, and you can see the content side in action across regimes: batteries, textiles, detergents and construction products.
Where Regen Studio sits in this
Our involvement in the DPP standards started a few years ago and through a specific door: the Trusted Digital Product Passports position paper that Regen Studio led for FIDES, commissioned by the Dutch Blockchain Coalition. That work — on how trust, identity and verifiable credentials could underpin a circular economy — is exactly the territory the JTC 24 security (WG3) and interoperability (WG4) working groups went on to formalise — which led us to take part, in the name of Yvo Hunink de Paiva, in those JTC 24 working groups, alongside a seat on the NEN national mirror committee that channels the Dutch position into the European drafts.
Our engagement in the committee work has wound down significantly over the past year as the standards moved from open design into formal balloting and as our focus shifted to helping operators actually implement DPPs. We are writing this not as the authors of the standards, but as practitioners who were in the room while they took shape and who now read them daily on behalf of the companies that have to comply. That vantage point — standards-literate, but operator-facing — is the one we think is most useful to share.
That practitioner stance is also why we have already built a requirements registry on top of the JTC 24 standards — a clause-by-clause map of what each of the eight standards actually demands. It lets DPP system builders monitor, requirement by requirement, where their system already complies and where the gaps still are. The standards are the rulebook; the registry is how you check an implementation against it.
What it means if you place products on the EU market
First, the calm part: a DPP is not mandatory for everyone today. These eight standards are infrastructure; the obligation to publish a passport comes from the sectoral acts, on their own timelines. The first hard deadlines are the Battery Regulation, with passport obligations from 18 February 2027, and the Detergents Regulation, from 23 September 2029 — so far the only two product groups with a fixed DPP date. For textiles, furniture and the rest, the ESPR delegated-act timing is still indicative.
Second, the useful part: because the system layer is now stable, you can prepare against a fixed target rather than a moving one. Practically, that means knowing which identifier scheme fits your product and supply chain (EN 18219), which carrier your packaging and materials allow (EN 18220), whether you will host the passport yourself or use a service provider (EN 18221), and how you will sign and protect it (EN 18246 and EN 18239). For smaller operators especially, the standards were written to keep those choices proportionate — the cheapest compliant path is usually a plain QR code, a hosted passport and an off-the-shelf signature, not a bespoke platform.
See it in action
Want to see these eight standards working together?
Our interactive demo traces sustainable furniture from Brazilian forests through manufacturing — with unique identifiers, a QR data carrier, verifiable credentials and ESPR-aligned data threaded all the way through.
Explore the DPP System Demo →Sources & further reading
- CEN/CENELEC — Digital Product Passport topic page (overview of JTC 24 and its standards)
- CEN/CLC/JTC 24 — standards catalogue (the EN 1821x series and their status)
- CEN/CENELEC — News (announcements on DPP standardisation)
- Ecodesign for Sustainable Products Regulation (ESPR), Reg (EU) 2024/1781 — the parent regulation
- NEN — the Dutch national standards body, where the EN 1821x texts are available as NEN-EN standards
Regen Studio contributed to the CEN/CLC JTC 24 security and interoperability working groups and the NEN national mirror committee for the Digital Product Passport, with roots in the FIDES "Trusted DPP" work commissioned by the Dutch Blockchain Coalition. Standard titles and clause references reflect the EN 1821x drafts as balloted; always check the published EN and its harmonisation status before relying on it for compliance.