How to Create a Digital Product Passport: 7 Steps
Most manufacturers who ask how to create a digital product passport are looking for a clear sequence, not a regulatory overview. Here it is. The process breaks into seven stages — each with its own decisions and dependencies. The rest of this guide goes deep on each one.
- Define your scope — which products, which markets, which DPP category applies
- Map and collect your data — internal systems, suppliers, third-party labs
- Choose your implementation approach — build, buy, or hybrid
- Structure and validate your data — against ESPR data model requirements
- Generate identifiers and data carriers — GS1 Digital Link, QR codes, RFID
- Integrate with existing systems — ERP, PLM, PIM connections
- Test, verify, and go live — then maintain as data evolves
If you are starting from scratch and wondering what a digital product passport actually is, read that guide first — it covers the regulatory context, mandatory data fields, and access control model that underpin everything below.
Step 1 — Define Your Scope Before You Touch Any Data
The most expensive DPP mistake is collecting data for the wrong products or the wrong regulation. Before anything else, you need answers to three questions.
Which regulation applies to your product?
Not all DPPs are identical. A battery DPP under EU Regulation 2023/1542 has different mandatory fields than a textile DPP under the anticipated delegated act, or a construction product DPP. The underlying ESPR regulation sets the framework, but the specific data requirements come from product-category delegated acts. At the time of writing, the battery sector is furthest ahead — the February 2027 deadline is legally fixed and the technical specifications are published. Textile requirements are expected in late 2025 or 2026. For other categories, the Commission's working plan gives a rough priority sequence but not confirmed dates.
Practical implication: confirm which delegated act (or draft regulation) governs your product before designing your data schema. Building a generic DPP that satisfies no specific regulation is a common and costly error.
Which products need a DPP — all of them, or a subset?
DPP obligations typically apply at the product model level for most categories, but at the unit level for batteries above 2 kWh. This distinction matters enormously for cost and effort. Unit-level DPPs mean generating unique identifiers and records for every individual item you produce. Model-level DPPs mean one shared record per SKU or model variant.
If you have a large product catalogue, start by prioritising the models closest to regulatory deadlines, highest by volume, or most exposed to EU market surveillance. Running a pilot on ten models before scaling to thousands is almost always the right call.
Which markets are you targeting?
The DPP framework is EU-specific. If you sell primarily outside Europe, the compliance burden is different. But if any products enter the EU single market — whether through direct sales, distributors, or importers — and fall under a delegated act, the obligation applies. Importers placing goods on the EU market are economic operators under ESPR and share responsibility alongside manufacturers.
Step 2 — Map and Collect the Data You Actually Need
Data collection is where most DPP projects run into trouble. The data exists — somewhere. The problem is that it is scattered across supplier declarations, internal engineering files, third-party lab reports, and ERP systems that were not designed to talk to each other.
What data you need and where it lives
| Data Category | Typical Source | Format | Third-Party Verification Required? |
|---|---|---|---|
| Product identity (model, GTIN, manufacturer) | ERP / PIM system | Structured database | No |
| Material composition | Product specifications, PLM, supplier declarations | PDF, spreadsheet, BOM | Yes (hazardous substances, critical raw materials) |
| Recycled content percentage | Supplier certificates, lab testing | PDF certificates | Yes (for claims above defined thresholds) |
| Carbon footprint (LCA) | Internal LCA study or third-party assessment | PDF report, structured data | Yes (mandatory for batteries, expected for textiles) |
| Energy efficiency class | EU Energy Label test results | Structured data + certificate | Depends on product category |
| Repairability score | Engineering assessment, French Repairability Index if applicable | Score + methodology PDF | Depends on delegated act |
| Spare parts availability | Aftersales / service department | List with part numbers and URLs | No |
| Disassembly instructions | Engineering / technical documentation | PDF, video link | No |
| Hazardous substance list | REACH SVHC declarations from suppliers | SCIP database, PDF | Yes |
| Warranty and end-of-life info | Legal / warranty team, take-back programme data | Text, URLs | No |
Building your supplier data pipeline
Supplier data is consistently the slowest part of any DPP project. Material composition, recycled content, and carbon footprint data depend on upstream cooperation that you do not fully control. The earlier you engage suppliers, the better.
A few things that actually work in practice. First, standardise what you ask for. Sending suppliers a free-form request for "material information" produces inconsistent, unusable responses. Send a structured template — spreadsheet or web form — specifying exact fields, units, and acceptable evidence formats. Second, prioritise Tier 1 suppliers first. You can request that your Tier 1 suppliers ask their own suppliers in turn, but you will not get full chain-of-custody data overnight. Third, build material declarations into new supplier contracts. Every new supply agreement should include a clause requiring DPP-relevant data and a timeline for delivery.
For a complete checklist of mandatory data fields by category, the DPP requirements checklist lists each field with its data type, acceptable evidence, and verification status.
Data you generate internally
Some DPP data is owned entirely by the manufacturer: product identifiers, model descriptions, warranty terms, repair documentation, and conformity declarations. This data is usually more available but often siloed across departments. Engineering, legal, aftersales, and logistics teams may each hold a piece of it. Nominate an internal DPP data owner — ideally in the product or sustainability team — who can coordinate across functions and maintain the record over time.
Step 3 — Choose Your Implementation Approach
There are three realistic paths for building DPP capability, and the right one depends on your technical resources, product complexity, and timeline.
Build your own DPP infrastructure
Building from scratch means developing your own data registry, API layer, identifier generation system, QR code pipeline, and access control logic. This gives you maximum control and avoids vendor dependency. The cost is significant: development time runs to months rather than weeks, ongoing maintenance requires dedicated engineering, and keeping pace with regulatory changes falls entirely on your team.
This path makes sense primarily for very large manufacturers with existing software engineering teams, complex product catalogues that require deep customisation, or companies for whom DPP data will feed into broader product lifecycle management infrastructure they are also building.
Use a purpose-built DPP platform
Purpose-built software handles the registry, API, identifier generation, QR code output, data validation, and access control out of the box. You configure rather than build. The regulatory compliance layer — keeping the data model aligned with delegated acts as they are published — is maintained by the platform rather than by your internal team.
For most manufacturers, particularly SMEs and mid-sized companies, this is the most practical option. The time to first DPP is measured in days rather than months. The upfront investment is lower and the risk of building something non-compliant is transferred to the platform provider. DPP-Tool was designed specifically for this use case: manufacturers who need EU-compliant DPPs without building data infrastructure from scratch.
Hybrid approach
Some companies already have strong PIM or PLM infrastructure and want to generate DPPs from it rather than re-entering data in a new platform. A hybrid approach keeps master product data in existing systems and connects them to a DPP platform via API. The platform handles identifier generation, QR code output, and the public/regulatory-facing data layer. The source of truth for product data stays where it already is.
This is increasingly common for larger manufacturers who have invested in Akeneo, SAP MDG, or similar product data management systems. For a detailed breakdown of how different platforms compare on integration flexibility, see the DPP software comparison guide.
Step 4 — Structure and Validate Your Data
Raw data from suppliers and internal systems needs to be transformed into a structured format that conforms to the DPP data model. This is not optional: the regulation requires machine-readable, standardised data, not PDF documents or spreadsheets.
What the ESPR data model requires
The European Commission, working with ECLASS and GS1, has defined a core data model for DPPs based on JSON-LD and REST API principles. Each data element has a specified identifier, data type, unit of measure, and language handling. Dates follow ISO 8601. Substance identifiers follow CAS or EC number formats. Identifiers follow GS1 Digital Link or equivalent URI schemes.
Validation means running your structured data against the published schemas before generating any DPP. A DPP with incorrectly typed fields, missing mandatory elements, or non-conformant identifiers will fail market surveillance checks and — once automated enforcement systems are deployed — may block product placement on the market.
Data quality checks that prevent go-live problems
Beyond schema validation, do a manual quality pass on a sample of DPP records before scaling. Check that recycled content percentages match the supporting certificates. Verify that carbon footprint figures use the correct unit (kg CO2 equivalent, not tonnes, or vice versa — a common mistake). Confirm that product identifiers are unique and correctly linked to physical data carriers. Test that access control rules work: a consumer-facing scan should not expose data intended only for market surveillance authorities.
Step 5 — Generate Identifiers and Data Carriers
The data carrier is the physical link between the product and its DPP. Getting this right is critical because it determines how downstream users — consumers, repair technicians, recyclers, regulators — actually access the passport.
GS1 Digital Link — the recommended identifier standard
The GS1 Digital Link standard encodes a resolvable URL directly into a barcode or QR code. When scanned, the code resolves to the appropriate data endpoint depending on who is scanning and what context they are in. A consumer scanning a product in a shop might see energy efficiency and repair information. The same code scanned by a recycling facility resolves to detailed material composition data. A market surveillance authority scanning it resolves to the full compliance record.
This is significantly more powerful than a simple QR code pointing to a static web page. The resolution service routes the scan to the correct data layer. GS1 Digital Link is not mandatory under all delegated acts, but it is the approach recommended by the Commission and the most future-proof choice.
Choosing the right data carrier format
| Format | Best For | Read Distance | Cost per Unit | Consumer Scannable? |
|---|---|---|---|---|
| QR code (printed) | Consumer products, textiles, packaging | Line of sight, <30cm | Negligible (print cost only) | Yes (smartphone camera) |
| GS1 DataMatrix | Small products, pharmaceuticals, electronics | Line of sight, high density | Negligible | Yes (with appropriate app) |
| NFC tag | Durable goods, luxury items, electronics | <4cm | €0.10–€0.50 | Yes (tap with smartphone) |
| RFID tag (UHF) | Industrial products, pallets, logistics | Up to 10m | €0.10–€1.00 | No (requires reader) |
| Laser-etched code | Metal components, batteries, high-durability | Line of sight | €0.50–€5.00 (setup amortised) | Yes (QR format) |
For most products entering the consumer market, a printed QR code encoding a GS1 Digital Link URL is the right starting point. It is lowest cost, requires no special reader infrastructure, and is universally scannable. For batteries, where the data carrier must survive the product's full lifetime (which can span decades for industrial batteries), a laser-etched QR code or NFC tag embedded in the battery housing is more appropriate.
What happens when a data carrier is not scannable?
The regulation requires that the data carrier remain legible throughout the product's useful life. For consumer products with short lifespans this is relatively easy to achieve with printed labels. For industrial equipment or batteries expected to last 10–20 years, carrier durability is a genuine engineering question. Factor in heat, moisture, UV exposure, and abrasion in the environment where the product will be used, and test your chosen carrier format before committing to production volumes.
Step 6 — Integrate With Your Existing Systems
A DPP that requires manual data entry for every product update will fail operationally within months. Sustainable DPP management requires connecting the DPP platform to the systems where product data actually lives.
ERP integration
Enterprise resource planning systems hold product master data, bill of materials, production batch records, and supplier information. For most manufacturers, the ERP (SAP, Oracle, Microsoft Dynamics, or similar) is the most important integration point. A well-built ERP integration means that when a supplier material is updated, the corresponding DPP field updates automatically — rather than requiring a manual update by someone who may not know the change happened.
PLM integration
Product lifecycle management systems hold engineering specifications, component lists, and design documentation. For products with complex material compositions — batteries, electronics, industrial machinery — PLM integration gives DPPs access to the bill of materials directly, rather than relying on manual transcription from engineering PDFs.
PIM integration
Product information management systems (Akeneo, Salsify, inRiver) are increasingly used as the single source of truth for product data published to retail, e-commerce, and regulatory systems. If your organisation already uses a PIM, connecting the DPP platform to it means consumer-facing DPP content stays in sync with your product listings automatically.
Supplier portal or EDI connections
For supplier data — material declarations, recycled content certificates, carbon footprint data — you need either a supplier portal where suppliers log in to submit and update their declarations, or an EDI/API connection if your suppliers have systems that can provide structured data directly. Manual supplier data collection via email does not scale and creates version control problems that are genuinely painful when a market surveillance authority asks for evidence.
Step 7 — Test, Verify, and Go Live
Before your DPP goes live, work through a structured verification process. Market surveillance authorities will be able to audit DPPs, and non-conformant records carry real consequences: products can be prohibited from EU sale if their DPP fails to meet requirements.
Technical testing checklist
- Scan each data carrier format with at least three different smartphone models and camera apps
- Verify that the resolution service routes correctly for each actor type (consumer, operator, authority)
- Confirm that mandatory fields are populated for every product in scope
- Validate data against the published schema — no type mismatches, no missing required elements
- Test API response times under load — the regulation requires the data to be accessible
- Confirm that access-controlled data layers are not exposed to unauthorised actors
- Test your update process: modify a field and confirm the change propagates correctly
Third-party verification
For certain data fields — carbon footprint, hazardous substance declarations, recycled content claims above threshold levels — third-party verification is mandatory. Build this into your project timeline. Third-party LCA audits and substance verification typically take 6–12 weeks and cost between €3,000 and €20,000 depending on product complexity. These are not optional extras that can be deferred to a later compliance phase.
Realistic Timeline and Cost Estimates
One of the most common questions manufacturers ask is how long this actually takes. The honest answer depends heavily on starting point, product complexity, and whether you build or buy.
| Scenario | Timeline | Key Bottleneck | Typical Cost Range |
|---|---|---|---|
| Simple product, purpose-built platform, data ready | 2–6 weeks | Data validation and carrier sourcing | €2,000–€10,000/year (SaaS) |
| Complex product (e.g., battery), purpose-built platform, data collection needed | 3–6 months | Supplier data collection, third-party LCA | €15,000–€60,000 first year (SaaS + LCA + integration) |
| Large catalogue (100+ models), platform with ERP integration | 6–12 months | ERP integration, supplier pipeline | €50,000–€200,000 first year |
| Custom build (in-house registry and API) | 12–24 months | Engineering resource, ongoing maintenance | €150,000–€500,000+ (build + maintain) |
These ranges are rough but grounded in real project timelines. The biggest variable is supplier data readiness. If your suppliers can provide structured, verified material declarations within weeks, data collection does not become a bottleneck. If you are starting supplier engagement from scratch, assume six months minimum for the data collection phase alone — particularly if third-party verification of those declarations is required.
For battery manufacturers specifically, the February 2027 deadline is 24 months away. That sounds comfortable until you account for a 6-month supplier data pipeline, a 3-month LCA audit, and a 3-month integration and testing phase. Companies in the battery sector who have not started scoping yet are already in a tight timeline. Review the EU battery passport requirements to understand the full field specification and plan your data collection accordingly.
For companies in the textile sector, the textile product passport guide covers the anticipated requirements and how they differ from the battery framework — useful for scoping data collection before the delegated act is finalised.
Common Mistakes — and How to Avoid Them
Having watched companies work through DPP implementation, there are failure modes that come up consistently enough to be worth naming explicitly.
Treating DPP as a one-time project rather than ongoing data management
A DPP is not a document you create once and file. Products change — materials get reformulated, suppliers switch, certifications expire, repair parts availability updates. The regulation requires DPPs to reflect the current state of the product. Companies that treat DPP as a compliance project rather than a data management function find themselves with stale, non-conformant records within 12 months of launch.
Collecting data in the wrong format
Asking suppliers for PDF declarations is understandable — PDFs are familiar. But PDFs cannot be directly ingested into a DPP system. You will need to transcribe or parse the data, which introduces error and delay. Where possible, require structured data from suppliers in the format your DPP system can import: JSON, XML, or a standardised template spreadsheet that maps directly to your data model.
Underestimating the identifier management problem
If your DPP uses unit-level identifiers (required for batteries above 2 kWh), you need a process for assigning unique identifiers at production time, encoding them onto data carriers, and associating them with the correct DPP record. This needs to be part of your production line workflow, not an afterthought. Companies that realise mid-implementation that they have no identifier assignment process face delays of months while the production operations team is brought into the project.
Forgetting the access control layer
The ESPR regulation distinguishes between public data, operator data, and authority data. A DPP that exposes everything to everyone — or, conversely, a DPP where consumers cannot access basic product information — fails on both ends. Get the access control model right in the design phase, not at testing.
Starting too late
The February 2027 battery deadline has been fixed since EU Regulation 2023/1542 was published. Yet many battery manufacturers started scoping work only in late 2025 or early 2026. The regulatory calendar for other product categories will follow the same pattern: dates known years in advance, implementation left too late. If a delegated act for your product category is in draft, treat the expected publication date as your project start trigger — not the enforcement date.
Frequently Asked Questions
- How do I create a digital product passport?
- Creating a digital product passport involves seven stages: defining the regulatory scope for your product, collecting the required data from internal systems and suppliers, choosing between building your own infrastructure or using a purpose-built platform, structuring and validating data against the ESPR data model, generating unique product identifiers and data carriers, integrating with your existing ERP or PLM systems, and testing before going live. For most companies, using a dedicated DPP platform significantly reduces the time and technical complexity involved.
- What software do I need for a DPP?
- You need software covering four functions: a data registry, a conformant API layer, identifier and QR code generation, and access control. Purpose-built DPP platforms like DPP-Tool handle all four. Companies with existing PLM or PIM infrastructure often connect those systems via API, keeping master product data where it already lives while the platform manages the regulatory-facing output.
- Can I create a digital product passport without specialist software?
- Technically yes, but building compliant DPP infrastructure from scratch — a registry, conformant API, GS1 Digital Link encoding, access-controlled data endpoints — takes 12–24 months of engineering time and requires ongoing maintenance as delegated acts evolve. For most manufacturers, purpose-built platforms are faster, lower cost, and transfer the regulatory compliance maintenance burden to the platform provider.
- How long does it take to set up a digital product passport?
- From 2–6 weeks for a simple product with data already available, to 6–12 months for large catalogues requiring ERP integration and supplier data collection. Battery DPPs requiring third-party LCA verification typically take 3–6 months even with a platform. The biggest variable is supplier data readiness — collecting verified material declarations is consistently the slowest phase.
- What does a digital product passport cost?
- SaaS platform costs range from approximately €2,000–€10,000 per year for simple catalogues to €50,000–€200,000 in year one for large catalogues with integration and third-party verification. Building your own infrastructure costs €150,000–€500,000 or more in year one. Third-party LCA audits, mandatory for certain data fields, add €3,000–€20,000 per product category regardless of approach. See DPP-Tool plans and pricing for platform cost breakdowns.
- Do I need a DPP for products sold outside the EU?
- The obligation applies to products placed on the EU market. If products enter the EU through any route — direct sales, distributors, or importers — and fall under a delegated act, they need a compliant DPP. Importers are economic operators under ESPR and share compliance responsibility with manufacturers.
- When do digital product passports become mandatory?
- Batteries above 2 kWh placed on the EU market after 18 February 2027 are already subject to legally fixed DPP requirements under EU Regulation 2023/1542. For other product categories — textiles, electronics, furniture — mandatory dates are set by delegated acts under ESPR (EU 2024/1781), with the first acts expected in 2025–2026 and enforcement typically 12–24 months after publication.