The EU Digital Product Passport Registry Is Live. Build a Supplier Data Intake Workflow, Not Just a QR Code.

On 20 July 2026, the European Commission launched the EU Digital Product Passport Registry and a testing environment. The launch makes the Registry’s operational infrastructure available, including registration through a secure user interface or API, technical materials, guidance, webinars, and helpdesk support. The Commission’s announcement also describes a semantic repository, verification framework, and logging system.

The practical implication is important, but narrower than some early reactions suggest. The Registry being live does not mean every product needs a Digital Product Passport today. Requirements remain phased by applicable product category and legislation. The Commission frames the current testing period around its first stated implementation milestone: 18 February 2027 for certain types of large batteries.

For most product, sustainability, compliance, and supplier teams, the first useful move is not purchasing a QR-code carrier. It is building a controlled way to collect product information, request supporting evidence, assign gaps, review claims, and preserve a record of what was submitted and approved.

What changed with the EU Digital Product Passport Registry launch?

The Commission describes a Digital Product Passport as a digital container of product information intended to support supply-chain transparency, informed consumer choices, and compliance in the Single Market. The Registry is now the operational registration and testing layer around that ecosystem.

Its role is deliberately not the same as a central store for every product passport. The Registry supports registration of unique product identifiers and associated metadata, while the underlying product data is stored decentralised. Put plainly, the Registry can help identify and locate a passport record, but it is not a substitute for the systems, suppliers, and reviewers responsible for the underlying data.

The Commission identifies product groups under the Ecodesign for Sustainable Products Regulation, including textiles, steel and aluminium, tyres, furniture, ICT products, and energy-related products. It also identifies certain batteries, construction products, toys, detergents, and end-user surfactants under other Union legislation requiring DPP registration. That is broad system scope, not a statement that all listed products face the same immediate duty. Read the Commission’s launch notice for the stated scope and testing resources.

What the Registry launch does not mean

First, it does not create an immediate universal registration obligation. The Commission describes phased implementation, and specialist analysis similarly characterises obligations as sector-by-sector. EU Digital Product Passport’s analysis and DPP.cloud’s explanation both make the useful plain-language distinction: a live Registry does not itself make every product passport mandatory.

Second, it does not turn a QR code into product evidence. A data carrier may direct a user to a passport representation, but it cannot establish that a material composition, origin statement, certificate, repair instruction, or recycling claim is current and supportable.

Third, registration or technical validation should not be treated as proof of every underlying compliance claim. That caution comes from specialist analysis, not from a Commission guarantee. Product-specific legal applicability and claim review still need the appropriate internal and external expertise.

The working distinction is simple: the Registry is a registration layer. A passport host or representation is where information may be made available. Your upstream workflow is where suppliers provide evidence, owners resolve gaps, and reviewers decide what can become an approved product record.

The real bottleneck is supplier data collection

DPP work often appears to be a carrier, portal, or integration problem. In practice, the hard part usually arrives earlier. A product team needs a stable product identifier. A sourcing team needs the right supplier contact. A supplier needs clear requests and a way to state that evidence is unavailable. A reviewer needs provenance, dates, documents, and ownership before approving any customer-facing claim.

This is an operating model, not a universal legal DPP schema. It gives teams a durable starting point while product-specific rules continue to determine which fields, documents, and disclosures apply.

Use five evidence-governance categories

• Identity: internal SKU or model, product family, supplier name, supplier contact, manufacturing or sourcing context, and the system of record.
• Data category: the type of information being provided, such as composition, origin, certification, repair information, recycling information, or another product attribute.
• Evidence: source document, document date, issuer or source, supporting file, and the scope of the evidence.
• Exception: whether information is unavailable, why it is unavailable, who owns the follow-up, and the expected response date.
• Review state: submitted, incomplete, evidence requested, under review, approved for mapping, or not approved.

This structure prevents a common failure: a spreadsheet or shared inbox where a value is present but nobody can tell which product it applies to, who supplied it, what supports it, or whether anyone approved it.

A practical DPP supplier-data intake workflow

Build the workflow around accountable handoffs, not around a single enormous questionnaire. The supplier should only see relevant questions. The internal team should receive a structured submission that makes missing information visible.

1. Identify the supplier and product. Start with supplier organisation, contact name and email, product family, internal product identifier, and the intended pilot or business context. If a supplier receives a prefilled link, preserve that context rather than asking them to re-enter it.
2. Branch by product and data category. Ask which category the submission concerns, then show the relevant fields. A composition submission needs a different evidence request from a repair-information submission. Do not branch merely to make the form feel sophisticated. Branch when the next request genuinely depends on the answer.
3. Capture evidence provenance. For each supplied claim, collect the source or issuer, evidence date, file upload where appropriate, and a short note on what the evidence covers. This creates a reviewable record instead of a bare assertion.
4. Make unavailable data actionable. Every material gap needs an exception route. Ask why the information cannot be supplied, the accountable owner, and an expected date. Route that record to an internal owner rather than leaving it as an incomplete answer with no next step.
5. Separate submission, approval, and publication. Treat supplier input as evidence submitted for review. Maintain a separate internal approval field before any data is mapped into public product copy, a DPP representation, a PIM, ERP, PLM, or a future Registry workflow.

A useful rule is that a supplier may submit a claim, but only a defined reviewer can move it to an approved state. That separation protects both the supplier relationship and the customer-facing information layer.

Example five-page supplier evidence flow

Page 1: Supplier and product identification

Ask for supplier organisation, named contact, contact email, product family, product name, internal SKU or model, and whether the response covers one product or a group of related products. Where possible, prefill supplier and pilot context through a controlled link.

Page 2: Select the evidence category

Offer a focused selection: product identity, composition or material information, origin or sourcing information, certification or declaration, repair or maintenance information, recycling or end-of-life information, or another category. The choice determines the next page.

Page 3: Structured evidence collection

For each category, request the value or description, evidence source, source date, scope, and supporting file. Repeat the product name or SKU selected earlier so the respondent always knows what record they are supporting.

Page 4: Exceptions and ownership

If evidence is unavailable, ask for the reason, the person or team expected to provide it, and an expected date. Add a free-text note for constraints, but do not let free text replace the core structured fields.

Page 5: Submission boundary

End with a clear confirmation: the supplier has submitted information and supporting evidence for internal review; the submission is not an approved customer-facing claim and is not a completed Digital Product Passport. This is a small piece of copy with a large governance benefit.

How to build the intake layer in Stepform

Stepform is useful before the registry connection. It can act as the managed intake layer where suppliers submit structured information, attach evidence, flag missing data, and enter a review process. It does not host an EU Digital Product Passport, determine legal scope, register a passport with the Registry, or replace a DPP provider, PIM, ERP, PLM, or legal review.

Start with a multi-page supplier form. Use conditional logic to show category-specific questions, file uploads for declarations and supporting documents, and dynamic content to repeat the chosen product name or SKU. Hidden fields and URL parameters can preserve supplier, product-line, pilot, and campaign context.

Long evidence requests create real abandonment risk. Stepform creates partial submissions on first interaction and autosaves answers, which gives an operator a chance to see where supplier responses are stalling rather than assuming every uncompleted request disappeared. For general design guidance, see how to reduce form abandonment and recover partial leads.

On the operations side, map supplier contacts to structured Person records and supplier organisations to Company records where appropriate. Use custom fields for product ID, evidence category, document status, evidence date, reviewer decision, and next action. A pipeline can then make the workflow visible: Received, Incomplete, Evidence requested, Under review, Approved for mapping, and Not approved.

Assign a reviewer, add internal notes, and use automations or webhooks to notify an owner when a submission is incomplete or moves to review. Analytics can show which page or request category causes the most drop-off. AI-assisted drafting can help create an initial form and routing outline, but a human should review every field, branch, mapping, and approval rule before publishing. This is especially important when a form collects information that may later support regulated product claims.

For a broader view of why managed forms need structured records, ownership, automations, and pipeline states, see our guide to managed forms beyond flat spreadsheet responses.

Common mistakes to avoid

• Buying the carrier before mapping evidence ownership. A QR or NFC decision cannot resolve missing source documents or unclear approval rights. Define the data and review process first.
• Sending one giant questionnaire to every supplier. This increases irrelevant work and makes review harder. Branch by product, evidence category, and availability.
• Publishing supplier responses as approved claims. Supplier input needs a separate review state, reviewer, and decision record.
• Making “not available” a dead end. Missing data is still operational information. Capture the reason, accountable owner, and expected date.
• Letting identifiers drift between teams. Require a stable internal product identifier and record which product or group each evidence item covers.
• Treating the Registry launch as a universal deadline. The Commission’s rollout is phased. Use the live environment to prepare, but check the applicable product category and legislation before making compliance decisions.

Conclusion: fix the evidence workflow before a passport deadline forces it

The Registry launch is a practical opportunity to test assumptions about product identifiers, metadata, and future system connections. It is not a reason to rush every product into a generic QR-code project.

Choose one product line, one supplier group, and one evidence category. Build the intake, exception, review, and approval path. Once that path is reliable, expand it as the applicable product requirements become clear. You will have a more useful foundation for DPP work than a carrier with no controlled evidence behind it.