Ownership and governance
Name the accountable business owner, legal and compliance support, data owners, IT lead and product specialists.
Manufacturer implementation guide
Digital Product Passports for Manufacturers: Where to Start
A practical route from regulatory uncertainty and fragmented product data to a governed, testable Digital Product Passport operating model.
People and processData and evidenceSystems and accessPilot to scale
Start with capability
DPP readiness is a business operating-model challenge
A Digital Product Passport connects regulatory requirements to product identity, engineering data, supplier evidence, manufacturing records, customer access and lifecycle updates. No single department owns all of those elements.
Manufacturers should establish a cross-functional programme and prove how information will be governed throughout the product lifecycle. The technology must support that model, but software alone cannot resolve unclear ownership or unreliable source data.
Seven readiness workstreams
Build the foundation before scaling passports
Product scope
Segment the portfolio by product family, market, regulatory route and likely model, batch or item-level passport.
Identity and carriers
Define persistent product identifiers and test QR, NFC or other permitted carriers in the real operating environment.
Structured product data
Create a field-level dictionary covering meaning, format, units, source, validation, owner and update trigger.
Evidence and lifecycle
Connect declarations, certificates, instructions and lifecycle events to the correct product and version.
Systems and integration
Map ERP, PLM, PIM, MES, QMS, service and supplier data without creating another uncontrolled silo.
Access and security
Separate public, customer, service, auditor, authority and internal information by role and legitimate need.
Programme ownership
Create one accountable team across existing functions
The executive sponsor removes cross-functional barriers. Day-to-day ownership should sit with a named programme lead who can coordinate decisions without taking data ownership away from specialist functions.
Executive sponsor
Sets priority, funding and cross-functional accountability
Product / engineering
Owns product structure, specifications, revisions and technical meaning
Compliance / legal
Interprets applicable legislation and confirms evidence obligations
Quality
Controls approved evidence, release status, corrections and audit trail
IT / enterprise architecture
Owns integration, identity, security, resilience and support model
Operations / service
Defines creation, attachment, inspection, repair and retirement workflows
Supply chain
Coordinates required supplier and material data
Commercial / customer teams
Defines useful customer access and the value proposition beyond compliance
Product selection
Choose a pilot that reveals the real operating problems
A successful demonstration is not enough. The pilot should test identity, data ownership, evidence, physical access, stakeholder permissions and at least one change after publication.
- A real product family with known business ownership
- Representative model, batch or serialised identity
- Available specifications and supporting evidence
- A physical carrier that can be tested on the product
- At least one meaningful lifecycle or correction scenario
- A manageable supplier and stakeholder boundary
- Commercial relevance if the pilot succeeds
Product-data chain
Map each passport field back to an accountable source
Every required value should have a definition, system of record, business owner, format, validation rule, access class and update trigger. Evidence needs the same discipline, including version, validity, target product and permitted audience.
Requirement
What the applicable legislation or business case needs
Data owner
Who is accountable for accuracy and approval
Source system
Where the authoritative value or evidence is maintained
Passport rule
How it is validated, versioned, accessed and updated
Connect ERP and PLM without duplicating ownership
Use governed mappings, identifiers, validation and synchronisation to assemble the passport view.
Twelve-week readiness route
Move from scope to an evidence-based scale decision
Scope and ownership
Confirm the product, markets, responsible operator, team, success measures and decision boundary.
Data and identity
Map product hierarchy, identifiers, required fields, evidence, source systems and access classes.
Configure and connect
Build the product and passport templates, load governed data, issue identifiers and test integrations.
Publish and exercise
Publish controlled passports, scan physical carriers and test lifecycle events, corrections and restricted access.
Reconcile and improve
Compare passport outputs with sources, resolve data gaps and measure operating effort and failure modes.
Scale decision
Approve, revise or stop based on evidence, then define the next product family and integration depth.
Common failure patterns
Six mistakes to prevent during DPP preparation
Waiting for every delegated act
Prepare reusable identity, governance and data capabilities now while keeping the final dataset configurable.
Starting with tag procurement
Define passport level, identity, resolver and operating workflow before buying carriers at scale.
Copying everything into one database
Keep authoritative ownership clear and exchange governed data from source systems.
Publishing every document
Classify evidence and expose only the information appropriate to each stakeholder.
Treating publication as the finish
Design corrections, inspections, repairs, status changes and long-term availability from the start.
Choosing an easy demonstration product
Use a representative product that exposes real data and workflow problems.
Start with readiness evidence
Assess one product family, then test the full DPP chain
Use the 30-point readiness checklist to identify gaps, or discuss a controlled UniQorn Trace™ pilot using your real product, evidence and workflow.
Common questions
Digital Product Passports for manufacturers FAQ
Do all manufacturers already need a Digital Product Passport?
No. ESPR creates the framework, while product-specific delegated acts determine which products are covered, the required data, passport level and application dates. Separate EU legislation can create passport duties for other product groups.
What should a manufacturer do before detailed rules apply?
Establish ownership, segment the product portfolio, assess identifiers and source data, create a governed data dictionary, classify evidence and run a controlled pilot using a configurable architecture.
Which department should own the DPP programme?
One accountable business owner is essential, but implementation is cross-functional. Product, compliance, quality, IT, operations, supply chain and commercial teams each own different decisions and data.
Should manufacturers build a DPP platform or buy one?
The decision depends on architecture, capability, scale and long-term operating cost. Evaluate product identity, data modelling, evidence, permissions, interoperability, persistence, security and regulatory change—not only the user interface.
Can existing ERP and PLM data be reused?
Yes. Existing systems should normally remain authoritative for the information they govern. The DPP layer maps, validates and publishes the required view while controlling passport identity, access, evidence and lifecycle history.
How large should the first DPP pilot be?
Start with one representative product family and enough real items or batches to test identity, data, evidence, carrier access, publication, corrections and lifecycle behaviour. The objective is to prove the operating model before scaling.
Primary sources
See Regulation (EU) 2024/1781, particularly Articles 9–13, and the European Commission Digital Product Passport guidance. Verify current product-specific legislation before implementation.
Editorial note: This manufacturer guide provides general readiness information, not legal advice or a claim that every product already requires a DPP.