How to Choose a DPP Provider

Since 15 July 2026, six European standards for the digital product passport have been cited in the Official Journal of the European Union, which means that for the first time a textile brand can test a software vendor's claims instead of believing them. Commission Implementing Decision (EU) 2026/1736 of 14 July 2026 published the references of those harmonised standards in support of the Ecodesign for Sustainable Products Regulation (ESPR), and a passport built to them carries a presumption of conformity with the relevant ESPR requirements.

That changes the buying conversation completely. Until this summer, "ESPR-ready" was a slide in a sales deck. Now it is a question with a checkable answer, and the vendors who cannot answer it precisely are telling you something important.

This guide is about choosing the company that will hold your product data for the next decade. It does not repeat what a digital product passport is or what it costs, because we have covered both already. It covers the decision itself: what to ask, what to test before signing, what the contract has to say, and which answers should end the conversation.

What does a DPP software provider actually do for you?

A digital product passport provider does four things, and everything else on the pricing page is optional. It stores and serves the passport data, it mints and manages the identifiers, it produces and resolves the physical data carrier, and it controls which actor sees which field. If a vendor cannot describe its product in those four terms, it is selling something adjacent to a passport rather than a passport.

Storing and serving sounds trivial until you look at the availability requirement. A passport has to resolve when a consumer scans a label in a shop, when a recycler scans a garment in a sorting facility eight years later, and when a market surveillance authority checks a shipment at a border. That is a public endpoint with a very long life and no acceptable downtime story.

Identifier management is the part most brands underestimate. The passport identifier is not the same thing as your internal SKU, and it has to stay stable across seasons, suppliers and system migrations. Get this wrong and every future decision is constrained by it.

Carrier production and resolution is where the physical product meets the record. The vendor generates the code, and the resolver decides what happens when someone scans it. Whoever controls the resolver controls the relationship with everyone who ever scans your garments.

Access control is the least visible and most commercially sensitive of the four. ESPR gives different actors different views of the same passport, and your cost structure, supplier names and process details are not consumer-facing data. A provider without granular, per-role, per-field access rules is asking you to publish things you do not want published.

What a DPP provider does not do

A DPP provider does not collect your supplier data for you. Some platforms include questionnaire tooling, which helps, but the work of getting a Tier 3 dyehouse to report anything at all remains yours. Our practical guide to collecting supplier data sets out how that actually runs, and it is worth reading before you scope a platform, because the platform you need depends on the data you can realistically get.

A DPP provider also does not calculate your environmental footprint unless it explicitly sells that as a service. Many vendors will happily store a carbon figure you supply, which is not the same as producing one. If you need the number itself, that is a separate capability and a separate line in the budget, described on our environmental footprint page.

Which standards must a DPP provider conform to?

Eight European standards for the digital product passport were published by CEN and CENELEC on 27 May 2026, developed by the joint technical committee CEN-CLC/JTC 24 under standardisation request M/604. Six of the eight have since been cited in the Official Journal, which is what turns them into harmonised standards with legal effect.

The distinction in that last column matters more than it looks. Conformity with a cited standard gives a presumption of conformity with the ESPR requirements that the standard covers, so it shifts the burden of proof. The two standards not yet cited are still the right technical benchmark, but a vendor conforming to them cannot claim the same legal comfort, and an honest vendor will say so without being pushed.

Note also which subjects the two uncited standards cover. Access rights, security, business confidentiality, authentication and data integrity are precisely the areas where a brand carries the most commercial risk. The legal safety net is thinnest exactly where your exposure is highest, which is an argument for writing those requirements into the contract rather than relying on the regulation.

The question to actually ask

Ask for a written, dated statement of conformity for each of the eight standards, with three permitted answers per line, namely conforms, partially conforms, or on the roadmap with a date. Vendors who conform will produce this in a day. Vendors who do not will send you a case study instead, and that response is your answer.

Be sceptical of "fully ESPR compliant" as a phrase. The textile delegated act that will define the actual data requirements for garments does not exist yet, so nobody can be compliant with it. What can be demonstrated today is conformity with the horizontal standards above and readiness to add product-specific fields when the act lands. The regulatory context is set out on our legislation page, and the full picture of what a textile passport has to contain is in our complete ESPR compliance guide.

Should you build a DPP system yourself or buy one?

Buy, unless you already run product data infrastructure with a permanent engineering team, and even then buy the resolver. The reasoning is not about capability, it is about the shape of the obligation. A passport is a public service with a decade-long lifespan and a regulatory audience, which is a very different maintenance commitment from an internal tool.

Building the underlying data infrastructure takes 12 to 18 months, which is the figure we use in our DPP cost and ROI guide and which has not moved. Set that against a delegated act expected in 2027 and passports required from 2028, and the build option consumes most of the runway before you have written a single passport.

The hybrid column deserves more attention than it usually gets. You can buy the platform while retaining ownership of the identifier namespace and the resolver domain, so the code printed on a care label points at a domain you control, which then redirects to whichever platform currently serves the data. This costs very little to set up and it converts a painful migration into a DNS change. If you take one thing from this guide, take this one.

How does the data carrier decision constrain your provider choice?

The carrier decision comes first and it narrows the vendor field before you have shortlisted anyone, because not every platform supports every carrier. EN 18220:2026 recognises QR code, Data Matrix, NFC, HF RFID and RAIN RFID, and the practical trade-offs between them for garments are set out in our guide to DPP data carriers. The short version for a buyer is that most textile brands land on a QR code carrying a GS1 Digital Link URI, and the exceptions are driven by bulk reading or authentication needs.

What matters here is the coupling. If you intend to use RAIN RFID for warehouse reading, the passport platform has to handle an identifier that arrives from a reader rather than from a phone camera, and a surprising number of platforms are built around the phone-scanning case only. If you intend to run a single 2D code that also clears the checkout, the platform has to mint GS1 Digital Link URIs rather than opaque short links, and that is a yes or no capability rather than a roadmap item.

Three carrier questions belong in the vendor questionnaire rather than in a later technical workshop. Which symbologies and chip types can you generate and resolve. Can you issue GS1 Digital Link URIs against our own GS1 company prefix. And if we later add item-level serialisation to a product line that started at model level, what changes on your side and what does it cost.

The last of those is where unplanned money appears. Model-level identification prints one code for an entire style, which is cheap and simple, while item-level identification gives every garment its own identifier and unlocks resale, repair history and anti-counterfeiting. Textile brands very often start at model level and want item level within two years, so ask what that migration looks like before you sign rather than after.

What are the eight questions that separate a real provider from a demo?

Ask these in a live call, not by email, and write down who hesitates.

1. Which of the six cited standards do you conform to, and will you put that in writing with today's date? Covered above. The written, dated part is the test, not the claim.

2. Who owns the passport data, and what exactly happens on the first day after the contract ends? The answer you want describes a format, a delivery method and a deadline. The answer you do not want is "we would work with you on that".

3. What is your identifier strategy? EN 18219 defines identifiers for products, economic operators and facilities, and it recognises identification at model, batch and item level. A vendor should be able to state which levels it supports and what happens if you start at model level and later need item level, because in textiles that upgrade path is common and expensive if unplanned.

4. Can the carrier be a GS1 Digital Link URI that also scans at the till? A single 2D code that serves both retail checkout and the passport avoids printing two codes on one garment. The GS1 Digital Link standard is the mechanism, and a vendor that has not implemented it is committing you to a second code or a later reprint.

5. What happens to a passport if your company ceases to exist? EN 18221 exists because persistence is a regulatory requirement, not a nice-to-have. Acceptable answers involve escrow, a data trust, or a contractual commitment to hand over a running export before wind-down. "We are well funded" is not an answer to this question.

6. How do access rights work, per field and per actor role? Ask the vendor to show you the actual permission matrix for a real passport, including the recycler view and the authority view. If the demo only shows the consumer view, they have built a marketing page with extra steps.

7. What does the price do when my SKU count doubles, or when scans go up tenfold after a campaign? You are looking for a cost curve, not a headline price. Per-scan pricing without a ceiling turns a successful campaign into an unbudgeted invoice.

8. Show me a passport you serve in production today. Not a sandbox, not a mockup. A live URL, scanned in the call, for a product a real customer bought. You can see what a live passport looks like on our own DPP showcase.

How do you test data portability before you sign?

Run an export during the trial and try to load it somewhere else, because portability that has never been exercised is a promise rather than a property. This is the single most predictive test in the whole selection process, and almost nobody runs it.

EU law is unusually helpful here. The switching provisions of the Data Act have applied since 12 September 2025 and they cover cloud and software services supplied to customers in the EU. A customer can initiate a switch with a maximum of two months' notice, the provider must support a transition period of 30 days, extendable up to seven months where a faster switch is technically unfeasible, and switching charges are limited to the direct costs the provider actually incurs. From 12 January 2027 providers may generally not charge for switching at all, and that ban covers data egress fees. The mechanics are set out in this guide to the Data Act switching and porting rules.

So the legal floor is decent. The practical question is what lands in the export file.

A useful export contains the passport records in a structured, machine-readable format, the identifier assignments, the access rules, the carrier definitions, and the audit history of changes. CIRPASS-2, the EU-funded project running the large-scale DPP pilots including textiles, recommends JSON-LD as the default exchange format for passport data, so an export in JSON-LD with a documented schema is a strong signal. An export that is a CSV of consumer-visible fields is a strong signal in the other direction, because it means the identifiers and the permission model stay with the vendor and you are not actually portable at all.

Three clauses worth having in the contract regardless of what the Data Act already gives you. First, export on demand at any time, not only on termination, because an export you can run quarterly is an export you know works. Second, the format named explicitly, with schema documentation, rather than "a commonly used format". Third, a survival period during which the vendor keeps serving passports after termination while you migrate, since the passports stay legally required even while you switch suppliers.

How do you evaluate supplier onboarding, the part that actually fails?

Supplier onboarding is where DPP projects stall, so evaluate it as harshly as you evaluate the passport itself. The platform demo will always look good, because the vendor demonstrates it with clean data they prepared. The real test is what happens when a Tier 2 mill with no English-speaking sustainability contact receives an invitation email.

Only 13 percent of textile businesses report full visibility into their sourcing networks according to QIMA's Q2 2025 supply chain barometer, and roughly 54 percent can identify more than half of their supplier base. Those numbers describe the starting position of almost every brand reading this, and they mean the onboarding flow is not an edge case in the project, it is the project. The methods that work are covered in our supplier data guide, so here we only look at what to demand from a platform.

Ask to see the supplier side of the product, not the brand side. Specifically, ask how a supplier who has never heard of ESPR gets from an invitation email to submitted data, and count the steps. Then ask four things.

Whether the supplier portal works without the supplier creating an account, because account creation is where the drop-off happens. Which languages the supplier interface exists in, since a Turkish or Chinese mill will not fill in an English compliance form accurately even when someone there reads English. Whether a supplier can submit by spreadsheet upload as a fallback, because a meaningful share of your Tier 2 and Tier 3 will never use a portal. And whether data a supplier has already provided to one brand can be reused for another, which is the difference between onboarding a mill once and onboarding it for every customer separately.

Then run it for real in the pilot. Pick your most difficult supplier, not your best one, and send them a genuine invitation without warning them first. What comes back in two weeks tells you more about the platform than the entire RFP.

Which contract clauses are specific to a digital product passport?

Standard SaaS terms do not cover a passport, because a passport is a public record with a regulatory lifespan that outlives the contract. Six clauses are worth drafting deliberately, and none of them are unusual enough to be a negotiation problem with a serious vendor.

Post-termination service deserves a moment. The obligation to have a valid passport sits with you as the economic operator, and it does not pause while you migrate between vendors. If the old platform stops resolving on the last day of the contract and the new one goes live three weeks later, the garments in that gap are on the market without a working passport. A defined survival period, typically 90 to 180 days running in parallel with the new platform, removes that exposure for very little money.

On liability, be realistic about what you can get. Vendors will not accept unlimited exposure for regulatory penalties, and pushing for it wastes weeks. What is achievable is a commitment to serve the data you submitted without alteration, a defined incident response time for a passport serving wrong information, and a right to terminate without penalty if accuracy commitments are breached repeatedly. That combination is worth more in practice than a large liability cap you would never litigate.

What pricing models exist and which one fits your catalogue?

There are five common models, and the right one depends on how many product references you carry and how volatile your range is rather than on your revenue.

Ask specifically whether a colourway counts as a separate product reference, because in textiles that single definition can change the annual figure by an order of magnitude. Ask the same about sizes. A brand with 200 styles can easily have 3,000 billable references under an unfavourable definition.

Keep the subscription in proportion. Across the implementations we see, the software subscription is typically only 30 to 40 percent of the total first-year cost, with data work, integration and internal time making up the rest. A cheap subscription attached to an expensive integration is not a cheap platform. The full breakdown is in our cost and ROI guide, and our own approach is on the pricing page.

How should you run the selection process end to end?

Sixteen weeks from scoping to signature is realistic for a mid-size brand, and the calendar is set by the regulation rather than by your procurement cycle. The ESPR and Energy Labelling Working Plan, adopted in April 2025, puts textiles and apparel at the top of the priority list, the textile delegated act is expected during 2027, and the transition period after adoption is expected to run about 18 months, which lands the obligation in 2028.

The paid pilot is not optional. A pilot with 20 real products and one genuinely difficult supplier will teach you more than any reference call, and it is the only phase where you find out whether the vendor's onboarding survives contact with a mill that communicates by spreadsheet and telephone. Budget for it and insist that the pilot data migrates into production rather than being thrown away.

Involve legal at the RFP stage rather than at contract stage. The clauses that matter here, namely exit, persistence, access rights and liability for a wrong passport, are not standard SaaS boilerplate, and discovering that in week 15 costs you a month.

What are the red flags?

Six patterns that should at minimum slow you down.

"Fully ESPR compliant today." The textile delegated act does not exist. A vendor claiming compliance with unpublished requirements is either careless with language or hoping you do not know the timeline.

No named standard, only a logo wall. Conformity is per standard and it is a factual claim. A page of client logos answers a different question.

A passport URL on the vendor's domain with no exit path. If the code printed on 40,000 care labels resolves to a domain the vendor owns, your switching cost is a reprint of the entire season.

Per-scan pricing with no ceiling. Ask what a viral product does to the invoice, then ask for the cap in writing.

No answer on what happens if they fail. Persistence is a regulatory requirement with a decade-scale horizon, and a startup answering it with a funding announcement has not understood the question.

A demo that only shows the consumer view. The consumer view is the easy part. Ask for the recycler view, the authority view and the permission matrix behind them.

There is a seventh that is more a matter of judgement than a red flag. If a vendor's answer to every architectural question is a distributed ledger, ask which specific requirement in ESPR or in the harmonised standards that choice satisfies. Sometimes there is a good answer, particularly around authentication and integrity. Often it is a technology looking for a regulation.

How does the choice differ for an SME versus a large brand?

The evaluation criteria are identical, but the weighting is not. Almost the entire EU textile sector is small, since 99.5 percent of the roughly 143,000 textile companies operating in the EU are SMEs and about 88.8 percent are micro-companies with fewer than ten employees. For a company of that size, onboarding speed and the absence of an integration project matter more than configurability, and the build option is not a real option.

A smaller brand should weight three things heavily. Time to first live passport, because there is no team to absorb a slipped timeline. A flat, predictable fee, because a variable bill is harder to defend to a board of two people. And a genuinely self-service supplier onboarding flow, because nobody internally has time to chase a mill through a complex portal.

A larger brand inverts two of those. Integration with the existing PLM or ERP becomes the dominant criterion, because passport data that has to be maintained twice will eventually be wrong in one of the two places, and per-field access control matters more because there are more sensitive commercial relationships to protect. The practical route for smaller companies is set out in our lean compliance guide for SMEs.

One structural point applies to both. Whatever the size, the passport requirement bites at product level, and the textile scope is expected to capture products containing at least 80 percent textile fibres, which covers essentially every garment either type of company ships.

How large is the provider market and does that matter?

The market is small, young and growing very fast, which has a direct consequence for how you write the contract. Independent market research puts the digital product passport software market at roughly USD 186 million in 2024, growing towards an estimated USD 1.78 billion by 2030, which implies a compound annual growth rate in the mid-forties. Treat those figures as directional, since they come from commercial market research rather than from an official source.

The relevant conclusion is not the size but the shape. A market growing at that rate with dozens of vendors and no dominant player will consolidate, and consolidation means some of today's providers will be acquired, repositioned or wound down inside the ten-year life of the passports you create this year. That is not a reason to wait, because waiting does not make the deadline move. It is a reason to make persistence, export and identifier ownership contractual rather than assumed.

FAQ

Can I switch DPP providers later without reprinting labels? Only if you own the identifier and the resolver domain. If the code on the label points to a domain you control, switching providers is a configuration change. If it points to the vendor's domain, switching means reprinting every label in circulation, which for a mid-size brand is a five-figure cost before anyone touches the data.

What does conformity with EN 18219 actually prove? It proves the vendor assigns unique identifiers according to the European standard for products, economic operators and facilities, at the right granularity level. It does not prove the passport contains the right textile data fields, because those will come from the delegated act, and it does not prove anything about security or access rights, which sit in separate standards that are not yet cited in the Official Journal.

Can I use my existing PLM or ERP vendor instead of a specialist DPP provider? Sometimes, and it is worth asking, because the data is already there. The test is whether they conform to the harmonised standards, whether they can serve a public passport endpoint with a ten-year persistence commitment, and whether they can resolve a data carrier. Most PLM systems today do the first part of that and none of the rest, so the common outcome is that the PLM stays the source of truth and a specialist serves the passport.

Who is liable if my provider serves an incorrect passport? You are, as the economic operator placing the product on the market. That responsibility cannot be contracted away to a supplier, which is why the contract should give you a right of recourse, an accuracy commitment and an incident response time. Ask what happens at 2am on a Sunday when a passport shows the wrong fibre composition.

Does the DPP provider need to be established in the EU? The regulation does not require it, but data location and applicable law are worth deciding deliberately rather than by default. An EU-established provider simplifies the switching rights under the Data Act and the practical enforcement of your contract, while a non-EU provider is workable with the right clauses on data location, sub-processors and governing law.

What happens to my passports if my provider goes out of business? Whatever your contract says, which is usually nothing useful. Persistence obligations sit with you rather than with the vendor, so ask for a data escrow arrangement, a documented wind-down process with a defined handover period, and the right to run an export at any time. A quarterly export you have actually tested is worth more than any of those clauses on their own.

How many vendors should I put on the shortlist? Three, after a longlist of eight to twelve filtered by the written standards questionnaire. Two gives you no negotiating position and five turns the pilot phase into a full-time job for someone you have not hired.

The decision underneath the decision

Choosing a DPP provider looks like a software purchase and behaves like an infrastructure commitment. The subscription is renegotiable every year, but the identifier scheme, the resolver domain and the carrier printed on a care label are decisions you make once and live with for as long as those garments exist.

That is why the three questions worth obsessing over are ownership of the identifier, the tested export, and the persistence commitment. Standards conformance is table stakes and pricing is negotiable. Those three determine whether your 2028 decision is still yours in 2032.

If you want a second pair of eyes on a shortlist, or a look at how the identifier and resolver question plays out for your specific catalogue, talk to us. We will tell you where a platform genuinely fits and where you are better off owning the piece yourself.

Sources

• Harmonised standards for the digital product passport, European Commission
• CEN and CENELEC on the DPP standards package
• Ecodesign for Sustainable Products Regulation, legal text
• Implementing the ESPR, European Commission
• Switching and porting rules under the EU Data Act
• CIRPASS-2 project results
• GS1 Digital Link standard