The problem
The EU Digital Product Passport stops being a planning exercise in 2027. The Commission’s DPP Registry went live on 20 July 2026 under Implementing Regulation (EU) 2026/1778, and from 18 February 2027 a battery passport is mandatory for EV and industrial batteries placed on the EU market above 2 kWh. Iron and steel are already in scope under ESPR, with aluminium, textiles and tyres following.
Most of the effort so far has gone into the data: what a passport must contain, who may see which parts, how it is hosted. The part that gets underestimated is the physical end. A passport is worthless unless the right passport can be reached from the right individual item, years later, by whoever is holding it.
A Digital Product Passport is a data problem with a physical dependency. The carrier on the item has to survive the product’s life, resolve to that item’s passport rather than the product line’s, and keep working when the item has changed hands three times.
What the standards actually require
This matters more than any vendor’s marketing, so it is worth stating precisely rather than loosely.
- EN 18219 covers unique identifiers. It requires a resolvable, globally unique identifier and permits several schemes, including GS1 Digital Link URIs, IEC 61406 identification links, W3C decentralised identifiers, RFID and 2D product identifiers, and DOIs.
- EN 18220 covers marking and data carriers.
- The Registry is a directory, not a data host. It returns where a product’s passport data lives when queried with a conforming identifier.
So a compliant passport needs an open, resolvable identifier that anyone in the chain can follow. That is a real constraint and it is the opposite of a closed, app-only carrier. Any supplier who tells you their proprietary code replaces a conforming identifier is selling you a compliance problem.
How VCode is deployed alongside it
VCode is not a substitute for a conforming DPP identifier, and this page will not pretend otherwise. It is the controlled identity layer that sits next to one, for the parts of the lifecycle where open resolution is exactly what you do not want.
- The passport stays open. Your conforming identifier and carrier do the regulated job: public passport data, reachable by anyone entitled to it.
- The controlled interactions run on VCode. Ownership transfer, warranty registration, service and repair events, end-of-life and recycling handoffs, authenticity checks and anything where the answer should depend on who is asking.
- Both point at the same item. One physical thing, one item-level identity in your systems, two ways of reaching it with different trust properties.
What happens when it is scanned
A consumer or recycler follows the passport carrier and gets the passport, as the regulation intends. Nothing about that changes.
The controlled interactions behave differently. A repairer scanning the VCode is identified before an event is written to the item’s history. An owner transferring the product does so through a route the manufacturer controls, so the record follows the item rather than being retyped. A refurbisher gets a response the brand configured for refurbishers. Each of those is recorded, which is precisely the lifecycle evidence a passport regime is trying to create.
Why a QR code or NFC alone is not enough
For the passport itself, a QR code carrying a conforming identifier is often exactly right, and it is what most implementations will use. Nothing here argues against it.
The gap is on the controlled side. An open identifier is, by design, resolvable by anyone. That is correct for public passport data and wrong for a warranty transfer or a repair authorisation. NFC is a strong answer where the unit economics work, and for high-value goods it frequently does, but chip cost across a full product population is a real number and some materials and form factors make it impractical.
VCode’s contribution is narrow and specific: the interactions where the response should depend on who is scanning, where, when, and what has already happened to that item.
What it changes commercially
- The passport becomes a relationship, not an obligation. You are already forced to give every item an identity; this is how it earns something back.
- Lifecycle data arrives with provenance. Events written by identified parties, not typed into a form.
- Second and third owners become reachable. Today they are invisible.
- Compliance work is not wasted. The item-level identity you build for the regulator carries the commercial functions too.
Integration
Codes are minted per item through the platform API as part of the production run, alongside whatever identifier and carrier your DPP implementation uses. Reading runs through your own application via the SDK, so the controlled interactions stay inside your brand or service experience. Scan history provides the event record. See the developer documentation.
Preparing for a passport deadline?
Tell us the category and the date you are working to. If your requirement is only the passport carrier, we will tell you that a conforming QR implementation is enough and that you do not need us for it.