Before you sign a contract with a DPP provider, there are eight questions you should ask. Most brands don't ask them until it's too late. How to Avoid DPP Vendor Lock-In: 8 Questions Every Brand Must Ask.
The sales call for a Digital Product Passport platform tends to follow a familiar script. Someone shows you a dashboard. There's a QR code. Data appears on a phone screen. It looks clean and it looks easy, and somewhere toward the end, a compliance manager asks about ESPR timelines and a founder asks about price.
Almost nobody asks: what happens to my passport if you shut down?
It's not an unfair question. The DPP market is young, the regulation is still being implemented, and the companies building compliance infrastructure today range from well-capitalised platforms to two-person startups running on grant funding. Vendor risk is real. And unlike a SaaS subscription for project management, a Digital Product Passport is attached to a physical product that may be in circulation for ten, fifteen, twenty years.
The good news: the EU anticipated this problem. Regulation (EU) 2024/1781 – the Ecodesign for Sustainable Products Regulation, or ESPR – was written with data continuity explicitly in mind. The architecture it mandates is designed to prevent lock-in. But the regulation's protections only work if the platform you choose actually implements them.
Here is what to look for.
Every Digital Product Passport is anchored to a unique product identifier – a code that connects the physical product to its digital record. Where that identifier comes from matters more than most brands realise.
ESPR, and the JRC technical methodology behind it, defines three layers of identification that every DPP must carry: a Unique Product Identifier (UPI) that links the physical item to its digital record; a Unique Operator Identifier (UOI) that identifies the economic operator responsible for placing the product on the EU market; and a Unique Facility Identifier (UFI) that traces the physical locations involved in production or end-of-life processing. These are not internal SKUs or proprietary codes – the regulation requires identifiers that are discoverable, resolvable and verifiable across the global supply chain. The standards governing their exact format are currently being developed by the European standardisation committee CEN/CENELEC Joint Technical Committee 24.
Within that framework, GS1 identifiers – GTINs for products, GLNs for operators and facilities – are the most widely deployed implementation globally. GTIN is recognised across 115 countries, built into customs, retail and logistics infrastructure, and already required by major retailers and market surveillance bodies. GS1 Digital Link, the open standard that turns a QR code into a structured, resolvable URL, is the resolution mechanism Fluxy.One uses for exactly this reason: it works anywhere, with any compliant resolver, and it is not tied to any single platform.
The GTIN belongs to the brand, not to the platform. A company registers directly with GS1 – through GS1 Belgilux, GS1 Germany, GS1 France, or whichever national member organisation covers their market. If the brand changes DPP providers, the identifier travels with them. The QR code on the product does not change.
The first question to ask any DPP provider: which identifier standard do you implement, and can it be resolved by any compliant system independently of your platform?
Under Article 9 of ESPR, the economic operator – the manufacturer or importer who places the product on the EU market – is legally responsible for the accuracy and completeness of the DPP. That responsibility cannot be delegated to a software platform. It stays with the brand.
A well-built DPP platform reflects this in its technical architecture. The brand controls write access to its own passport records. Platform staff should have no ability to modify client data – not as a policy commitment, but as a technical constraint enforced through role-based access controls, with all access logged immutably.
Revocation deserves a separate note. Revoking a DPP does not mean deleting it. Under the ESPR framework, revocation writes an immutable event to the compliance record – with a timestamp, a stated reason, and the identity of whoever acted. The history of the passport remains intact. This matters for market surveillance authorities, who need to be able to reconstruct what happened and when.
Ask any provider: is write access restriction a policy, or is it enforced at the architecture level? The answer tells you a lot.
A backup copy is not the same as a working record. This distinction matters more than most DPP discussions acknowledge.
Retention means your data is stored somewhere safe. Continuity means your passport remains a live, resolvable, updatable record – one that can receive new lifecycle events, actor attributions and ownership transfers even after the original platform relationship ends. ESPR requires the second. A stale export or a broken resolver fails the point of the passport, regardless of what's in the backup.
What makes continuity possible across providers is not the backup mechanism alone. It is the combination of three things: an identifier that can be repointed to any compliant resolver; an event log in an open format that any certified operator can ingest and continue appending to; and the EU central registry, mandated under Article 13 of ESPR for July 2026, which is designed to hold the canonical reference record and maintain resolution independently of any single platform.
The exact rights and obligations – who can append to a record, under what authentication, across which platform boundaries – will be defined in the delegated acts per product category. That is not a gap in the current framework; it is how the regulation was designed to work.
Most DPP providers host the data themselves. That's fine – it's operationally sensible, and the regulation does not require brands to self-host. What the regulation does require is a safety net.
Article 11 of ESPR mandates that an up-to-date backup copy of every DPP be held by an independent third-party – separate from the primary platform. This requirement was written specifically to address insolvency. If a DPP provider closes, the backup operator holds the data and can transfer it to a new platform. The regulation was designed so that your passport survives your vendor.
The certification scheme for these backup operators is currently being finalised by the European Commission, so the precise definition of "independent" and "certified" is still in development. What already exists in the regulation is the obligation itself: the backup must happen, and it must be with a separate party.
There is a second layer of protection that is often overlooked. Under Article 13 of ESPR, the Commission is required to establish a central digital registry by 19 July 2026. This registry will hold the canonical reference record of every DPP – not a copy, but a live, resolvable record that persists independently of any single platform. Updates, actor attribution, lifecycle events: the architecture assumes these continue through the registry even if the original platform relationship ends.
On resolution specifically: identifiers built on open standards can be repointed to any compliant resolver. Migration from one provider's resolver to another is a technical operation, not a data loss event.
Scanning a QR code on a product is a single gesture. What appears on the screen depends entirely on who is doing the scanning.
A consumer buying a jacket sees material composition, care instructions, and sustainability information. A certified repairer sees technical diagrams and spare part references. A customs authority sees compliance certificates and conformity declarations. A recycler sees chemical content data and disassembly instructions. A market surveillance authority sees everything – including the full audit trail of every change ever made to the passport.
Same QR code. Four completely different views.
This is not a design choice – it is a regulatory requirement. Article 10 of ESPR mandates tiered access: different actors see different layers of the passport based on their role and authorisation level. The delegated acts, published product category by category, will define exactly which actors can view, enter, amend or update which data fields.
One boundary is already fixed in the regulation regardless of delegated acts: personal customer data cannot be stored in the DPP system without explicit consent. The passport is a product record. It is not a customer database, and it cannot become one.
Until the delegated acts are in place for a given product category, the access tiers are configured jointly by the platform and the brand. Any honest provider will tell you that this part of the framework is still being built out – and will show you exactly how their current access architecture will migrate to the delegated act requirements when they arrive.
The question worth asking: can you see, right now, who accessed your passport data and when? An immutable access log – recording every view, by which actor type, at what time – is not an optional feature. It is how you demonstrate to a regulator that your data governance worked.
Brands with proprietary formulations, material sourcing arrangements, or manufacturing processes often worry that a DPP will require them to publish that information publicly. This concern is understandable and, in most cases, misplaced.
The ESPR framework distinguishes between data that must be publicly accessible and data that is restricted to authorised actors – regulators, auditors, market surveillance authorities – under confidentiality conditions. A cosmetics brand does not need to publish its formula. A textile manufacturer does not need to disclose its supplier list to consumers. The regulation requires transparency about sustainability attributes, not the disclosure of trade secrets.
The exact boundaries will be set product by product in the delegated acts. For categories where delegated acts are not yet in place, the access tiers remain configurable. A good DPP platform allows the brand to define what is public, what is restricted to verified professional actors, and what is available only to regulatory authorities.
Portability is not just about having an export button. The question is whether the exported data can be read by another system without the original platform in the room.
The answer depends on the format. JSON-LD structured according to the CIRPASS-2 vocabulary – the EU's own open interoperability framework, developed in collaboration with GS1 – is the format that any certified DPP operator can ingest. If your passport data is stored in a proprietary schema, an export file may technically exist but be practically unreadable without custom integration work.
Beyond the data format, there is the question of validation rules. The SHACL shapes – the formal definitions of what a compliant DPP must contain for a given product category – are published openly by CIRPASS-2 and maintained by the EU standardisation process. A DPP platform that builds on these open shapes does not write the rules; it implements them. When the shapes are updated to reflect new delegated acts, the validation logic updates. The data does not need to move.
Eight questions worth putting to any DPP provider before committing:
Which identifier standard do you implement, and can it be resolved by any compliant system independently of your platform?
Who technically owns write access to passport records – and is that enforced architecturally or by policy?
Where is the mandatory backup copy held, and by which independent operator?
In what format is data exported, and can you demonstrate that another certified platform can ingest it without custom work?
What validation schema does the platform implement, and how are those schemas updated when new delegated acts are published?
Can you show the append-only event log for a sample passport, and confirm it cannot be retroactively modified?
Can you show the immutable access log – every view, by which actor type, at what time?
What is your migration process if we decide to move? How long does it take, and at what cost? A provider who has thought seriously about interoperability will have a specific answer, even before the delegated acts arrive.
A provider with well-designed infrastructure will have direct answers to all eight. Vague answers on any of them are worth probing.
The EU did not design the DPP framework with vendor lock-in in mind. It designed it with continuity, interoperability and accountability as explicit goals. The open identifier standards, the mandatory third-party backup, the central registry, the open validation shapes – these are architectural choices embedded in the regulation, not optional features.
The brands that will navigate the DPP transition most smoothly are those that treat vendor selection as an infrastructure decision, not a software purchase. The questions above are not hostile. They are the right questions to ask of any serious platform, and a serious platform will welcome them.
If you want to understand how Fluxy.One addresses each of them in practice, the conversation starts here.
Fluxy.One — the transparency infrastructure for the global economy.
Book Free Demo
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
