Digital Product Passport writing tends to fall into one of two unhelpful registers: policy explainers that translate the regulation into language only compliance teams can follow, and vendor brochures that sell software without describing what’s inside it. Brands and distributors heading toward the 2027 ESPR deadlines often end up with less clarity than they need about what they’re being asked to do.

This piece is an attempt to give the practical answer from a team that’s spent the last year building DPP infrastructure. We’ve published five live passports in production across textile and machinery categories. The work has clarified, repeatedly, the substance of a DPP and the steps required to build one.

The regulatory shape

A Digital Product Passport is a structured set of data about an individual product, served at a public web URL, accessible without an app, machine-readable by regulators and consumers alike. The EU’s Ecodesign for Sustainable Products Regulation (ESPR), which entered force on 18 July 2024, makes them a mandatory part of placing products in scope on the EU market.

The first ESPR delegated acts arrive in 2027. Textiles is one of the priority categories. Machinery is another, covered separately under the Machinery Regulation 2023/1230, applicable from January 2027. Batteries already have their own DPP under Regulation 2023/1542. Other categories (iron and steel, aluminium, furniture, tyres, detergents, paints, lubricants, chemicals, energy-related products, electronics) follow on a known schedule out to 2030.

For brands and distributors selling into the EU, this is not optional. ESPR Article 10 connects market access to passport publication: if the passport doesn’t exist or doesn’t meet the requirements, the product can’t be sold.

What’s inside a passport

A working DPP needs four things. They sound technical written down, but each one is concrete and solvable.

A persistent unique product identifier. The ESPR uses the term “unique product identifier” (UPI). The GS1 standards body, which sits behind the global GTIN system already on most product barcodes, supplies the practical answer: a GTIN at one of three granularity levels (model, batch, or item) is the unique identifier. For products requiring identification at the product type, the model-level GTIN already on the barcode is enough. Some categories (batteries explicitly, textiles likely) require finer granularity using batch numbers or serial numbers.

A data carrier on the product itself. A QR code is the primary carrier, supported on every smartphone camera. The ESPR specifically cites QR. Other carriers (Data Matrix, RFID, NFC) are options but QR is the default. The URL encoded in the QR is what gets a consumer or a regulator to the passport.

A web-resolvable URL using a standard syntax. GS1’s Digital Link standard provides the syntax: https://<domain>/01/<GTIN> for a model-level identifier, with optional /10/<batch> and /21/<serial> extensions for batch and item granularity. The crucial property is that the identifier persists independently of the domain. If the brand’s website ever moves, fails, or changes domain, the same product can still be identified by its GTIN and looked up in the backup repository or central registry.

A backup copy held independently. ESPR Article 11 requires the passport data to be held by a registered backup repository operated by a party independent of the primary publisher. This is where the planning gap is wide. Few brands have a backup-repository strategy in place. The EU is expected to designate or accredit a network of recognised backup providers; the practical implication is that no brand can rely solely on hosting their own passport data.

These four elements working together give a regulator scanning a QR code on a textile garment in 2027 the same access to the same product data as a consumer scanning it at home.

The data inside the passport

What goes into the passport varies by category. Each delegated act under ESPR specifies the fields required for that category. Textiles will need fibre composition, dye information, repairability and recyclability data, and social compliance information. Machinery needs technical specifications, maintenance and repair instructions, energy consumption details, and end-of-life handling guidance. Batteries need state of health, supply chain provenance for critical materials, carbon footprint data, and recycling information.

Across categories, two principles hold. The data should be structured, ideally as JSON-LD with schema.org as the semantic anchor, which makes the data interoperable between systems that have never seen each other before. And the data should follow a granularity hierarchy: facts about a product type apply at GTIN level, facts about a manufacturing batch apply at GTIN-plus-batch level, facts about an individual item apply at GTIN-plus-serial level. Higher-level facts inherit downward; lower-level facts don’t duplicate upward. This is one of the elegant parts of the standard, and one of the easier places to get wrong if the hierarchy isn’t designed in from the start.

What you actually do to build one

The work splits into three phases.

Phase one is data preparation. The data doesn’t usually live in one place. It’s scattered across PIM systems, spreadsheets, supplier emails, technical datasheets and the heads of category managers. The work isn’t producing new data; it’s gathering, structuring, and validating what already exists, then filling the genuine gaps. For a category like textiles, this might mean asking suppliers for fibre composition data they’ve never had to provide before. The data work will surface problems that have been quietly accepted for years, and the project plan should treat that surfacing as expected rather than as a setback.

Phase two is publication. The data needs to land at a URL conformant with GS1 Digital Link, served reliably, with appropriate access controls (public for the consumer-facing parts, restricted for the commercially sensitive parts). The URL needs to resolve in milliseconds in any jurisdiction where the product is sold, because a regulator in Berlin scanning a UK-manufactured garment shouldn’t experience a delay.

Phase three is operations. A DPP isn’t a static document. It’s a living record that updates when product data changes, when repairs happen, when the product moves through subsequent ownership. The back-end needs an audit trail (who changed what, when), versioning (so historical states can be retrieved), and a process for incorporating downstream events like repair or refurbishment. ESPR Article 11 covers data quality and integrity requirements; this is the part where early implementations need to harden.

What’s not in a passport, and why that matters

There’s a persistent misconception that a DPP is a marketing document. The ESPR is explicit that it isn’t: the passport is for regulatory and circular-economy purposes (identifying the product, confirming compliance, supporting reuse, repair and recycling). Brands that try to fill the passport with marketing copy will fail the compliance check.

There’s a related misconception that the passport replaces existing product content. In practice it sits alongside marketing, alongside instructions for use, alongside customer-facing chat. The GS1 “scan then select” pattern means the QR code on the product can resolve to a landing page with multiple links: the passport, the instructions, the warranty, the conversational interface, anything else the brand wants. The passport is one of these links, not the only one.

Common questions

How long does it take to publish a first passport? Around one working day if the brand’s product data is clean and a category-aligned schema already exists. It can take several weeks if the data needs to be gathered from suppliers and validated against the regulation.

Who owns the data? The economic operator (the brand owner or importer) owns the data. The platform that hosts the passport is the data processor, not the controller. The GDPR distinction matters here, particularly for any product data that touches personal information downstream.

Can a single brand publish passports for all its product lines on one platform? Yes. Multi-tenant platforms designed for DPP typically isolate each brand’s data and identifiers from every other brand’s, while sharing the underlying schema engine and publishing infrastructure.

Do I need to be a GS1 member? In practice, yes. GTINs come from GS1, which is the only authorised issuing agency for them. The cost is a sliding scale based on company turnover and the number of GTINs needed; check gs1uk.org for current pricing in the UK.

Where this goes next

The EU central registry is expected to go live in July 2026. From that point onward, every passport-bearing product placed on the EU market will need to be registered with the central registry as well as being individually published by the brand. The delegated acts for textiles and machinery follow in 2027. Other categories follow on the published schedule.

For brands and distributors heading toward 2027, the practical advice is to start the data work now. The technical layer (identifiers, URLs, hosting, backup) is largely solved by existing GS1 standards and platforms built on top of them. The data layer (collecting, validating, structuring what each delegated act will require for the specific category) is the longer and harder piece. Brands beginning the data work in 2026 will have something running before any delegated act bites, with time to refine it. Brands starting in 2027 will be doing the same work in compressed time and with thinner margins.

A Digital Product Passport, at its core, is a structured set of product data at a stable URL, accessible via a QR code, conformant with GS1 standards, and backed up by an independent third party. The regulatory language makes it sound harder than the engineering actually is. The harder part is the data preparation, and that’s where the early work pays off.