Choosing a Digital Product Passport provider means picking data infrastructure that must last for years. The wrong choice locks product data into formats that don’t travel or adapt to new rules. The right questions expose those gaps before signing.
Start with regulatory adaptability, not price
Buying conversations often start with cost per passport and setup speed. Those numbers mean little if the platform can’t track developing rules. The Ecodesign for Sustainable Products Regulation, or ESPR, sets general passport requirements and duties. Product-specific delegated acts will determine detailed fields, timelines and enforcement.
That distinction matters. General ESPR claims give procurement teams little to plan against. Innovation and compliance teams need to understand how the system accommodates new acts for textiles, electronics or furniture without rebuilding.
The EU Battery Regulation offers a preview. Passports become mandatory for electric vehicle batteries, light means of transport batteries and industrial batteries above 2 kWh from February 18, 2027. For other groups, applicable ESPR delegated acts determine obligations, scope and compliance dates.
Ask this:
- How do you monitor ESPR delegated acts and update schemas?
- Can you show data model change logs for new rules?
- Who decides which fields are mandatory or optional?
A credible answer is specific. The provider describes its regulatory watch process and owner. It shows versioned templates and explains customer migrations. Limits matter too. Software alone cannot make a product compliant. Applicable rules determine the responsible economic operator; the platform supports that responsibility.
Price still counts, but adaptability comes first. A cheap system can become expensive when rules shift.
Ask if data models were built for passports
Many SaaS products claim passport coverage. Some began as passport platforms. Others added compliance modules to quality or sustainability tools. Their practical differences emerge in daily use.
Whatever its origins, a suitable platform treats each passport as a structured record tied to the required model, batch or item. It supports product-group information, controlled updates and permissions. A PDF alone doesn’t demonstrate field-level search, exchange or sharing.
Request a live walkthrough using real product data. Don’t settle for lorem ipsum mockups.
Ask this:
- Is the passport structured data or an attached document?
- How do you handle sensitive component-level bill of materials data?
- How do you calculate repairability and recyclability indices where future acts require them?
A useful demonstration filters a test passport by substance, component and supplier. Permissions let a recycler access appropriate material data without cost or margin fields. Circularity scores have explanations, sources and update dates rather than unexplained numbers.
Short demos can conceal gaps. A working demonstration reveals more than slides.
Ask the team to create a variant, change a material and publish while preserving history. Workarounds or exports warrant attention.
Press on identifiers, carriers and standards
Every passport needs a reliable physical-to-digital link. It has two parts. A unique product identifier establishes identity in systems. A data carrier provides access to the record.
Carriers include QR codes, RFID tags, NFC chips and other machine-readable options. No option suits every product. Applicable rules guide selection. Printed codes and embedded tags differ in production needs and durability; both need testing for intended environments. Providers should explain these tradeoffs and readability after repairs or relabeling.
Standards determine whether identifiers work outside the provider’s system. GS1 identifiers and EPCIS event data are widely used for traceability because partners can read and exchange them. Registry-ready formats also matter where authorities need central registry checks.
Manufacturers mapping identifiers, hosting and supplier inputs can read a detailed digital product passport implementation guide before shortlisting. Arriving with a clear connection plan helps.
Ask this:
- How do you generate unique product identifiers and maintain stability across variants?
- Are identifiers GS1-compatible and ready for required registry lookups?
- Which carriers do you support, including reprints and replacements?
A strong answer covers the code’s lifespan. The provider explains model, batch and individual-item identifiers, including how serial numbers distinguish individual units. It demonstrates QR code replacement without losing history. Warehouse scanning with low connectivity also needs attention, not just shoppers’ newer phones.
Clarify where data lives and who controls it
Storage architecture is easy to overlook and difficult to change. EU guidance points toward decentralized storage, with passport data across networks rather than dependent on one private silo. Some providers follow that approach. Others use centralized databases.
Buyers need to assess the architecture against the applicable requirements, not rely on a provider’s label for it. Ask how the system supports interoperability and avoids dependence on a single resolver, as well as where data is stored, how it is backed up and what happens during outages. Continuity commitments belong in the contract, not just the pitch.
Data sovereignty raises ownership and access questions. Who owns passport data after termination? Who can read it during the contract? Brands often assume ownership. Some terms permit broad retention or reuse of aggregated data.
Ask this:
- Is storage decentralized or centralized, and where are servers located?
- What contractual uptime and backup commitments apply?
- How does termination affect data return and access?
Look for standard-format exports and open APIs. A credible provider names formats, provides documentation and commits to a handover period. Vague exit cooperation isn’t enough.
Supplier-submitted data also needs clear contractual treatment. Ownership and retention rules should cover component suppliers’ test results after exit.
Test integration and supplier onboarding in practice
Manual uploads can support a 50-product pilot. They become impractical across thousands of SKUs and frequent engineering changes. Passport inputs already sit in ERP, PLM, quality and manufacturing systems. Connections should reduce constant retyping.
Integration is often oversold. Ask about live capabilities rather than roadmaps. A tested ERP connector differs substantially from one promised after signing.
Ask this:
- Which ERP and PLM connectors are live, and can you demonstrate synchronization?
- How are internal part numbers mapped without duplicates?
- How do material or design changes reach published passports?
A useful demo maps a sample BOM, flags mismatches and demonstrates missing-field error handling. Engineering updates reach draft passports for review rather than overwriting live records. Documented change management assigns publishing approval.
Supplier onboarding deserves equal attention. Brands rarely hold every required input. Component suppliers hold substance declarations, test reports and origin details. Suppliers should be able to submit and confirm data without exposing the entire BOM to everyone.
Trust matters here. All-or-nothing access discourages suppliers from sharing sensitive formulations.
Ask how permissions restrict suppliers to their own submissions. Ask whether participation requires full licenses and what support covers other languages and time zones. Providers experienced with reluctant suppliers should offer clear answers and examples.
Check lifecycle updates and access control
Passports can change after publication. Products undergo repairs, part replacements and resale. Depending on the category’s delegated act, some events may require a verifiable trace. Even without a requirement, histories can help buyers and recyclers understand changes.
Ask about post-publication updates. Can repair shops record battery replacements? Can refurbishers add test results? Can brands approve entries before publication? Audit trails should identify changes and contributors while retaining earlier versions.
Different readers need different views. Shoppers may need care, safety and recycling basics. Authorities may have rights to detailed compliance fields. Recyclers may need disassembly and substance data under applicable access rules. Suppliers may need only their submissions.
These roles need a working demonstration, not just a data-sheet description.
Ask this:
- How do you record repairs and resale while retaining prior versions?
- Can permissions separate roles and fields, including partial BOM views?
- How do authorities and recyclers receive access where rules grant it?
A solid demo shows one passport through three logins with different visible fields. The provider explains product-group permissions and change logging. Identical full records for every user suggest missing partial-access design.
Language and usability matter too. Single-language passports or slow loading on older phones limit usefulness for shoppers and shop-floor staff. Request a mid-range-device demonstration with a weak signal.
Pin down pricing, scale and exit terms
Passport platforms use different pricing models. Some charge per passport. Others bill by data volume or scans. User- or site-based pricing also exists. Each behaves differently as pilots expand and additional product-specific obligations apply.
Third-year costs deserve attention alongside first-year fees, especially with ten times more products and growing data. Request written calculations.
Ask this:
- Is pricing per product, data volume, scan or user, and what triggers higher tiers?
- How does a tenfold passport increase affect fees and performance?
- Are carrier printing, tag provisioning and registry submissions included or separate?
Demand full proposal pricing, not just platform fees. Implementation support, connectors, supplier training and extra storage often fall outside base quotes. Uptime and support-response commitments should include remedies for missed targets.
Exit terms address lock-in. Open APIs and standard formats are essential for years of product history. Request usable exports of passport records and audit trails, not screenshots or locked files. Discuss handover timelines and continued identifier and link resolution or clean redirection during transition.
Portability deserves testing before exit. Request a sample export during evaluation and open it without provider assistance. If the data can’t be read and reused elsewhere, keep shopping.
Passport procurement calls for the perspective of a long-term data owner. Providers worth considering answer difficult questions through demonstrations, contract language and clear limits. Promises need written commitments and working evidence.
