Why DPP Projects Fail When Product Identity Is an Afterthought

The Pattern

The pattern is rarely the result of a bad decision. It’s the result of a reasonable decision made by one team, on its own criteria, on a deadline.

A compliance team receives a delegated act, lists the required fields, and procures a tool to publish them. The data carrier is a QR code because it’s cheapest. The identifier is model-level because that’s the minimum. The resolver is the vendor’s domain because it came with the tool. The passport goes live. Then other teams arrive.

Brand protection ask: sCan the passport code authenticate? No: it’s a printed QR, copyable onto fakes.
Supply chain asks: Can scans show diversion? No: the identifier is model-level, every unit is identical.
Client services asks: Can it support resale and ownership? No: no item identity to attach an owner to.
IT asks: Can we change vendor? Only by redirecting a domain we don’t own, forever.

None of these teams is wrong to ask. Each has a real problem that item-level identity on a secure carrier would solve. The passport project simply wasn’t designed to solve it, and by the time they ask, the products are already carrying the answer.

Each of these conversations happens after the products are already in market, carrying the code. That’s the defining feature of the failure: by the time anyone notices, the decision is physically fixed on thousands or millions of units.

Five ways it goes wrong

Five failure modes recur across sectors. Most passport projects that run into trouble hit at least two of them.

Pitfall	Threat	Mechanism	Outcome
The copyable passport	Counterfeiters reproduce the printed passport code on fakes.	The fake resolves to genuine passport data.	The passport makes counterfeits more convincing.
The wrong granularity	A model-level identifier is chosen to meet the minimum.	Item-level needs later require a second carrier.	Products carry two codes; consumers scan the wrong one.
The disposable carrier	The passport code is printed on outer packaging.	Packaging is discarded at purchase.	Repairers and recyclers can’t reach the passport years later.
The vendor-owned identifier	Identifiers point to the tool vendor’s domain.	Switching vendor breaks every code in market.	Permanent dependency or permanent redirects.
The second record	The passport tool keeps its own product data.	Authentication and traceability systems hold different records.	Three versions of the same item, none authoritative.

What these failures have in common is that they’re invisible at launch. The passport works, the compliance date is met, the project closes. The cost appears months or years later, in another team’s budget.

The decisions made fastest in a passport project are the ones that last longest.

The first is the most damaging for premium brands. A passport is meant to inform and build trust. On a copyable code, it does the opposite: a counterfeiter who reproduces the code gives the fake a genuine page of materials, origin and care information. The more complete and credible the passport, the more convincing the counterfeit becomes.

Why the timing makes this urgent

Three developments in 2026 turned this from a theoretical risk into a practical one. The EU’s central DPP registry went live on 20 July 2026. The EU formally recognised NFC as a compliant passport data carrier (Implementing Decision (EU) 2026/1736, referencing EN 18220), which removed the last argument that secure carriers were a compliance risk. And the first product-group requirements are close: textiles are expected indicatively from 2027, with obligations applying around 18 months after each act enters into force, and battery passports apply from 18 February 2027.

That timeline creates pressure to choose quickly. Quick choices default to the cheapest carrier, the minimum granularity and whichever domain comes with the tool. Those defaults are exactly the decisions this piece is about.

A passport on a copyable code doesn’t just fail to stop fakes. It makes them more convincing.

The cost of retrofitting

Element	Easy to change later?	Why
Passport content	Yes	Data, updated in software
Access rights	Mostly	Configuration, if the model supports roles
Hosting provider	Only if the domain is yours	Identifiers on products point to a domain
Identifier granularity	No	Requires new serialisation and new carriers
Data carrier	No	Physically on every product already shipped

The asymmetry is the whole argument. The elements compliance tools focus on, content and display, are the cheapest to change. The elements they treat as defaults, carrier, granularity and domain, are the most expensive.

Retrofitting granularity or carrier means two things: a new carrier on all new production, and a long tail of products in market that carry the old one. For durable goods that tail can last years, so the brand runs two systems in parallel for a long time.

There’s a hidden cost too: confusion. When products carry two codes, one from the passport project and one from a later authentication programme, consumers scan whichever they see first. Data splits across two systems, engagement drops, and the brand has to explain to customers which code means what.

The carrier decision, side by side

Most of the damage traces back to one choice: what goes on the product. Here is how the main options compare when the passport is only one of the jobs the carrier will have to do.

	Printed GS1 Digital Link QR	Copy-resistant print (e.g. ACM-secured barcode, Diamond Dust)	Cryptographic NFC (NTAG 424 DNA class)
Passport access	Yes	Yes	Yes, any recent phone, no app
Proves the item is genuine	No, a photocopy scans the same	Yes, the print is hard to reproduce	Yes, new signed message on every tap
Tamper evidence	No	No	Yes, with TagTamper variant
Indicative unit cost	Near-zero print cost	Print plus security feature	About USD 0.45–0.65 at five-figure volumes (public catalogues, 2026)
Fits	Low-value goods, passport only	High volumes needing protection	Premium goods, resale, sealed products

The point isn’t that every product needs NFC. It’s that the carrier should be chosen for every job it will have to do over the product’s life, not only the first one. Many premium programmes combine a visible QR for passport access with NFC as the trust layer, both pointing to the same item.

Who pays for the afterthought

Team	What they inherit	Cost
Brand protection	A copyable code on every product	A second, secure carrier, or counterfeits with valid passports
Supply chain	Model-level identifiers	No diversion visibility without new serialisation
Client services	No item identity	Resale and ownership handled by third parties
IT	Vendor-owned resolver domain	Permanent dependency or redirects
Operations	A second carrier to apply	Line changes made twice

The compliance project’s budget looks lean. The total cost of the decisions it made sits in five other budgets.

Identity first: what to decide, and in what order

Decide first

Item-level identity where any business case needs it
A carrier that can’t be copied, on the product itself
GS1 identifiers on a brand-owned resolver domain
One item record that every use case reads

Then build the passport as

A view of the item record, filtered by regulation
Role-based access on the same resolver
Content mapped from existing data sources
An update as delegated acts evolve

This isn’t more work. It’s the same work in a different order. For the foundations, see Digital Product Identity: What It Is and Why It Matters; for the practical roadmap, Digital Product Passport: Requirements by industry

Identity first doesn’t mean delaying the passport. Identifier standards, carrier choice and domain ownership can be settled in weeks. They’re decisions, not builds. The passport project then proceeds as planned, on foundations that other teams can use.

In practice, identity-first means one short working session before the passport project starts, with compliance, operations, brand protection, supply chain, digital and client services in the room. The output is four decisions on paper. The passport project then runs as planned, and every other team inherits foundations it can use.

What identity-first looks like by sector

Sector	Threat	Mechanism	Outcome
Fashion and textiles	Early passport obligation, high counterfeit exposure.	Item-level identity on a woven or care-label NFC tag, with a visible QR for passport access, both on one record.	Compliance on time; the same tag authenticates in resale.
Luxury leather goods	Resale is a major channel; passport requirements expected later.	Sewn-in cryptographic NFC with ownership certificates now, passport views added when required.	Business value from day one; compliance becomes an extension.
Watches and jewellery	High-grade copies, service and resale value.	On-metal NFC in the case or certificate card, linked to service history and ownership.	Passport data, if required, joins an existing record.
Wine and spirits	Beverages outside ESPR scope; refill and diversion are the real threats.	TagTamper NFC in the capsule for first-open evidence and diversion detection.	Ready for packaging or retailer data requests without a new carrier.

The common thread: the identity is designed for the hardest job the product faces, and the passport becomes a view on it rather than a separate system.

Who should make the identity decisions

Because identity decisions affect every team, they shouldn’t be made by the passport project alone. A short decision process works best.

Convene the affected teams: Compliance, operations, brand protection, supply chain, digital, client services.
List each team’s use of item identity: Today and within three years.
Decide the four foundations: Granularity, carrier, identifier standard, resolver domain.
Hand the passport project its foundations: It proceeds on schedule, on identity that others can reuse.

Three questions for your DPP project this quarter

Can our passport carrier be copied? If yes, what stops a counterfeit from carrying it?
If we needed item-level identity next year, would we re-tag? If yes, the granularity decision is being made by default.
Whose domain is printed on our products? If it’s the vendor’s, so is the exit cost.

For luxury-specific implications see How DPP Will Impact Luxury Supply Chains.

If the honest answer to any of these is uncomfortable, the time to fix it is before the next production run, not after the next delegated act.

How Selinko helps brands put identity first

Selinko, part of TOPPAN, builds item-level identity that serves the Digital Product Passport, authentication, traceability and ownership from one record. Brands come to us at two moments: before a passport project, to set the foundations, and after one, when another team discovers it can’t use what’s on the product.

Carrier chosen for every job, from a portfolio spanning NFC (including tamper-evident), secure QR, RFID, ACM-secured barcodes and Diamond Dust.
Commissioning on the line with ILM Station, so every unit carries a working, registered identity.
One record in SelinkoTrack serving passport views, authenticity results, ownership certificates and grey market detection.
Standards and portability: GS1 identifiers on a domain the brand controls, so the passport outlives any vendor.

Key takeaways

Passport projects often choose identifier, carrier and resolver as implementation details.
Those choices are the most permanent in the programme: they’re physically on every product.
Copyable carriers, model-level identifiers and vendor domains block authentication, traceability and resale.
Retrofitting means new carriers, parallel systems and costs in other teams’ budgets.
Decide identity foundations first, across teams. It takes weeks and doesn’t delay the passport.
Choose the carrier for every job it will face over the product’s life, not just the passport.

Decide the hard-to-change parts first

We’ll review your DPP plan’s identifier, carrier and domain choices before they’re on products in market.

FAQs

Why do Digital Product Passport projects fail?

Many are scoped as data-publishing exercises. The identifier, carrier and resolver are chosen for minimum compliance, which blocks later uses such as authentication, traceability and resale, and these elements are the hardest to change once products are in market.

What is product identity in the context of a DPP?

The unique identifier, data carrier and item record that the passport is served from. ESPR requires a unique identifier and data carrier; product identity designs them so other use cases can reuse them.

Can a DPP use a printed QR code?

Yes, QR codes are permitted carriers. The risk for high-value goods is that printed codes can be copied onto counterfeits, which then resolve to genuine passport data.

Should the DPP resolver use the brand’s own domain?

Yes. Identifiers printed or encoded on products point to a domain for their whole life. If the domain belongs to a vendor, changing vendor means permanent redirects or re-tagging.

Is NFC an accepted data carrier for the Digital Product Passport?

Yes. In 2026 the EU formally recognised NFC as a compliant DPP data carrier through Implementing Decision (EU) 2026/1736, referencing EN 18220. Many programmes combine a visible QR code for passport access with NFC for authentication on the same item.

When will brands need a Digital Product Passport?

It depends on the product group. The EU registry went live on 20 July 2026, textiles requirements are expected indicatively from 2027 with obligations around 18 months after each act, and battery passports apply from 18 February 2027.

Can a DPP project be fixed after products are in market?

Content and access rules can be changed in software. Carrier, identifier granularity and domain can’t be changed on products already shipped, so fixing them means new carriers on new production and running two systems in parallel until old products leave circulation.

Talk to the Selinko team

.css-1az3ztj{white-space:wrap;}.css-155tdfw{display:inline-block;overflow:hidden;margin-bottom:calc(var(--chakra-space-4) * -1);}.css-1kjo4sp{display:inline-block;will-change:transform;}Why DPP Projects Fail When Product Identity Is an Afterthought