Digital Product Passport
FAQ for buyers

Choose the operating model and required service scope before deciding where the software sits. In KPMG's survey of more than 70 European organisations, 61% were undecided, 34% planned to use an external vendor and 5% planned an in-house build. Fieldwork ran from September to December 2025; the report says the sample is not representative.

• Buy a platform or managed service when its demonstrated functions and contracted support address your gaps. Confirm whether supplier outreach, evidence review and exception resolution are included.
• Extend existing systems when they can maintain the required data and your provider can demonstrate the publishing, access, integration and continuity functions you need. A familiar system still needs testing against the passport requirements.
• Build when you have a justified business need, engineering capacity and a funded plan for standards changes, security, support and maintenance over the required service period.
• Combine services where responsibilities and interfaces are clear, for example keeping product records in an existing system while using a separate publishing service.

Our view: compare these options on total work, evidence quality, integration, maintenance and exit. Scattered data is a problem to solve under any option; buying software alone does not settle who will collect or validate it. Secure the rights and technical means to retain your identifiers, domain control and usable data when changing arrangements.

The contract should state who performs each task. A supplier portal, a data-validation feature and a managed data-collection service are different deliverables. Do not infer the amount of operational work included from a demonstration of the software.

The CIRPASS study on SME costs and benefits identified data collection, skills and outsourced data generation as distinct considerations. Its evidence came from eight interviews, four with SMEs and four with providers, in 2023. It was a qualitative study, not a benchmark for which party normally performs the work or which cost is largest.

Our view: assign supplier contact, reminders, translation, document intake, evidence review, exception resolution and publication approval separately. Define the acceptance standard, turnaround expectations, included quantities and escalation route for each task. Make clear whether checking a document means checking its presence, authenticity, coverage or the underlying product claim.

Include your own estimated staff time in the comparison. A lower subscription can be a reasonable choice when you have the required capacity; a managed service needs an equally clear statement of what it delivers.

Give every shortlisted provider the same brief using a small set of your real products, including a difficult case. A sample-data demonstration can explain the product; testing your own scenario shows how it handles the work you need.

1. A supplier submits data and evidence, a missing or conflicting value is detected, and the authorized person resolves it under the agreed publication rules.
2. A consumer and relevant professional users see the information they are entitled to access. An unauthorized account is denied access, including through the API.
3. An approved change reaches the published passport with provenance and history, while an older batch retains the facts that apply to it.
4. The provider performs the identity or registration steps in scope using the applicable test service. Record the environment, response and limitations of the test.
5. The agreed data, evidence and history are exported and loaded into a compatible second system. A printed code still resolves to the intended product record after the move.
6. A failed update or revoked access is handled, with a visible exception, an accountable response and an audit trail.

Agree the pass criteria before the session. Record the product and software versions, evidence shown, result and unresolved limitations. A supplier statement, an observed demonstration and a live deployment establish different things; use each only for the scope it supports. A test-environment success is not a blanket product-compliance approval.

Compare the function you need, because providers can cover different parts of the work.

• Passport platforms: create, host, manage access to and publish passport records.
• Existing business-system vendors: add passport functions to product lifecycle management, product information management or enterprise resource planning systems.
• Traceability platforms: collect and connect supplier, material and product-flow information.
• Product-compliance and sustainability suites: maintain requirements, evidence, calculations and reporting workflows.
• Identifier, resolver and labelling providers: supply identifiers, physical carriers or services that direct a scan to the relevant information.
• Footprint and lifecycle-assessment providers: supply calculations, methods or supporting datasets.
• Verification bodies, consultants and managed-service providers: offer defined assessment, implementation or operational tasks.

Our view: use these as functional categories, not a ranking or a claim that every provider in a category offers the same service. One provider may cover several functions, and a project may combine providers. Make the boundaries explicit: who maintains the evidence, who publishes it, who manages the printed link and who remains responsible when an interface fails.

Use the latest dated total and category breakdown in the yellow3 Digital Product Passport Supplier Register. The register includes different kinds of organisations; its organisation count should not be treated as the number of directly comparable commercial passport platforms.

A useful shortlist starts with your product group, role, required functions, service scope and evidence needs. Read the scope and date of each supplier record. Stated identifies a supplier statement; Shown identifies supporting evidence recorded for the capability in question. Neither label certifies every aspect of a provider or guarantees suitability for your project.

An empty evidence field does not establish that a supplier lacks the capability. A comparison may display Not on record to make that limitation visible. Use the record to identify the questions and proof still needed.

Our view: assess continuity for every shortlisted provider through its contract, support arrangements and tested exit plan. A supplier count, an acquisition or a funding label does not by itself establish the risk of service failure.

Ask the same questions of every shortlisted provider and make material commitments part of the contract.

1. Which product rules, standards and versions does your offer address? What has been tested, by whom, on which version and at what scope?
2. Which functions are available today, which require configuration or integration, and which are planned? What dated demonstration or production reference supports each answer?
3. Who contacts suppliers, checks evidence, resolves missing data and approves publication? Which of those tasks and languages are included in the price?
4. Which identity, registration and backup steps will you perform where applicable, and which remain our responsibility?
5. Who controls the printed URL and identifier-use rights? What happens to every existing code when we change provider?
6. Can we export the agreed data, evidence, history and access information in a usable documented format, and import it into the proposed successor?
7. How do you protect confidential information, remove access and handle incidents or failed updates?
8. What continues if the provider is acquired, the contract ends or a service fails? Who operates the recovery arrangements?
9. Who performs and pays for changes to delegated acts, standards, data models or integrations after signature?
10. What are the pilot acceptance criteria, exclusions, service commitments and total charges over the agreed operating and retention scenarios, including exit?

Keep supplier statements separate from the evidence supporting them. A successful test establishes what passed in that environment; confirm its relevance to your production volumes, data and responsibilities.

Buying a platform changes how work is performed; a software contract does not by itself change the legal duties attached to your role. The Commission's battery guidance, for example, distinguishes authorization to another party from the responsible operator's ultimate responsibility. Check the corresponding rules for your own product regime.

• Appoint an internal owner who can resolve product-data and supplier-contract decisions.
• Define the evidence and publication rules, and the cases that need your approval.
• Maintain the links between product changes, affected batches and the published records.
• Manage provider performance, exceptions, incidents and the continuity or exit plan.
• Review claims drawn from passport data and involve the relevant legal or compliance owner.
• Track identity credentials, registrations and renewals that remain your responsibility.

Our view: some execution can be contracted out, but name an accountable person for each retained decision. Budget training and integration effort as well as routine administration. Measure the time during the pilot rather than assuming a subscription removes those tasks.

Look for a service you can operate with the people and systems you have, and require the support to be described in the offer. CIRPASS-2's April 2026 readiness work reports difficulties accessing sufficient regulatory information and a substantial education role for service providers. Those research findings support asking for practical onboarding and training; they do not guarantee that a particular provider supplies them.

Our view: ask for a hosted setup with named implementation and support contacts, supplier onboarding where needed, workable imports or existing connectors, and training for the person who checks and approves information. Ask the provider to show the connection to your actual system version and a routine update performed by your team. Confirm any custom development, maintenance or third-party software costs before accepting a 'no-code' promise.

Where the provider will perform identity or registration steps on your behalf, agree the authorization and the tasks you retain. Also document your rights to access, reuse and export the data and evidence, the help available after launch and the route for an urgent incident.

ESPR requires technical, semantic and organisational interoperability and provides for transferability without provider lock-in. These requirements do not establish that any two products will exchange your complete dataset correctly without configuration.

Our view: select a compatible receiving system and agree the versions, interfaces, data model and evidence in scope. Export and import representative records containing identifiers, units, code lists, evidence links, dates, history and both public and restricted information. Check that the meaning and relationships survive, not just the file transfer.

Document any field mapping, unsupported extension or information that requires a separate migration route. Test access rules with real role scenarios rather than assuming that permissions transfer unchanged between systems. Confirm that published links still reach the correct product and that any applicable registration records and checks are handled.

Require failures to be explicit. A receiving system should not silently drop a required field, treat an unknown value as confirmed or expose restricted evidence. Retain the comparison and exception report as proof of what was tested.

Potentially, but confirm acceptance with each customer and its platform. EURATEX's March 2026 position paper calls for information to be supplied once and reused across brands, compatibility with existing systems and protection against proprietary dependence. This is an industry position describing a desired outcome, not evidence that every customer's platform already supports it.

ESPR's interoperability requirements are relevant, but they do not demonstrate the capabilities, contractual terms or extensions of a specific implementation. Customers may use different definitions, evidence rules, update schedules or additional fields.

Our view: maintain reusable source records with identifiers, definitions, provenance and version dates. Keep the permissions to reuse and share each record clear. Ask customers to accept a documented export, API or agreed common template where possible, then map any genuine differences explicitly. Record which customer received which version, so a correction can reach the right recipients without repeatedly rebuilding the evidence.

Check both the legal continuity requirements and the service that will actually operate if the provider fails or changes ownership. ESPR Article 11(e) requires continued passport availability for the prescribed period, including after insolvency, liquidation or cessation of EU activity by the economic operator responsible for creating it. Your service arrangement must also explain how that availability will be maintained if a hosting provider fails. A contract and recovery test are needed to establish how your arrangement delivers the required continuity and independent backup.

A backup may support reading, restoration or further operations depending on the service design. Do not assume that it automatically provides a working replacement for publication, updates, credentials, evidence access or the printed resolver link.

Our view: require a continuity plan that identifies the recovery operator, activation triggers, authorized access to usable data, restoration priorities and the time and cost to resume the required service. Include identifier and domain control, confidential evidence, update rights, registrations and retained history. Review acquisition and change-of-control terms as well as insolvency.

Test the plan during the pilot and repeat the relevant checks after a material architecture or provider change. Separate what is promised in the contract from what the exercise demonstrated.

ESPR requires the backup copy to be made available through an independent third-party Digital Product Passport service provider. A backup option on the primary provider's price list does not tell you which organisation actually holds or operates it. Ask for that organisation's identity and the arrangement that establishes independence.

Do not treat a separate company name as sufficient evidence of operational independence. Shared ownership, infrastructure, credentials or access arrangements can create common dependencies. Conversely, the legal wording alone should not be paraphrased as a settled rule that primary hosting and backup must always be purchased from two unrelated companies.

Our view: seek a backup arrangement that can be accessed and activated without relying on a failed primary service. Assess corporate relationships, infrastructure, recovery rights and funding together. The Commission's planned service-provider rules may further specify requirements; check their adopted status before signing.

Ask what exactly has been certified or approved. As at this FAQ's review, the Commission's planned rules for Digital Product Passport service providers should not be presented as an operating EU quality-certification scheme. Registry identity verification is a different check from technical conformance, data quality or product compliance.

A provider may hold a legitimate private certificate, test report or management-system certification. Identify the issuer, scheme, exact standard and version, evaluated product or service, scope, exclusions, validity and verification route. If the claim is specifically 'EU-approved', ask for the relevant legal basis and official record. A private scheme need not originate in a legal act, but its certificate still proves only its defined scope.

The Commission's 2025 consultation reported that 79% of economic-operator respondents considered provider certification important, while 32% said they would pay more for it. These are consultation findings, not a representative measure of all buyers.

Our view: retain the evidence and its limits. Treat a supplier's statement as Stated until the supporting evidence has been examined for the capability you need.

Agree a pilot that tests the work, the evidence and the exit before committing to the full service. Use representative products and supplier records, including a case with incomplete evidence or more complex access requirements. Set the scope, acceptance criteria, owners, price and decision date in the pilot agreement.

Include an exit exercise. Export the agreed data, attachments, provenance and history; load them into a compatible receiving system; and confirm that an existing printed code reaches the correct record after the move. Check restricted access, missing-field handling, relevant registration steps and the ability to maintain the record afterwards. A second resolver alone does not demonstrate a complete data migration.

Also test a routine update, a failed or rejected update and the recovery route. Use the applicable registry test service where registration is part of the scope, recording precisely what the environment verified.

Log failures and required fixes. A failed test identifies work to resolve before the buying decision; it is not a reason to assume that the same outcome is inevitable in every future implementation. Agree what must pass before production approval.

Estimate the programme from your own dependencies: evidence availability, supplier response, system integration, physical labelling, approvals and the scope of any independent assessment. Separate first publication, pilot acceptance and a production rollout at the required coverage.

Published cases illustrate different parts of the work. Reporting on Löffler described 50 suppliers onboarded in three months; Tom Tailor reported about 240. Another report described an Indian pilot with 25 small exporters producing passports within weeks using secondary footprint data. These accounts have different scopes and evidence boundaries. Supplier onboarding or rapid creation of a pilot record does not establish full product-data coverage or a transferable implementation duration.

Our view: run a representative pilot early enough to measure your own critical dependencies. Schedule the slowest supplier or evidence tasks alongside integration discovery, and leave time for corrections, label changes and acceptance testing. Work backwards from the applicable deadline and your production commitments. A two-year or one-year planning allowance can be a scenario, but it should not be presented as a universal requirement.

Start with the rules for your product group and the role your company performs. For an ESPR Digital Product Passport, the product-specific delegated act determines the required content, granularity and access rights. Sector regimes, including batteries, have their own requirements. A framework regulation or a provider's template is not a final field list for every product.

• Identifiers and operator information: establish which product, company and facility identifiers and contact details the applicable rules require.
• Product and compliance information: map required technical documents, instructions, safety information and other product-specific fields to their source records.
• Substances of concern: where the information requirements apply, ESPR Article 7(5) addresses identification, location, concentration, safe use and end-of-life information, subject to the applicable provisions and exemptions.

The JRC's May 2026 textile draft discusses fibre composition, durability or robustness, substances of concern, recycled content and chain of custody, environmental-footprint information and care instructions. These are preparatory proposals, not adopted textile passport requirements.

Our view: maintain a field list that records the legal or contractual source, status, product coverage, evidence, owner and permitted audience. Keep proposed fields identifiable so that a draft does not silently become a procurement requirement.

Separate three reasons for collecting or publishing a field: an applicable legal requirement, a customer contract and a voluntary business use. Record the specific source in each case. A duty to hold information under another law does not automatically mean that the same information must appear in the Digital Product Passport.

A customer's additional request can become a contractual commitment. Clarify the requested definition, product coverage, format, evidence, access rights, delivery date and update responsibility before accepting it. For voluntary fields, define the benefit and the effort needed to maintain them.

Publishing additional information also creates responsibilities. Environmental statements may fall under consumer-protection and advertising rules, including national measures implementing Directive (EU) 2024/825. The fact that a statement appears in a passport does not establish that the claim is substantiated.

Our view: keep a required core and clearly identified extensions. Review the purpose and evidence for each extra field, and agree when it must be updated or withdrawn.

Assign an authoritative source and an accountable owner to each field or lifecycle event. That source might be your product lifecycle management system, product information management system, enterprise resource planning system, a supplier record or the passport platform itself. The right choice depends on which system can reliably maintain that information and the rights you retain over it.

The ten-company Finnish textile pilot programme found information distributed across enterprise systems, spreadsheets and email. Volvo Cars' battery work also describes the need to maintain connections between supplier information, enterprise records, individual batteries and physical labels. These examples support clear ownership and synchronization; they do not establish one architecture for every buyer.

Our view: define permitted write routes, validation, reconciliation and version history. Distinguish a correction to an old record from a new specification applying to future production. A material or supplier change should not overwrite the facts about previously manufactured batches. Repair and other lifecycle events need their own authorized update routes.

Start with information you already need to identify products, manage suppliers and substantiate existing obligations or claims. This gives preparation a clear purpose while product-specific passport requirements develop.

• Check product identifiers, variants and commodity codes, including the systems that maintain them.
• Map direct suppliers and the upstream relationships needed for your actual products and claims. Record gaps and available facility identifiers.
• Locate existing composition, substance, care, repair and end-of-life records. Record their source, coverage, units and date before commissioning new work.
• Match certificates to the claims and products they cover. Use transaction certificates where the particular scheme requires them; different certification schemes use different evidence.
• Check data-sharing permissions, responsible people and existing credentials before purchasing new services.

Our view: prioritize the gaps that affect a current obligation, a committed customer requirement or a representative pilot. Treat draft field lists as planning inputs. Commission additional testing or footprint calculations when their purpose, method and required precision are clear. This is a practical starting point, not a promise that every possible delegated act will require the same dataset.

Work backwards from each required field or claim to the evidence needed to support it. Supplier depth is a consequence of that evidence requirement, not a single tier number that makes every passport complete. A finished-product fact may come from a direct supplier; a material-origin or chain-of-custody claim may require records further upstream.

Fashion evidence illustrates the challenge, with limits. TrusTrace's October 2026 vendor survey covered 57 sustainability, compliance and supply-chain leaders and reported stronger trusted-data coverage at Tier 1 than at raw-material level. Separately, reporting on Tom Tailor described about 240 Tier 1 and Tier 2 suppliers onboarded in three months while 17% of purchase orders had been traced to raw material. These are different measures and should not be treated as comparable market benchmarks.

Our view: distinguish supplier registration, data received, evidence checked and traceability completed. Define the tier terminology for your sector and measure coverage against the relevant purchase orders, material volumes or products. A supplier count alone does not show whether the required evidence is complete.

A certificate can support a defined claim. It does not establish every fact in a Digital Product Passport. Check the named scheme, certificate type, covered products or sites, issuer, validity and the connection to your materials or deliveries.

• GOTS and Textile Exchange schemes such as GRS: a supplier's scope certificate identifies the certified scope. The applicable transaction-certificate and chain-of-custody rules establish how certified products or deliveries are evidenced. Check the scheme's current rules, including any permitted grouping of shipments or exceptions.
• OEKO-TEX STANDARD 100: this is certification of textile articles tested for harmful substances. Verify the label or certificate and the covered article. Do not request a transaction certificate merely because an article has STANDARD 100 certification.
• Other OEKO-TEX or certification schemes: establish their specific purpose and evidence requirements instead of assuming that the same model applies.

Our view: verify certificates through the issuing body or scheme's official service, link them to the claims and product records they support, and record who checked them and when. Monitor expiry, withdrawal and changes in scope so that affected claims can be reassessed. Keep confidential certificate information within the access rights that apply to it.

First establish exactly which information the supplier is protecting and which information your company or other actors need. EFIC's July 2025 consultation response describes furniture-component suppliers that would share sensitive documentation with third parties, such as ecolabel authorities, rather than directly with manufacturers. This documents an obstacle reported by the association; it does not measure its frequency across the market.

ESPR provides for access rights to be specified in the applicable product rules. EFIC also proposed protected submission routes involving service providers and authorized parties. That proposal should not be presented as an adopted operating model for every sector.

Our view: explore a route in which an authorized provider, verifier or other agreed recipient can receive confidential evidence. Specify which parties can inspect the underlying records and what information each may receive. A summary or verified result is suitable only if it satisfies the actual information and access requirements. Record the verifier, method, evidence link and claim scope; a supplier assertion is different from an independently checked result.

For an ESPR passport, the economic operator placing the product on the market is responsible for ensuring that its information is accurate, complete and up to date. Contracting a provider to perform checks does not, by itself, establish that the underlying product facts are true. Registry and software validation check particular technical or data rules; they should not be described as verification of every claim.

Whether independent assessment is required depends on the applicable product and conformity-assessment rules. Market-surveillance authorities may request documentation and check products. Ask what a provider's validation actually covers: file structure, completeness, consistency, certificate authenticity, calculations or independent examination of the underlying claim.

Our view: keep provenance and an evidence link for each material claim, with the reviewer, scope and date. Set an exception process for conflicting records, missing mandatory information and withdrawn evidence. Identify estimates and calculated values with their method and permitted purpose. AI-generated text or an inferred value should not silently replace a missing supplier fact. Define who resolves the gap and approves a correction before publication.

Define access by data field, actor and permitted action. ESPR requires the applicable product rules to determine access rights and to take confidential business information into account. Avoid assuming that every sector will use the same three access tiers or that every professional has the same entitlement.

The JRC's textile draft discusses differentiated visibility for information including substances of concern and footprint parameters. It is a preparatory proposal. EN 18239 addresses access rights and business confidentiality; its publication and its legal citation status are separate points to check in the current standards record.

Our view: agree who can submit, read, update, export and delegate access to each sensitive field. Test both permitted and denied access through the user interface and APIs. Include supplier isolation, changed roles, revoked credentials and the permissions retained during export or migration. A screen that hides a field is insufficient evidence that the underlying record cannot be retrieved through another route.

ESPR Article 10 prohibits storing customers' personal data in the Digital Product Passport without their explicit consent. Consent does not replace the other applicable GDPR requirements. Ordinary access to public passport information should not require a customer to create an account.

A product's repair or ownership event can be useful without publishing the customer's identity. However, an item identifier or linked event history may still relate to an identifiable person. Check the actual data flows rather than assuming that removing a name makes every record anonymous.

Our view: separate product facts from customer-account and service records where practical. Define the purpose, access, retention and consent handling for any personal information, including what happens after resale or a withdrawal of consent. Ask how the provider supports the applicable data-protection rights while maintaining product information that must remain available.

Use the retention rule in the legislation for your product. There is no single hosting term for every Digital Product Passport.

• ESPR: Article 9(2)(i) requires the product-specific act to set a period covering at least the expected lifetime. Article 11 requires continued availability for that period despite the responsible operator's insolvency, liquidation or cessation of activity in the EU.
• Toys: Article 19(2)(g) requires ten years after placing the toy on the market. Because the passport describes a model, planning must account for the last unit of that model placed on the market, not just the date the passport was first created.
• Batteries: the battery passport ceases to exist after the battery is recycled. Lifecycle responsibility can transfer under the Batteries Regulation.
• Registry metadata: Article 10(3) of the registry regulation provides a ten-year deletion default where Union law specifies no availability period. This is not a blanket ten-year hosting rule for the full passport.

ESPR's requirement for a backup of the most recent version supports continuity. It still needs a workable hosting, funding and recovery arrangement. Our recommendation: price the full required term, including periods after a product is discontinued or the active vendor contract ends. A sofa passport sold in 2030 might need long-term hosting into the 2040s; that is a planning example until the furniture rules set the period.

The sources below do not establish one transferable market price for a Digital Product Passport programme. Separate a published tariff from a vendor's market estimate and from a hypothetical project budget. None is a substitute for a quote covering your products, data work, service scope and operating period.

• Renoon's vendor guide: indicative annual market estimates below EUR 15,000 for its basic category, EUR 15,000 to 100,000 for premium and from EUR 100,000 for enterprise. These are guide categories, not independently comparable compliance specifications.
• DPP-Tool's vendor guide: estimated SME software ranges of EUR 29 to 149 a month, enterprise ranges of EUR 2,000 to 15,000 or more a month, and a custom-build estimate of EUR 200,000 to 500,000. Confirm current offers and included work directly.
• Talk Shop's blog: hypothetical year-one scenarios of about USD 54 per SKU at 100 SKUs and USD 20 at 10,000 SKUs. Their assumptions and SKU denominator should not be transferred to your production volumes without review.

The CIRPASS SME study was qualitative and did not produce a representative price benchmark. Our view: price software, supplier and evidence work, integration, physical carriers, operation, retained availability and exit separately. Which component dominates depends on your starting position and required scope.

Ask which variables change the actual invoice and which create work outside the subscription. The JRC's preparatory textile and steel studies identify granularity as a cost consideration; they do not establish that it is always the largest cost for an individual buyer.

• Record and carrier volume: distinguish product models, variants, batches, individual units and physical labels.
• Supplier work: invitations, supplier accounts, supported languages, evidence review and exception handling.
• Systems and brands: connectors, custom interfaces, separate environments, brands, domains and markets.
• Usage: scans, API calls, storage, attachments and access accounts, where these are charged.
• Updates and change: revised product data, new rules, data-model changes, additional integrations and the work to keep them operating.
• Service period: active production, availability and backup after sales stop, recovery support and exit.

Our view: ask for a worked invoice at your baseline volumes and at a growth scenario. Confirm what counts as a new billable record, whether archived records still incur charges, and which limits trigger a new plan or implementation fee. Definitions such as 'product' or 'passport' need to be explicit in the quote.

A controlled spreadsheet can support a pilot or a workflow with manageable volumes and change. In the Commission's 2025 consultation, 42 of 81 relevant economic-operator respondents, or 51.9%, preferred a combination of manual and automated data exchange. That consultation result supports considering hybrid workflows; it does not establish a spreadsheet limit or a legal preference.

Our view: use an agreed data model, stable identifiers, field definitions, controlled access, validation and a clear owner. Keep evidence linked to the record and make versions and approvals traceable. Avoid distributing uncontrolled copies that different teams treat as the latest source.

Plan automation where repeated entry, update frequency, contributor numbers, exceptions or audit effort make the manual process unreliable or costly. A few hundred products is not a universal threshold. Test how the template will import into the chosen platform, how errors are reported and how approved updates return to the maintained source.

Look for work and continuing obligations that sit outside the headline software price. The CIRPASS SME study identified implementation and operating cost elements, but their size depends on the project. Check each of the following against your actual scope.

• Supplier contact, translation, data collection, evidence review and resolving gaps.
• Testing, footprint calculations or lifecycle-assessment work where the required purpose and method justify them.
• Label design, artwork, printing equipment changes and physical carriers.
• Data cleansing, integration, connector maintenance and changes to existing systems.
• Training, internal approvals, support, incident response and independent assessment where required or chosen.
• Identifier licences and any identity credentials your arrangement requires, after checking what you already hold.
• Hosting, backup and continuity over the applicable service and retention periods.
• Language versions, accessible presentation and testing with the people who need to use the information.
• Regulatory or data-model changes, export, transition assistance and provider migration.

Our view: give every line an owner, an assumption and a price or explicit exclusion. Distinguish one-time work from recurring and event-driven charges. Do not assume that commissioning software includes the work to obtain credible source data or to keep it current.

Compare the same defined service over the same period. Specify product models, variants, batches, physical units, supplier numbers, integrations, languages, evidence work, expected changes and the period for which records must remain available. Ask providers to distinguish platform functions from work performed by their staff.

• Separate implementation, recurring operation and event-driven charges.
• State the billable unit and included allowances for records, scans, API use, storage and accounts.
• Include your internal work, third-party services, tax and currency assumptions, price increases and volume changes.
• Price the period after production stops, plus recovery, export and transition assistance.
• Record exclusions, service commitments, acceptance criteria and responsibility for future rule or data-model changes.

A Deloitte study commissioned by GS1 modelled ten-year European system costs of EUR 3 to 7.1 billion for open, decentralised standards and EUR 63 to 152 billion for competing proprietary systems. These are system-wide scenarios under the study's assumptions, not provider quotes or observed savings available to your company. They should not be used to calculate your project's return.

Our view: use a common scenario and an explicit assumptions register. Assess the value of portability through the tested exit arrangements and their price, rather than importing a system-wide cost ratio into your budget.

ESPR provides for support measures for small and medium-sized enterprises. The Commission's guidance discusses information, training, digital tools, national support and possible financial assistance. That framework does not establish that a particular grant is open, that your project is eligible or that the work will be funded.

Our view: check your national or regional business-support agency and relevant digitalisation or circular-economy programmes. Ask about eligible activities, company size and location, application dates, required match funding, procurement conditions and whether costs incurred before approval can be claimed.

Separate practical support from a grant. A free tool, training programme, pilot opportunity or subsidised assessment may reduce particular tasks without covering the full implementation. Build a viable project budget first and identify confirmed assistance separately from applications or possibilities.

The EU Digital Product Passport registry stores registration information; it does not replace the system hosting the full passport. The Commission launched it on 20 July 2026. Its operating framework is Implementing Regulation (EU) 2026/1778, which entered into force on 6 August 2026.

The registry stores the relevant identifiers and registration metadata, and, where applicable, commodity codes and a reference to the service provider. The applicable rules determine which information is required. Your full passport remains with you or the operator hosting it on your behalf.

Article 8 requires automatic checks against the applicable data model and granularity rules, together with consistency, commodity-code and backup-link checks where applicable. These are checks of structure, completeness and consistency; they do not establish whether every underlying product claim is true. Product models and available testing workflows should be checked in the Commission's current guidance.

A successful registration returns a persistent registration identifier. The registry can also generate a digitally sealed proof of registration. The launch itself did not make passports compulsory for every product: registration duties follow the relevant product law and application provisions.

No. ESPR Article 13(5) expressly says that receiving a registration identifier is not proof of compliance with ESPR or other Union law. The registry can generate proof that a registration obligation has been fulfilled; that is a narrower claim.

The registry checks required structure, completeness and consistency. It does not independently establish the truth of every materials, performance or environmental claim. Operators still need the evidence required by the applicable law, and market surveillance authorities can examine it. Some product regimes also require assessment or verification by other bodies.

Our recommendation: treat registration, technical conformity and substantiation of product claims as separate items in your acceptance criteria.

Start with the requirements for your legal role and product group:

• Verified identity. Legal entities use the permitted qualified electronic seal or electronic-attestation route. Sole traders have different permitted methods, including a qualified electronic signature. The requirements depend in part on whether the actor must be established in the EU.
• Valid credentials. Verification ends when the credential expires or after three years at the latest. Renew it before expiry so you can continue the registry actions allowed for your role.
• Required identifiers and metadata. Prepare the product, operator and facility identifiers where required, in the correct format. Supply a commodity code where the applicable rules require it and reconcile it with customs data.
• A compliant passport and continuity arrangement. ESPR requires the most recent backup with a service provider. Registry backup-link checks apply where relevant; other passport laws must be assessed on their own terms.

Registration can use the web interface or an API. A testing environment is available. Avoiding repeat verification through a system such as EPREL is conditional: the registry must be integrated with that Union system and its verification process must be equivalent or identical. Holding an EPREL account alone is not a blanket exemption.

Yes, where the applicable Union law permits a third party to act on your behalf. Under the registry regulation, the authorised third party must complete the verification process specified in Article 19(4), which refers to Article 5. Your verified economic operator remains responsible for complying with the registry obligations.

Do not confuse authorising a vendor to perform tasks with transferring a registered passport. Article 6a permits transfer to another verified economic operator or, where relevant, a verified value-chain actor that assumes the previous actor's passport obligations from the transfer date, for example following an acquisition.

Sector rules still control who has the underlying duty. The Commission's battery FAQ specifically distinguishes creation and updating from registration by the operator placing the battery on the market.

We have not identified a published Commission registration tariff in the registry guidance reviewed on 20 October 2026. That observation is not a guarantee that every registry-related service is free.

Keep separate the Commission's registry, the trust service used for identity verification, any commercial identifier scheme, and your provider's registration or integration service. A vendor's per-registration charge may be its own service fee. Ask what it covers and whether it continues after a change of provider.

Also confirm which product workflows and data models are available in the testing environment. A working general registry interface does not establish that every future product group already has a final data model. Use the Commission's guidance and helpdesk to resolve that question before making a production commitment.

GS1 is one route, not a universal legal requirement. ESPR requires appropriate persistent, globally unique identifiers and addresses the ISO/IEC 15459 family or equivalent requirements. Harmonised standard EN 18219 specifies requirements for product, operator and facility identifiers and accommodates issuing-agency schemes, self-issuing systems or a combination.

If you already use GS1, a GTIN can identify a product model and a GLN can identify a party or location in the relevant GS1 scheme. A model identifier alone is not enough when the applicable law requires identification of individual items. Other schemes need to be assessed against the applicable legal and technical requirements; the issuing agency's name alone does not establish compliance.

Cost example, checked 20 October 2026: GS1 Germany's published GS1 Complete tariff lists a one-time price of EUR 250 to EUR 580 and an annual usage price of EUR 160 to EUR 32,500, excluding VAT. These depend on numbering capacity and company or group turnover. Other packages and national tariffs differ, so this is not a universal passport cost.

The applicable legislation decides whether a passport identifies a model, batch or individual item. For future ESPR groups, the product-specific act will decide. Some sector choices are already adopted: the battery passport applies to each covered battery, while the toy passport corresponds to a toy model.

Article 8 of the registry regulation adds two rules. If several applicable Union laws require different registration levels for the same product, use the most granular level required. For an ESPR item-level passport, link the batch and model identifiers where batch and model designs exist; a batch-level passport similarly links the model where one exists.

Granularity can materially affect identifier volumes, production-line work, storage and update costs. Item level requires each covered unit to be distinguishable, though shared model data may still be reused. The JRC's draft textile study describes model-level practice and examines granularity as a cost consideration; it is research input, not a final apparel requirement.

The applicable law decides the permitted carrier and where it must appear. For future ESPR product groups, the delegated act will make that choice. The general definition should not be read as permission to choose packaging instead of the product when a sector law requires a product-level carrier.

EN 18220 addresses Digital Product Passport data carriers. Optical codes such as QR and Data Matrix, and radio-frequency technologies such as NFC and RFID, have different reading and durability characteristics. QR codes are widely readable with smartphone cameras; NFC depends on compatible devices; RAIN or UHF RFID normally requires a suitable reader. A technology being covered by a standard does not make it suitable for every product or workflow.

Our recommendation for clothing: assess the carrier over the life stages you need to support, including washing, repair, resale and sorting. Compare woven or printed labels and embedded electronic tags on your own materials. The JRC's draft work discusses carrier durability, but the final apparel requirements remain to be adopted.

Ask for separate prices for QR on an existing label, NFC in a hangtag and NFC embedded in the product, at your volumes. Include encoding, attachment, durability testing, reader equipment and replacement costs. We would not use unsourced per-tag ranges as a procurement budget.

Control of the printed link is an important supplier-exit question. If a carrier points to a vendor-controlled domain, continued access after you leave depends on that domain and its redirection arrangements. Reprinting already sold products may be impractical.

Our recommendation: use a domain or subdomain you control where the chosen identifier and carrier scheme supports it. Pair it with an appropriate identifier syntax, such as the relevant GS1 Digital Link approach or ISO/IEC 18975, and document who controls domain renewal, resolution and redirection. Those standards do not guarantee that any resolver can serve any identifier without configuration.

Before printing at scale, demonstrate that a sample of the actual codes can reach the passport after a simulated change of host. A portable identifier, control of the web address and access to the underlying data are separate requirements. Secure all three in the exit agreement.

Six European standards were cited in the Official Journal by Implementing Decision (EU) 2026/1736, effective 15 July 2026:

• EN 18216: data exchange protocols.
• EN 18219: unique identifiers.
• EN 18220: data carriers.
• EN 18221: storage, archiving and data persistence.
• EN 18222: APIs for passport lifecycle management and searchability.
• EN 18223: system interoperability.

Under ESPR Article 41(2), conformity with cited harmonised standards gives a presumption of conformity with Articles 10 and 11 only for the requirements those standards cover. It is not approval of a provider or proof that the product information is correct.

EN 18239, on access rights, security and business confidentiality, and EN 18246, on data authentication, reliability and integrity, have been published but were not yet cited as of 20 October 2026. The Commission's timeline plans their citation for November 2026. That remains a planned milestone until the Official Journal decision appears.

The technical standards support the system. The applicable product law determines its mandatory information. Our recommendation: ask your vendor for a written mapping of the standards and clauses it supports, the evidence, any limitations and the work needed for your product. Decide whether your internal technical or procurement team also needs access to the standards.

No general EU passport rule requires blockchain. The Commission's battery FAQ expressly confirms that blockchain is optional. ESPR sets outcomes for openness, interoperability, data integrity, security and transfer without vendor lock-in, and requires technology-neutral identifier rules as far as possible.

Blockchain, distributed ledgers, W3C Verifiable Credentials, the UN Transparency Protocol and the Asset Administration Shell are possible architectural choices. Naming one of them does not establish legal compliance, and the passport legislation does not make that list a mandatory technology stack. Check the applicable technical requirements and the implementation itself.

The storage standard EN 18221 addresses decentralised passport storage and persistence. The registry uses applicable data models and its semantic repository to support consistent interpretation. Our recommendation: assess whether a proposed architecture meets access, integrity, continuity and portability requirements at an acceptable cost, including how data and printed links survive a provider change.

For ESPR, the product-specific act will identify who may create or update each type of information and the relevant access rights. Article 11 already requires a new passport created for a product that had a previous passport to link to the earlier one. The existence of that linkage rule does not mean every repair or resale automatically needs a new passport.

For batteries, repurposing or remanufacturing, and preparing a waste battery for reuse or repurposing, can require a new passport linked to the previous one. A simple repair does not. The responsible actor and relevant updates follow the Batteries Regulation, as explained in the Commission's battery FAQ.

Industry example: Fnac Darty describes a passport initiative for large household appliances with information added at factory, delivery, home-repair and workshop-refurbishment stages. This shows an operational data flow; the company's initiative is not evidence that an ESPR appliance passport obligation already applies.

Our recommendation: define an event, responsible actor, permitted fields and audit record for each lifecycle change in your pilot. Distinguish changes to the hosted passport from changes that also require a registry update.

Outsourcing data collection does not automatically transfer your regulatory responsibility. ESPR requires passport information to be accurate, complete and up to date, while manufacturers, importers and other actors retain the duties attached to their roles. The registry regulation also makes the responsible verified operator accountable for its submissions.

The Commission's battery FAQ expressly says that written authorisation to create or update the passport does not transfer ultimate responsibility from the operator placing the battery on the market. A supplier can have its own obligations, but those do not remove yours.

Our recommendation: agree supplier warranties, evidence access, prompt error notification, correction duties and appropriate contractual remedies. Contractual recourse is one route; liability may also depend on applicable national and EU law. Retain the source, date and version of the evidence so you can trace and correct an affected passport.

Discontinuing a product does not by itself end its passport obligations. For ESPR, the passport must remain available for the period specified in the product-specific act, covering at least the expected lifetime. Article 11 also addresses continuity after insolvency, liquidation or cessation of activity in the EU.

Other passport laws set their own periods and lifecycle events. For example, toy passports remain available for the statutory ten-year period, while a battery passport ceases to exist after recycling. Apply the rule for the product rather than assuming every passport has the same end date.

Our recommendation: create a separate budget and service level for discontinued products. Required corrections or lifecycle updates may still arise even when sales and routine marketing updates have stopped. Include continued hosting, link resolution and the applicable backup arrangement.

Availability is a compliance requirement once the relevant passport obligation applies. ESPR Article 9(1) requires a passport for covered products placed on the market or put into service, and Article 11 addresses continued availability. An inaccessible passport can therefore be a customer problem and a compliance risk; the consequences depend on the applicable law and the circumstances.

The detailed future service-provider rules have not yet established a universal availability percentage that you can treat as a legal safe harbour. The Commission's 2025 consultation explored availability expectations: 59 of 81 relevant economic-operator respondents, approximately 73%, said they could not yet estimate the financial cost of unavailability. Those are consultation findings, not adopted uptime standards or a representative measure of all buyers.

Our recommendation: agree availability, incident notification, recovery time and recovery data loss explicitly. Test a broken carrier link and a host outage before accepting the service, including how authorised users reach the backup.

ESPR already requires a backup of the most recent passport version. Article 10(4), together with Articles 27 and 29, requires the relevant backup to be stored by a Digital Product Passport service provider. The registry checks a link to that backup where applicable. These requirements should not be described as wholly undecided.

The detailed future rules for service providers remain pending. The Commission's current programme places that work in 2027. Exact implementation requirements, service arrangements and any certification scheme depend on the adopted act. The definition of a service provider as an independent third party does not itself settle every relationship between a primary host and a backup holder.

Retailers and wholesalers have asked for clarity about backup content, update frequency and responsibilities. EN 18221 addresses storage, archiving and persistence, including backup arrangements. Check how a proposed service satisfies both the current most-recent-version duty and the applicable standard.

Our recommendation: require the backup to follow each published change, retain the history you need and support restoration or continued serving if the primary host fails. Agree the trigger, permissions, recovery time and cost, then observe a recovery test. Apply the specific backup and continuity rules for other passport regimes separately.

For products covered by ESPR passport requirements, Article 31 requires dealers to make the passport easily accessible, including in online and distance sales. Article 10(3) entitles dealers and marketplaces to a digital copy of the carrier or unique product identifier, or a link to a webpage providing it, from the operator placing the product on the market, promptly and free of charge, within five working days of a request.

EuroCommerce has raised concern that passport access could divert shoppers to a manufacturer's sales website. The legal right to receive a carrier or identifier does not by itself guarantee a particular API, a right to republish every restricted field or a ban on sales links.

Our recommendation: agree an authorised feed or API for the public information you want to display on your product page, while preserving clear access to the full required passport. Define how corrections and updates reach your page. If you want a passport landing page without shop links, make that an explicit commercial requirement and verify it in the demo.

Consequences depend on the applicable passport law and the Member State. Under ESPR Article 74, national penalties must be effective, proportionate and dissuasive. Member States must be able to impose at least fines and temporary exclusion from public procurement. That does not mean both sanctions automatically follow every breach.

Authorities can require correction and, where the relevant legal conditions are met, restrict sales or order withdrawal or recall. The Market Surveillance Regulation permits recovery of certain costs of action on non-compliant products. Online marketplaces can receive orders concerning non-compliant listings, and customs may withhold release under the applicable customs and product rules.

There is no single EU-wide fine amount stated in ESPR, and the FAQ does not provide a verified country-by-country schedule. Our recommendation: check the national provisions and sector regime for the markets in which you sell, and prioritise a clear process to detect, correct and document passport errors.

A passport can affect customs clearance, but the rules differ by product law. For a product covered by an ESPR delegated act, Article 15 requires the person seeking release for free circulation to provide or make available its unique registration identifier. That requirement is tied to the relevant product rules and operation of the registry.

The automatic check of the registration identifier and commodity code before release applies when the registry's interconnection with the EU customs single window becomes operational. ESPR requires that link within four years after the registry implementing act enters into force, which gives a deadline of 6 August 2030. The Commission's FAQ mentions an expectation around 2029; that is not the statutory deadline. Authorities also retain risk-based customs and market-surveillance powers.

Battery exception: the Commission's battery FAQ says the battery passport must be registered, but its registration identifier is not to be entered in the electronic customs declaration. Do not apply the ESPR declaration rule automatically to batteries or every other sector passport.

Our recommendation: identify the passport regime with your customs team. Where the identifier and commodity code are required for clearance, register before declaration and reconcile the values in both systems. Registration or release by customs does not certify full product compliance.

A Digital Product Passport is a structured digital record about a product, reached through a data carrier, typically a QR code. The applicable law decides whether that carrier goes on the product, its packaging or accompanying documents. The passport holds the information required for that product group, such as materials, substances of concern, repair or recycling information, and the identity of the responsible economic operator.

A regulated passport has requirements that an ordinary product page may not meet: structured, machine-readable information, interoperable access, persistent identifiers and availability for the legally required period. Under ESPR, the product-specific act must set a retention period covering at least the product's expected lifetime, including continuity if the responsible company stops trading. Other passport laws have their own retention rules.

The relevant identifiers and registration information go into the EU Digital Product Passport registry. The full passport is hosted by the economic operator or its service provider. Registration supports checks by public authorities; it does not certify that every statement in the passport is true.

As of 20 October 2026, the battery passport requirement has not yet started, and no product-specific ESPR act requiring a passport has been adopted. Under ESPR, a passport becomes mandatory when the relevant product-specific requirements apply. Article 4(4) normally provides at least 18 months from the act's entry into force to application, but expressly allows exceptions.

The first passport requirement scheduled to apply is the battery passport. From 18 February 2027, it covers each electric-vehicle battery, battery for light means of transport such as an e-bike or e-scooter, and industrial battery with a capacity above 2 kWh placed on the market or put into service. The 2 kWh threshold applies to industrial batteries, not to the other two categories.

The supporting infrastructure is developing ahead of the obligations: the EU registry launched on 20 July 2026, and six harmonised technical standards were cited in the Official Journal on 15 July 2026. Those milestones do not make passports mandatory for every product. Toys, detergents and construction products follow their own legislation and transition rules.

Separate dates adopted in sector legislation from Commission plans to adopt future ESPR rules. Batteries, toys and detergents have adopted dates. The ESPR dates below are planning milestones, not application dates.

ESPR normally provides at least 18 months between an act's entry into force and application, with exceptions under Article 4(4). Adoption, entry into force and application are different events. The estimates below assume the current programme proceeds and a normal transition is used; the adopted act will control.

Commission planning can change. Footwear is not a separately prioritised product group in the 2025 to 2030 ESPR working plan. Do not assume that an apparel milestone automatically applies to footwear.

Because 2027 is the planned adoption year for the textile act, and an adoption date is sometimes repeated as a compliance deadline. The Commission's textile page currently identifies Q4 2027 for planned adoption and says implementation timing may evolve.

Under ESPR Article 4(4), the normal transition is at least 18 months after the act enters into force. The Article permits exceptions, and the act has not yet fixed the apparel application date. Around 2029 is therefore a planning scenario based on the current programme, not a guaranteed earliest date.

Our recommendation: prepare product and supplier data now and use 2029 as a provisional planning assumption, with a review point when the act is published. If a vendor or adviser quotes 2027, ask whether they mean adoption, a customer requirement or a legal application date, and request the source.

Several sector laws introduce their own passport requirements alongside ESPR:

• Batteries Regulation (EU) 2023/1542: passports for the battery categories in Article 77 from 18 February 2027. Their identifiers are registered in the shared EU registry.
• Toy Safety Regulation (EU) 2025/2509: a passport for each toy model from 1 August 2030, replacing the separate EU declaration of conformity with passport information. Article 57 protects continued marketing of toys lawfully placed on the market before that date.
• Construction Products Regulation (EU) 2024/3110: Articles 75 to 80 establish a construction passport system. The obligation in Article 22(7) starts 18 months after the system act enters into force, with coverage also depending on the new Regulation's product and transition provisions.
• Detergents and Surfactants Regulation (EU) 2026/405: passports for detergents and surfactants intended for end users. The Regulation applies from 23 September 2029; Article 36 permits an additional transition for products complying with the old rules until 23 September 2030.

The Packaging and Packaging Waste Regulation (EU) 2025/40 has digital-labelling and information requirements, rather than a general product-passport obligation for all packaging. Packaging data and carriers may still interact with a product's passport.

Implementing Regulation (EU) 2026/1778 provides the shared registry framework for the passport regimes it lists. One registry identity can support work across those regimes, but does not replace the distinct duties, access rights or product-specific information each law requires.

Planning outlook: further horizontal EU product legislation could expand digital information requirements. Treat proposals and reported drafts as future possibilities; use an adopted legal text and its application provisions to establish a compliance deadline.

For ESPR, Article 9(1) connects the passport requirement to placing a covered product on the market or putting it into service. In EU product law, placing on the market is assessed for each individual unit, when it is first made available on the Union market. A manufacturing date alone does not decide whether a passport is needed.

In general, a new requirement does not retroactively apply to units already lawfully placed on the market. Units first placed after the application date may need a passport even if manufactured earlier. Check the specific act's transition provisions, and treat substantial modification or remanufacturing separately from ordinary resale.

There are already sector-specific examples. Toys lawfully placed before 1 August 2030 may continue to be marketed. For detergents, old-rule products placed before 23 September 2029 may continue to be marketed indefinitely; qualifying old-rule products first placed between 23 September 2029 and 22 September 2030 may be marketed until 23 September 2030.

Our recommendation: map stock by the legal placing-on-the-market event, not just manufacture, shipping or warehouse receipt. Identify production runs likely to cross the application date and plan carrier labelling and evidence of the relevant transactions.

Yes, where the applicable rules cover them. ESPR extends to intermediate products and components as well as finished consumer goods. Selling only to other businesses does not create a general passport exemption.

Iron and steel is a priority intermediate product group, with the Commission currently planning adoption of its ESPR act for Q4 2026. Aluminium is also in the programme, with adoption planned for 2027. These are adoption milestones. The final acts will determine which products and actors have duties, the required information and the application dates.

For a buyer of intermediate materials, the immediate question is which supplier information you will need for your own product, and which information must be supplied in the material's own passport. A customer request may arrive before a legal passport duty applies.

There is no general exemption for small and medium-sized enterprises from ESPR passport requirements. Once a product-specific obligation applies, company size alone does not remove it. Read the act for its precise scope, proportionate measures and any specific exceptions.

Do not confuse passport duties with the separate ban on destroying unsold apparel and footwear. Micro and small enterprises are generally exempt from that ban, while medium-sized enterprises follow from 19 July 2030. ESPR contains provisions to prevent those exemptions being used to circumvent the rules.

The Commission's FAQ points to support for smaller companies, including guidance, digital tools, national contact points and potential financial support. Those measures should help implementation; they are not a blanket exemption or a promise that every service will be free.

Yes. Since 19 July 2026, large enterprises may not destroy unsold apparel, clothing accessories and footwear covered by ESPR Annex VII, except where a legal derogation applies. Medium-sized enterprises follow on 19 July 2030. Micro and small enterprises are generally exempt, subject to the anti-circumvention provisions.

Delegated Regulation (EU) 2026/296 specifies the derogations and their evidence requirements. Examples include dangerous products, substantiated intellectual-property infringements and certain damaged products that cannot be repaired technically or cost-effectively. The donation derogation in Article 2(h) specifies offer routes involving at least three suitable EU social-economy entities or an accessible website, an eight-week period, and evidence requirements. Check all its conditions before relying on it.

Large enterprises also have a separate duty to disclose discarded unsold consumer products, including quantities, weight and reasons. That duty already exists under ESPR Article 24. Implementing Regulation (EU) 2026/2 applies the detailed format from 2 March 2027; it does not postpone the underlying disclosure duty until then.

Our recommendation: use the same inventory controls to support these disclosures and future passport work, while treating them as separate legal obligations.

Responsibility depends on the applicable passport law and each company's role. For products covered by ESPR delegated acts:

• Manufacturer, Article 27: ensures that the required passport is available and that a backup of its most recent version is stored by a Digital Product Passport service provider. Required manufacturer contact details appear in the public passport where applicable.
• Importer, Article 29: has separate duties before placing the product on the market, including ensuring the passport and backup are in place. Required importer contact details appear in the public passport where applicable.
• Distributor, Article 30: verifies the passport is available before making the covered product available and acts on known or suspected non-compliance.
• Dealer, Article 31: makes the passport easily accessible to customers, including in distance sales. This role includes retailers and other businesses offering products to end users.
• Online marketplace, Article 35: cooperates with authorities and may receive orders concerning non-compliant offers.

Under Article 10(3), the operator placing the product on the market supplies dealers and marketplaces with a digital copy of the carrier or unique product identifier, or a link to a webpage providing it, promptly and free of charge, within five working days of a request. The registry rules identify the responsible registrant and allow authorised third-party actions where Union law permits them. Delegating a task does not remove the responsible operator's obligations.

Battery, toy, detergent and construction rules must be checked separately; the ESPR role list is not a universal allocation for every passport.

Manufacturing outside the EU does not remove the legal manufacturer's obligations. If you are the manufacturer under ESPR, Article 27 requires you to ensure the required passport and backup are available for covered products. Your EU importer has separate duties under Article 29 before placing those products on the market. A contract factory supplying another company's branded product may have a different legal role, so identify the legal manufacturer first.

Your EU customers are likely to need materials and production data from you, a suitable carrier on the product, and clarity on hosting, updates and backup. Agree those operational tasks without suggesting that a supply contract can erase duties imposed by law.

Non-EU operators can complete registry identity verification where the applicable law permits their role, using the relevant eIDAS methods. Verification alone does not confer every registrant role. The Commission's battery FAQ, for example, distinguishes creating or updating a passport under written authorisation from registration by the operator placing the battery on the EU market.

Our recommendation: settle who registers and updates, who pays for hosting and backup for the required period, and who controls the web address printed in the carrier. Document the mandate and the responsibility of each legal entity.

An authorised representative does not take over the core manufacturer passport duty under ESPR. Article 28(1) excludes the obligations in Article 27(1), and the preparation of technical documentation, from the representative's mandate. Article 27(1) includes ensuring that the passport and its most recent backup are available.

The representative performs the tasks specified in its written mandate, such as keeping the relevant documentation available to authorities and cooperating with them. It can help coordinate operational work, but that does not transfer the manufacturer's Article 27 duty. An importer also retains its own Article 29 obligations.

The answer is specific to ESPR. Check the separate authorisation provisions if your product uses a battery, toy or another sector passport.

Yes, if you meet the legal manufacturer definition. Under ESPR, that includes a business which has a product designed or manufactured and markets it under its own name or trademark. You do not need to own the factory to be the manufacturer.

Article 34 also treats an importer or distributor as the manufacturer when it places a covered product on the market under its own name or trademark, or modifies an already placed product in a way that affects compliance. The manufacturer's duties include the passport requirements once the applicable act applies.

Our recommendation: treat an own-brand arrangement as a responsibility question when negotiating supplier access, evidence, updates and passport hosting. Confirm the precise legal role for each brand and product rather than relying on who physically made it.

For a product subject to ESPR passport requirements, a distributor must verify that the passport is available before making the product available. It must act when it knows, or has reason to believe, that the product does not comply. A retailer acting as a dealer must make the passport easily accessible to customers, including online.

Under Article 10(3), dealers and online marketplaces can request a digital copy of the data carrier or unique product identifier from the operator that placed the product on the market. The operator must promptly provide the copy, or a link to a webpage providing it, free of charge within five working days. That right supports access to the passport; it does not automatically grant access to every restricted supplier field.

Authorities may order online marketplaces to act on non-compliant offers. Battery, toy and other sector rules can allocate additional or different checks, so confirm the legal regime for each product line.

ESPR makes the relevant operators responsible for compliance and limits how a Digital Product Passport service provider may use passport data. Under Article 11, the provider may not sell, reuse or process those data beyond the relevant storage or processing service unless specifically agreed with the operator placing the product on the market.

For the EU registry, Article 19(5) of Implementing Regulation (EU) 2026/1778 identifies the verified operator as controller for the data it submits. The Commission has its own controller responsibilities for operating the registry. Those roles do not create a universal property right over every fact supplied by another company.

Our recommendation: define your rights to use, publish, correct, export and transfer product data and history in the contract. Secure continued use and control of identifiers and links where the relevant scheme permits it. Supplier agreements should identify which data you may publish and at which access level, including any licence, confidentiality or personal-data constraints.

Consumer interest and observed passport use are different measures. The sources cited here do not establish a scan-rate benchmark that can be transferred to your products or customers.

A Certilogo and SDA Bocconi survey included 1,741 users invited after authenticating a product, with fieldwork in 2024 and publication in 2025. Authentication was the leading expectation reported for a passport. This was a self-selected group already using authentication, not a representative sample of all consumers or a measurement of later passport use. General QR-code activity on product tags also does not show how many people read or acted on passport information.

Our view: ask for the eligible product or customer population, unique scans, repeat and automated traffic treatment, observation period, markets and any incentives. Separate reaching a landing page from reading information, starting a repair or completing a resale action. Keep customer research and behavioural measurements distinct, and evaluate the outcome that supports your own business case.

A Digital Product Passport can support repair, resale, authentication and reuse of product information when the surrounding service and evidence are in place. Treat each benefit as a use case to test, with an owner, baseline, cost and outcome measure.

Bain and eBay discuss potential additional product-lifetime value. That proposition is not a revenue forecast for your catalogue. In KPMG's nonrepresentative survey of more than 70 organisations, 61% expected brand-trust benefits and 9% expected cost savings. These are expectations reported in 2025 fieldwork, not measured returns.

The OECD and EUIPO estimated counterfeit goods at up to 4.7% of EU imports in 2021. That describes the scale of a problem, not the effectiveness of a passport against it. A plain QR code can be copied. Authentication needs a credible connection between the physical item, its identity and the validation process, with the relevant threats tested.

Our view: distinguish required compliance work, measurable operational improvements and customer-value hypotheses. For resale or repair, test whether the intended user can complete the task and whether the outcome improves. For data reuse, measure avoided re-entry or review work. Scale benefits from the evidence you obtain rather than from a headline market claim.

Yes, where the claim is accurate, appropriately scoped and substantiated under the rules that apply in the market where you make it. A passport is a disclosure channel; publishing a value does not independently certify it.

Directive (EU) 2024/825 required Member States to apply their implementing measures from 27 September 2026. Its changes address practices including generic environmental claims without recognised excellent environmental performance, whole-product claims based on only one aspect, sustainability labels without the required scheme or public-authority basis, and claims of a neutral, reduced or positive product climate impact based on greenhouse-gas offsetting. Check the relevant national implementation and other applicable claims rules.

Our view: preserve the scope of the source fact when using it in marketing. For a recycled-content percentage, specify what material or part it concerns, the calculation basis, product or batch coverage and the supporting evidence. Avoid expanding a narrow certificate or component result into a claim about the whole product.

Give claims their own approval and correction process. If the underlying evidence changes or proves wrong, identify the passport records, product pages, labels and campaigns that need review.

The separate Green Claims proposal should not be treated as an adopted obligation. When checked on 20 October 2026, the European Parliament's official file for procedure 2023/0085(COD) recorded its status as awaiting the Council's first-reading position. Use the official legislative file for changes to that status and any future timetable.

This proposal is distinct from Directive (EU) 2024/825 on empowering consumers for the green transition, which already required national implementing measures to apply from 27 September 2026. Existing consumer-protection and advertising rules also remain relevant to environmental claims.

Our view: evaluate a provider's claim of 'Green Claims compliance' against a named, applicable legal requirement and the work actually included. Separate preparation for a proposal from the evidence and claims controls your business needs under current rules. Keep the legal status and source attached to any future requirement in the procurement specification.

A shared evidence base can support several uses, but the outputs and calculation rules still need to be mapped separately. Product identifiers, supplier records, material information and certificates may be reusable inputs for passports, customer requests, claims, due-diligence work or reporting. A common field name does not establish the same meaning, boundary, period, method or required evidence.

EURATEX's position paper asks for information supplied once and reused across brands and compatible systems. That is a useful design objective. It does not establish that one finished dataset satisfies every passport, customs, sustainability-reporting or due-diligence requirement.

Our view: build a shared field and evidence dictionary, then document the transformation for each use. Record identifiers, units, product or batch coverage, dates, calculation methods, provenance, access and reuse permissions. Preserve the underlying records so an output can be checked without recreating its history.

Choose the granularity justified by your actual requirements and use cases. Collecting everything at the finest imaginable level can add work without an established benefit. Measure reuse through fewer repeated requests, less re-entry or faster review, rather than assuming an automatic return.

Assign ownership to someone with authority to coordinate the functions that supply, approve and operate the information. The title matters less than the person's ability to resolve cross-functional decisions and obtain resources.

In KPMG's survey of more than 70 organisations, sustainability was named as a leading function by 46%, IT by 26% and procurement or supply chain by 24%; 23% reported no assigned owner. Respondents could identify more than one function. The September to December 2025 sample was not representative, and these figures do not show which structure performs best.

Our view: name one accountable programme owner and named contributors for product compliance, supplier contracts, product data, IT, security, customer information and claims. Assign operational ownership for publication, exceptions, credentials, provider performance and continuity as well. Give each retained decision an approver and a deputy, with clear escalation when evidence or a deadline is at risk.

Use the next 90 days to establish your scope, evidence gaps and a tested implementation decision. Adapt the sequence to your obligation date, existing systems and current commitments.

1. Establish scope and ownership. List relevant products, markets and company roles. Separate adopted requirements, confirmed application dates and planning assumptions. Name the programme owner and decision-makers.
2. Inspect existing information. Select representative products and map the identifiers, supplier records, evidence, permissions and systems already available. Prioritise gaps with a current legal, customer or pilot purpose.
3. Define the service and buying brief. Decide which work you want to perform internally and which you want a provider to perform. Set the common quote scenario, evidence tests and acceptance criteria. Supplier-data work and provider discovery can proceed in parallel.
4. Check prerequisites before buying them. Confirm existing identifier licences, domain control, credentials and available registration routes. Establish what can be reused and what the provider will handle before ordering additional credentials or services.
5. Run a representative pilot. Test collection, evidence review, access, updates, relevant registration steps, export and continuity. Measure your team's work and the remaining dependencies.
6. Make the rollout decision. Resolve material failures, agree contract responsibilities and change charges, and set the budget and programme against your actual production and application dates.

Add data-delivery, evidence, access, update and continuity commitments to relevant supplier, customer and service contracts through the appropriate contract process. Keep the readiness list connected to the requirements it serves, so speculative fields do not become unnecessary collection work.

Measure the effort, evidence and operating outcomes needed to decide whether to proceed. Agree each measure's definition, denominator, collection method and acceptance owner before starting.

• Collection: time from requesting information to usable evidence, supplier response by the tiers in scope, and unresolved gaps.
• Evidence: required fields supported by appropriate records, checks completed, exceptions and the time to resolve them. Keep optional-field completeness separate.
• Work: staff hours, repeated entry, corrections and time spent coordinating third parties.
• Change: time to approve and publish an update, correct treatment of historical batches and recovery from a failed update.
• Access and usability: successful authorized tasks, denied unauthorized access, revoked credentials and the languages or devices needed by the intended users.
• Portability and continuity: export/import accuracy, evidence and history retained, printed-code resolution and recovery against the agreed target.
• Cost: provider charges, your own work, integration and other in-scope services, with the unit and projected rollout assumptions stated.

Record pass criteria for critical functions and acceptable levels for measurable workload or service outcomes. Investigate whether the pilot sample represents the difficult parts of rollout before extrapolating. Keep demonstrated results separate from a provider's commitment to deliver a future improvement.

Battery passports provide an early, concrete implementation reference, with a legal scope that other sectors should not copy automatically. The Batteries Regulation sets 18 February 2027 for passports for electric-vehicle batteries, light-means-of-transport batteries and industrial batteries above 2 kWh.

The Commission's battery FAQ distinguishes the initial passport obligation from the timing of individual information requirements. It explains that usage fields may initially be empty where the data do not yet exist. It also clarifies that the initial passport start does not itself make carbon-footprint, recycled-content or due-diligence information mandatory. Check the corresponding provisions and detailed guidance for your battery.

The Battery Pass and BatteryPass-Ready work provides industry implementation materials and data models. These are useful reference tools; the applicable legislation and official guidance determine the legal requirements.

Our view: prepare the known identity, evidence and operational dependencies while keeping data models and validation rules configurable. Distinguish a field that is not yet applicable from one that is required but missing. Test lifecycle updates, restricted access and changes in responsibility. Other sectors can reuse that discipline while checking their own content, timing and retention rules.

Watch both the legal text and the implementation guidance. The following remain relevant planning or implementation items as of 20 October 2026:

• Two remaining harmonised-standard citations: the Commission plans the Official Journal decision for EN 18239 and EN 18246 in November 2026.
• Iron and steel: adoption of the ESPR product act is planned for Q4 2026. Its final scope, information requirements and application provisions matter more than the planning quarter.
• Battery restricted-data access: an implementing act remains pending. The Commission programme lists Q4 2026; its battery FAQ expects a draft for public feedback in October or November 2026. Draft publication and final adoption are separate events.
• Service providers: requirements and any certification scheme remain to be adopted. The Commission's timeline places this work in 2027 and currently includes entries in both Q2 and Q3.
• Textiles, aluminium and tyres: ESPR act adoption is planned for Q3 to Q4 2027. These are not fixed compliance dates.
• Construction: the system act is planned for Q2 2027. Follow its entry into force, the 18-month trigger and product coverage under the new Construction Products Regulation.
• Registry administration: Member States must appoint national administrators by 18 February 2027. This is not a common deadline for all national penalty laws; monitor those separately.
• Further horizontal product legislation: a proposal or reported draft can indicate future direction, but does not create a binding passport duty. Check published proposals, adopted acts and their application provisions before changing a compliance deadline.

Our recommendation: assign an owner to this watchlist and review it at each product launch and vendor decision. Record whether an update is a draft, an adopted act, an entry-into-force date or an application date. A date shown in Commission planning can change.