How to Create a Digital Product Passport: The Six Harmonised Standards as a Build Spec

Most teams asking how to create a Digital Product Passport are really asking which platform to buy. That is the wrong first question, and it is the reason so many DPP programmes stall at month four: the vendor is selected, the contract is signed, and then the project discovers there is no product identifier scheme, no owner for substance data, and no decision about what goes on the physical item.

There is now a better first question, because there is a specification. On 14 July 2026 the Commission adopted Implementing Decision (EU) 2026/1736, citing the first harmonised standards for the Digital Product Passport in the Official Journal. Conformity with them confers a presumption of conformity with the DPP requirements in Articles 10 and 11 of ESPR, to the extent the standards cover them.

Six standards, six pieces of work. None of them is a software purchase.

The six standards, and what each one makes you decide

Standard	Subject	The decision it forces
EN 18219:2026	Unique identifiers	What identifies a product, a model, an operator - and at what granularity
EN 18220:2026	Data carriers	What physically goes on the product, and how it survives the product
EN 18221:2026	Data storage, archiving and persistence	Where the passport lives, and for how long after you stop making it
EN 18216:2026	Data exchange protocols	How supplier data gets in and authority data gets out
EN 18222:2026	APIs for passport lifecycle and searchability	Who can query it, and what happens when it changes
EN 18223:2026	System interoperability	Whether anyone else's system can read yours

Reference lists for these were published by the Commission and cited in the Official Journal in July 2026.

Step 1: settle identifiers before anything else (EN 18219)

Every passport regulation so far requires a unique product identifier, and the choice of scheme is not a technical detail - it decides the granularity of your entire programme.

The question to answer first is what a passport is about. The battery passport is per unit: state of health means nothing at model level. The toy passport is per model. Get this wrong and you either generate a hundred thousand passports you cannot populate, or one passport that cannot carry the per-item data a later regulation demands.

Then decide where the identifier comes from. You need an operator identifier and a facility identifier alongside the product one, and they need to be stable across an ERP migration, a factory change and a corporate restructure. If your product identifiers today are SKUs that marketing renumbers each season, that is the first thing to fix, and it is an internal governance job, not a vendor feature.

Step 2: decide what goes on the physical product (EN 18220)

The data carrier is the part of the passport that has to survive manufacturing, transport, shelf life and, for durable goods, years of use. Deciding it late is expensive, because it touches packaging artwork, label suppliers, moulds and print runs.

The regulations are permissive about which carrier - QR code, NFC, RFID, or another automatic identification medium - and unhelpfully silent about placement. So the real constraints are physical:

• Does it survive the product's life? A printed label on a garment tag is fine for a season and useless in year eight. For anything durable, the carrier has to be on the product, not the packaging.
• Can it be read where it matters? By a consumer in a shop, a recycler on a sorting line, a customs officer at a border, and a repairer with the product in pieces.
• Does it resolve when your systems change? The carrier is printed once and permanent. What it points to must be a resolvable identifier, not a URL tied to a hosting arrangement you might leave.

That last point is the one that catches people. A carrier encoding a link to your current vendor's domain becomes a liability the moment you switch vendors.

Step 3: choose a retention horizon you can honour (EN 18221)

Persistence is a legal requirement with a number attached, and the numbers differ sharply by sector. Toys and detergents: technical documentation and passport kept for ten years after placing on the market. The construction DPP system: accessible for 25 years after the last product of that type is placed on the market.

Two consequences follow. First, take your retention assumption from the longest-lived market you sell into. Second, the passport has to outlive your vendor relationship, which means an exit path - a documented export format and a tested restore - is a procurement requirement, not a nice-to-have. Ask any prospective platform what happens to live passports if you stop paying them, and make the answer contractual.

Step 4: build the supplier data pipeline (EN 18216)

This is where DPP programmes actually fail, and no platform fixes it.

The fields that matter most - substance content, recycled content, carbon footprint - are held by suppliers you may not have a direct relationship with. Collecting them means a contractual mechanism (a clause requiring structured data to a named schema), a technical mechanism (an exchange protocol, not a spreadsheet emailed to a shared inbox), and a quality mechanism (what you do when a tier-three supplier sends a number it cannot evidence).

Start this before the software. It is the only part of the work with a multi-year lead time, and it is identical whichever platform you eventually buy.

Step 5: model access as configuration, not code (EN 18222)

Every passport regime so far splits its data by who is asking. The battery passport does it in three tiers under Annex XIII: public, authorities, and persons with a legitimate interest. Other regimes will draw the lines elsewhere.

And the lines can move after you build. The implementing act defining who has a legitimate interest in non-public battery data was legally due on 18 August 2026 and was not adopted, with the Commission's timetable now pointing to Q4 2026 - while the 18 February 2027 passport obligation stayed exactly where it was.

So the design rule is simple: never hard-code an access tier. Build a permission model in which a tier is a configuration object with a membership rule, a field list and an audit trail, so that when the rules finally arrive you change a configuration rather than a codebase.

Step 6: register, and treat registration as a release step (EN 18223)

The EU central DPP Registry has been operational since 20 July 2026. Registration is what makes a passport findable by an authority, and under the detergents regulation the passport must be declared at customs when an imported product is presented at the border. A passport that exists but is not registered is, from an enforcement point of view, a product without a passport.

The practical implication is that registration belongs in your product release process, next to the steps that generate the declaration of conformity and the label - not in a quarterly compliance catch-up.

Then, and only then, choose a platform

By this point you have an identifier scheme, a carrier decision, a retention horizon, a supplier data pipeline, an access model and a registration step. Those are your requirements, and they are specific enough to evaluate a vendor against rather than being led by one.

And notice what the sequence implies about the ESPR product groups still waiting for a delegated act - which, in September 2026, is all of them. The six standards apply horizontally. Every step above can be completed now, without knowing a single field your act will demand, because none of it is field-specific. The fields are the last thing you add, and the easiest.

The work that takes years is the work you can start this quarter.