By the VixQR team · published on · 10 min read
The EU Digital Product Passport: What the QR Code Requirement Actually Means
Batteries face a hard DPP deadline in February 2027. What the EU Digital Product Passport requires from a QR code — and the vendor myth worth ignoring.
There's a piece of European law that will put a QR code on nearly every physical product sold in the EU, and most of the articles explaining it are written by companies selling QR code subscriptions. That's a problem, because the single most repeated claim in those articles is wrong.
Let's go through what the Digital Product Passport actually requires, what the dates really are, and which part of it is genuine regulation versus vendor marketing.
What a Digital Product Passport is
A Digital Product Passport — DPP — is a structured digital record attached to a physical product. It holds the product's identity, what it's made of, how long it should last, whether it can be repaired, what its carbon footprint is, and what to do with it at end of life.
The record lives online. The product carries a data carrier — in practice, a QR code — that links the physical object to that record.
The legal basis is the Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, which entered into force in July 2024. The ESPR is a framework: it establishes that DPPs exist and how they work in general, but the specific data fields and deadlines for each product category come later, through separate "delegated acts" adopted category by category.
That two-layer structure explains most of the confusion around dates. The framework is settled law. The obligations arrive one sector at a time, and only a few have landed.
The dates that are actually firm
Only one deadline is genuinely fixed and confirmed:
18 February 2027 — batteries. From that date, a digital battery passport is mandatory for electric vehicle batteries, light means of transport batteries (e-bikes, e-scooters), and industrial batteries above 2 kWh placed on the EU market, including batteries installed inside other products. This obligation comes from the Batteries Regulation (EU) 2023/1542, not from the ESPR, which is why it's ahead of everything else and why its rules are already finalised.
Everything after that follows the adoption of its delegated act, with roughly 18 months between adoption and enforcement. The Commission's indicative sequence looks like this:
| Sector | Expected milestone |
|---|---|
| Batteries (>2 kWh, EV, light transport) | 18 February 2027 — firm |
| Iron and steel | First pilot delegated act, 2026 |
| Textiles, tyres, aluminium | Delegated acts 2027, obligations to follow |
| Energy-related products | 2026–2029 |
| Furniture | Delegated act expected 2028 |
| Mattresses, ICT products | 2029 |
Treat every row except the first as expected, not fixed. Anyone giving you a confident date for textile DPP compliance is guessing — the delegated act defining the actual data requirements hasn't been adopted yet.
Two pieces of infrastructure did land recently, and they matter more than the speculative dates:
The DPP Registry went live on 20 July 2026. This is the central EU database that stores the unique identifier for every passport, along with mandatory registration data. Commission Implementing Regulation (EU) 2026/1778, published 16 July 2026, sets out how it works — access management, operator verification, data registration, technical architecture — and applies from 6 August 2026.
The technical standards are published. Six European standards came out on 27 May 2026, covering unique identifiers (EN 18219), data carriers (EN 18220), data exchange protocols (EN 18216), the lifecycle API and searchability (EN 18222), system interoperability (EN 18223), and storage, archiving and persistence (EN 18221). Two more — on access rights and information security, and on authentication and data integrity — remain final drafts under formal vote.
The practical consequence: you can start building before your delegated act exists. The identifier scheme, the carrier, and the data architecture are specified. Only the field list for your specific category is still open.
What's actually inside a passport
The exact fields vary by category, but the ESPR framework groups them into four families. Knowing the shape of it early tells you which internal systems you're going to have to connect.
Identification. A globally unique identifier, the brand, the model, the manufacturer, and the economic operator responsible for placing the product on the market.
Durability and repairability. Expected lifespan, spare-part availability and pricing, repair instructions, a repairability score, digital manuals.
Composition and environment. Materials and weight per component, substances of concern, lifecycle carbon footprint, recycled content, energy class, material provenance.
Compliance and end of life. Declarations of conformity, certifications, dismantling and recycling instructions, take-back schemes, resale and repair pathways.
The battery passport goes further than any of these and is worth studying even if you don't make batteries, because it shows where the rest is heading: it carries continuously updated state-of-health data from the battery management system, declared carbon footprint, recycled content thresholds and performance classes. It's the only current DPP that inherently requires connected infrastructure rather than a one-time publication at manufacture.
Two points people miss about who this lands on.
"Economic operator" includes importers. If you bring a covered product into the EU market, the obligation is yours even though you didn't manufacture it — and the data you need sits with a supplier who may be outside the EU and under no equivalent obligation. That gap is where most compliance programmes get stuck.
The hard part isn't the technology. Building a QR code and a data endpoint is a few weeks of work. Collecting accurate, product-level material and footprint data across a supply chain, and keeping it current for a decade, is a multi-year organisational project. Teams that treat DPP as a labelling exercise discover this late and expensively. It's a data architecture problem wearing a packaging costume.
What the QR code has to do
Here's where it gets interesting, and where most vendor content misleads.
ESPR Article 10 requires the passport to be accessible via a physical data carrier affixed visibly to the product or its packaging, using open, interoperable formats without vendor lock-in. QR codes, NFC chips and RFID tags all qualify. QR codes dominate in practice because every phone reads one without an app, and printing one costs nothing.
The carrier has to encode a persistent, resolvable, globally unique identifier. Three words worth unpacking:
- Unique — it identifies this model, batch, or individual item and nothing else.
- Resolvable — it's a URL that leads somewhere. Not a serial number in a database only you can query.
- Persistent — and this is the one with teeth. Manufacturers must maintain DPP data for a minimum of ten years after the product is placed on the market. If the company ceases operations, the data transfers to the Commission's registry.
Ten years. That obligation, more than anything else in the regulation, should shape how you think about the code on the pack.
There's also a granularity decision that drives everything downstream: does a passport cover a model, a batch, or an individual item? Batteries require item-level serialisation. Other categories may permit model-level. This one choice determines your volume, your cost, and the design of every system that touches it.
And the record behind the code isn't a public web page. The Commission's Joint Research Centre published a 121-page methodology document (JRC145830, March 2026) setting out a five-tier access model: consumers, regulators, recyclers, supply chain partners and market surveillance authorities each see different views of the same underlying data. So the identifier has to resolve to something that returns different content depending on who's asking, with what credentials.
That's an API with an access-control layer. Not a PDF.
The myth: "you need a dynamic QR code"
You will read, repeatedly, that DPP compliance requires a dynamic QR code — meaning a code that points at a redirect service you rent monthly, so the destination can be changed from a dashboard.
The reasoning goes: DPP data must stay current throughout the product's life, a static QR code points at a fixed URL, therefore static codes are "structurally incompatible" with the DPP.
This conflates two completely different things: the address and what lives at the address.
A QR code encodes a URL. That's all it does. If the code says yourbrand.com/dpp/A1B2C3, then updating what a scanner sees means updating the page — or the API response — at that address. The printed code never changes because the address never changes. The content behind it changes as often as you like.
That's not a limitation. That's how the entire web works.
What a commercial "dynamic QR" adds is an intermediate hop: the code points at vendor.com/x7k2, which redirects to wherever you've configured. Useful if you don't control a domain, or if you need to repoint a code at a completely different destination later. But for a DPP, the destination is your own product record — the one thing that will never need repointing somewhere else.
And now put that against the ten-year persistence obligation. A vendor redirect introduces a third party between your product and its legally required data, for a decade. If the subscription lapses, if the vendor is acquired, if the service sunsets, every code in the market breaks — and the compliance failure is yours, not theirs.
Vendors have started marketing "non-expiring code guarantees" as the answer to a risk their own architecture creates. A URL on a domain you own has no expiry to guarantee.
The honest version of the requirement: your identifier must resolve reliably for ten or more years, and the data it resolves to must stay current. A code pointing at a URL on your own domain satisfies both, permanently, with no recurring cost. A commercial redirect can also satisfy both — it just adds a dependency you didn't need.
The other myth: "GS1 Digital Link is mandatory"
It isn't. EN 18219 requires a resolvable, globally unique identifier. GS1 Digital Link is one conforming option among several, not the only lawful one.
That said, there's a strong practical argument for it if you're a packaged-goods brand. GS1 Digital Link encodes your product's GTIN inside the URL, which means the same code can be read at a retail checkout and by a customer's phone. If you're also preparing for GS1 Sunrise 2027 — the separate industry initiative to get retail point-of-sale systems reading 2D codes by end-2027 — then one properly built code covers both.
Two different requirements, one technical solution. We covered the retail side in detail in our guide to GS1 Sunrise 2027.
If you're not selling through retail checkouts, GS1 syntax is overhead you don't need. A resolvable URL on your own domain is compliant.
What to actually do this year
Confirm whether you're in scope, and when. Identify your product categories and find the delegated act — or the Batteries Regulation — that covers them. If you make batteries above 2 kWh, EV batteries or e-bike batteries, February 2027 is real and close. If you make textiles, you have time to build but not to ignore it.
Decide your granularity first. Model, batch, or item. Everything else depends on it, and changing your mind later is expensive.
Audit your supply-chain data. This is almost always the critical path, and it surprises people. The technology is straightforward. Getting accurate material composition, carbon footprint and provenance data out of your suppliers — and keeping it current — is the hard part. Start there, not with the QR code.
Pick an identifier scheme and a carrier. Decide whether GS1 Digital Link earns its complexity for you. Choose a carrier that survives the product's whole life: a QR code printed on a hangtag that falls off doesn't meet a ten-year obligation.
Sort out hosting and persistence. In-house or a DPP service provider — either way you need a documented back-up arrangement, because persistence beyond your own existence is a legal requirement, not an aspiration.
Run a pilot on one product range. Pick something with clean data and low business risk. A pilot surfaces the data-quality problems no architecture diagram will, and it does it before you've committed a print run.
Register in the Registry. It's live. If your category has a confirmed obligation, verification and registration are prerequisites, not last steps.
If none of this applies to you
If you print QR codes for a shop, a restaurant, an event or a service, the Digital Product Passport doesn't reach you. There's no product being placed on the EU market, no material composition to declare, no ten-year obligation, no registry.
The principle underneath it is still worth borrowing, and it costs nothing: point your codes at a URL you control. Then the destination can change forever — new menu, new campaign, new site — without reprinting anything or renting anything.
That's the same instinct behind the DPP's persistence requirement, applied at a scale where it's free.
For that, a plain QR code aimed at your own domain does the job permanently. VixQR generates them free, entirely in your browser, with SVG and PDF export for print — no account, and no subscription that can lapse and take your printed codes with it.
This article summarises publicly available regulatory information as of August 2026 and is not legal advice. DPP obligations are set by product-specific delegated acts that are still being adopted; confirm your own requirements against the current text of the applicable regulation and, where the stakes justify it, with a compliance specialist.