How to Choose a Digital Product Passport Platform: A Buyer's Guide for 2026

Until July 2026, evaluating a Digital Product Passport platform was an exercise in comparing vendor promises against a regulatory target that had no agreed technical shape. That changed in a single week. On 15 July 2026, Commission Implementing Decision (EU) 2026/1736 published the references of six harmonised standards - EN 18216, EN 18219, EN 18220, EN 18221, EN 18222, and EN 18223 - in the Official Journal, giving DPP tooling a formal conformity target for the first time. Five days later, the EU DPP Registry went live on 20 July 2026, and Commission Implementing Regulation (EU) 2026/1778, adopted 16 July 2026, entered into force on 6 August 2026, setting out the operating rules every platform must now follow.

The practical consequence: "conformity with EN 18216-18223" is no longer a nice-to-have. It is a contractual question. And "registry-connected" is no longer a roadmap item. It is a baseline requirement.

This post is a procurement guide. It assumes you already understand what a DPP is (see our explainer on what goes in a Digital Product Passport) and what the standards say (see our deep-dive on the EN 1821x series). The question here is how to choose the software that will actually deliver one.

---

What a DPP Platform Actually Has to Do

Before you can evaluate vendors, you need a clear picture of the functional scope. A DPP is not a product page. It is a regulated data infrastructure object with a lifecycle that can span a decade or more. Six functional blocks define the work:

Each block maps to at least one of the six harmonised standards. A platform that conforms to those standards is presumed to meet the corresponding DPP technical, design, and operational requirements under Article 41(2) of the ESPR - which means conformity with the named standards is the fastest path to legal defensibility, not just a technical preference.

A note on the registry architecture: the EU DPP Registry is a directory, not a data host - it stores the unique product identifier and the URL of each passport, and returns the location of a product's passport data when queried via a GS1 Digital Link identifier. Your product data stays with you or your service provider. What the registry requires is that the platform can submit to it, and that the passport URL it registers actually resolves. Platforms that generate standalone passport pages without registry connectivity will need rework before any mandatory deadline hits.

---

Build vs. Buy: An Honest Decision Framework

The build-vs-buy question has a real answer for most organisations, but it requires honest accounting.

The cost and time reality. Market estimates - which vary significantly by product complexity, SKU count, and existing PLM/ERP maturity - put an in-house DPP build at roughly EUR 50,000-90,000 in year one and 4-8 months of elapsed time, versus 2-3 weeks to deploy a bought solution. Treat those figures as directional, not precise: a manufacturer with 50 SKUs and a mature PIM will have a very different experience from one with 5,000 serialised products and no existing data infrastructure.

What the estimates do not capture is the ongoing cost. Registry connection, regulatory tracking as delegated acts arrive through 2030, hosting with public availability guarantees, access management, versioning, and audit trails are all operational obligations that compound over time. A SaaS platform spreads that maintenance burden across its entire customer base. An in-house build owns it entirely.

The three conditions under which building is genuinely defensible. All three should be true simultaneously:

1. Deep existing PLM/PIM investment. You have a permanent in-house platform team, and product data infrastructure is already their core job. The DPP is an extension of existing work, not a new discipline.
2. Unusual data-sovereignty constraints. Your product data cannot leave your own infrastructure under any circumstances - a genuine legal or contractual constraint, not a preference.
3. Product architecture no vendor models well. Your product structure (e.g., highly serialised, multi-component assemblies with complex sub-passport relationships) is genuinely outside what any available platform handles without significant customisation.

If all three are true, building is defensible. If only one or two are true, the economics almost always favour buying - and the regulatory ground is still moving. The two security standards, EN 18239 and EN 18246, closed their formal vote on 16 July 2026 and are expected to be published around September 2026, with OJ citation to follow. Anyone building in-house is building against a specification that is not yet fully closed.

---

Nine Questions to Ask Every Vendor

This is the centrepiece of any DPP platform evaluation. Use these questions in every vendor conversation. Vague answers are disqualifying.

---

Red Flags to Watch For

Not all red flags are obvious. Some are buried in demo scripts and sales decks.

Standalone passport pages with no registry connectivity. A platform that generates a public product page and calls it a DPP is missing the infrastructure layer entirely. Under Implementing Regulation (EU) 2026/1778, economic operators must register each passport in the Registry before placing the product on the market. A page with no registry submission path is not a compliant DPP solution - it is a product landing page.

A vendor who cannot name the EN standards. The six harmonised standards have been public since 27 May 2026 and cited in the Official Journal since 15 July 2026. Any vendor building DPP tooling should be able to tell you, without hesitation, which standards they conform to and how. Vagueness here is a signal that conformity has not been engineered in - it has been assumed.

"DPP-ready" without a definition. Until May 2026, "DPP-ready" was a stretchable marketing term with no verifiable technical referent. It is no longer acceptable as an answer. Ask what it means, specifically, in terms of the named standards and the live registry.

No data-exit clause. If a vendor cannot tell you how you get your data out - in a machine-readable format, with continued URL resolution - walk away. The ESPR requires passport data to remain accessible for the full product lifecycle. That obligation does not end when your contract does.

Carrier generation that ignores EN 18220. EN 18220 specifies requirements for data carriers including QR codes, DataMatrix, and RFID - covering symbology, encoding, print quality, and durability. A platform that generates a generic QR code without reference to EN 18220's requirements for machine readability, placement, and quality checking may produce carriers that fail in the field.

API architecture that is not EN 18222-aligned. EN 18222 covers APIs for DPP lifecycle management and searchability - it is what the EU Central DPP Registry expects a passport platform to speak when registering a product. A platform not built to EN 18222 will need custom integration work that a conformant one skips.

---

If You Do Nothing Else This Quarter

The regulatory calendar is not waiting. Here is the minimum viable action list:

• Map your product scope against the battery passport deadline. Battery passport registration becomes mandatory from 18 February 2027 under Regulation (EU) 2023/1542 for EV batteries, LMT batteries, and industrial batteries above 2 kWh. If you are in scope, roughly six months is not a long runway for platform selection, integration, data collection, and registry onboarding.
• Run the nine questions above against every vendor on your shortlist. Document the answers. Gaps in answers now are gaps in compliance later.
• Confirm your identifier strategy. If you are already using GS1 GTINs, a platform with native GS1 Digital Link support will have a materially shorter path to EN 18219 and EN 18220 conformity. If you are not, decide now - the identifier scheme you choose will be embedded in every carrier you print.
• Read the Registry operating rules. Commission Implementing Regulation (EU) 2026/1778 has been in force since 6 August 2026. It covers eIDAS identity verification for economic operators, the structure and completeness checks the Registry runs on submission, and the split of responsibilities between the Commission and Member States. Your platform vendor needs to have read it too.
• Check the EU DPP Registry post and the battery passport deadline post for the infrastructure and sector-specific detail that sits behind the procurement questions above.

---

The shift that happened in July 2026 is not incremental. For the first time, DPP tooling can be evaluated against a published conformity target and a live registry to integrate with. That means vendor selection can finally be done on evidence - conformity with named standards, live registry connectivity, documented data-exit terms - rather than on promises about a future that has now arrived.

The platforms that were genuinely building to the standards are ready to demonstrate it. The ones that were not are now visible.