Implementing a Digital Product Passport: where to start

Five decisions before choosing a system

The Digital Product Passport is a structured, machine-readable data record about a product, accessible through a data carrier attached to that product, and made mandatory product group by product group through the ESPR. What a Digital Product Passport has to contain is set for each product group by its own delegated act. Which product groups are affected and what the timeline looks like is covered on our overview page on the Digital Product Passport.

The foundations are now in place. Implementing Decision (EU) 2026/1736 of 14 July 2026 cites the harmonised standards in the Official Journal, and Implementing Regulation (EU) 2026/1778 of 16 July 2026 sets out the detail on the EU registry. What is still open is the product-specific detail. That is exactly what many companies are waiting for, and exactly the wrong conclusion to draw.

These five decisions sit with you and do not depend on a final legal act. The act sharpens the detail later; it does not replace the groundwork:

1. Assess exposure. Which product groups are likely to be covered, and from when?
2. Prioritise the product group. Where do you start, and on what grounds against the other programmes in your portfolio?
3. Define the target picture. What should someone see who opens the DPP?
4. Name the owners. Who carries the mandate, and who contributes?
5. Take stock of your data sources. Where does the information sit today, and who maintains it?

The first two points call for no system decision, but for a firm alignment between compliance, product management and production. Point two is the uncomfortable one: the Digital Product Passport competes with the other programmes in your portfolio for the same people, and without a solid rationale it loses that contest. The rest of this article shows how this becomes a project with a plan.

Key point: Five decisions require no legal act. Taking them early buys you the time that production lead time will demand later.

Digital Product Passport implementation: the six-phase model

Six phases, in this order. The first three are about clarification and prioritisation; the effort starts in phase four.

1. Orientate. Work out which product groups are affected, from when it gets serious and where the project stands against the other programmes in your portfolio.
2. Set the target picture. Decide backwards from the finished scan experience: which information is likely to become mandatory, which added value should come with it, which audiences will access it, and at which level the Digital Product Passport is issued.
3. Set up the project. Fix the first product group, name owners with a mandate, build a picture of your data situation and processes, and agree a work plan with dates and success criteria.
4. Deliver. Run the four workstreams data, passport template, product identity and communication in parallel, and check at every handover that they still fit together.
5. Take into operation. Bring data carrier, DPP platform and registry entry together, and settle who owns the DPP inside the organisation after go-live.
6. Learn and scale. Once the first Digital Product Passport is live, review it separately for data, production and usage, close the gaps and roll the proven process out to the next product groups.

Roles and data ownership run through all six phases and are therefore not a step of their own. The critical date is the kick-off in phase three: not an introductory meeting, but the start of the work. Once it is settled which product group you begin with and who contributes on a binding basis, the hardest decision has been made.

Key point: The kick-off decides whether the topic becomes a project with a mandate or a meeting without consequences.

The target picture and granularity

The question that structures everything else is this: who needs which information, for which product, and to what end? It turns into four decisions: which information is likely to become mandatory for this product group, which added value should be created alongside it, which audiences will access it and what each of them sees, and at which level the Digital Product Passport is issued.

The last question determines the product identity and has the widest consequences, because it reaches into the production process. Model level is enough where every unit is identical, for example an electronics item in an unchanged configuration. Batch level is right where supplier, material or composition change from batch to batch, which is the norm in textile production. Item level is what you need where service events, repairs or component replacements are recorded over time, for example batteries subject to the Battery Passport. You may not go coarser than prescribed. Planning finer can make operational sense, but what governs the Digital Product Passport and its registration is the level the legal act sets for your product group.

At the start, the target picture is rarely sharp. That is why we work with a fixed approach that reduces the uncertainty instead of assuming it away. One observation from live projects helps here: the more clearly a project is set up around compliance, the sharper the target picture becomes. The mandatory part provides the structure that the voluntary content attaches to.

What becomes possible beyond compliance

The second question is the one most often skipped. The data carrier on the product is the first direct connection between manufacturer and user that does not run through retail or a platform. Four effects hang on it:

• A channel of your own at the product. Whoever scans has the product in their hands. Service content, accessories and spare parts can be placed exactly there, without waste coverage and without an intermediary.
• Field data of your own. Which variants are opened how often, in which markets, at which stage of the product life. Manufacturers selling indirectly have not had access to these signals.
• Discoverability for machines. Marketplaces, procurement systems and AI assistants work with structured, substantiated product data. Making yours machine-readable puts you where a PDF data sheet is never read.
• Less friction in service. At item level it is on record which components were fitted and which were replaced. That measurably shortens returns and service cases.

This content adds little to the implementation effort as long as it is in the target picture. Content can be added later; the level cannot. Once the data carrier is in production at model level, you only get data per batch or per item through a new data carrier and the next production cycle.

The scope you start with follows your maturity, not your caution. If data situation, suppliers, production and ownership are settled, you can go straight into the first rollout wave with a complete product line or a single sales market. If some of those points are open, you cut the first wave narrower and close the gaps in parallel. The goal is the same either way: to cover the affected portfolio completely with Digital Product Passports.

Key point: Content can be added later, granularity cannot. Think the added value through now and you choose the level that carries both.

Time to shelf: production lead time as the binding date

The date in the regulation is not the date you plan against. What binds you is the day production starts for the affected batch, because from then on it has to be settled how the data carrier gets onto the product.

The Digital Battery Passport under the Batteries Regulation (EU) 2023/1542 is the clearest example. The obligation applies from 18 February 2027. Start in autumn 2026 and you have just under five months on paper. In practice it is less, because decisions on labels, marking and supplier processes are taken before production starts, and packaging designs, tooling and procurement cycles depend on them.

One simple recommendation follows from this: run the process through once in full before the regulation applies to your product group. What counts is not the individual product, but a process that holds and the blind spots nobody had on the list beforehand. The effort stays the same; the question is whether it is spread out or lands all at once. Which deadlines apply to which product group is covered in Digital Product Passport: when does it apply?

Key point: You plan backwards from production lead time, not from the date the rules apply. The difference is often several months.

Taking stock: transparency before integration

The first data job is transparency, not integration. Three questions per required piece of information are enough: what exists, where does it sit, who owns it? The result is an overview with four columns: required information, availability, source and ownership. In the first session it regularly reveals more than a systems analysis.

Typical sources are ERP, PIM, PLM, sustainability and quality data, production data and supplier information. They are almost always scattered, even where the system landscape is fully rolled out: individual records have historically been maintained outside the leading systems. The aim is therefore not to lift all data into one system straight away, but to name a leading source and an owner for every piece of information.

That puts the real core question on the table, and it is not "do we have the value?". It is: who maintains it, when and where? On a battery, data points from different sources with different update frequencies come together. Without named ownership, the Digital Product Passport is correct on the day of go-live and wrong three months later.

There are two routes for handing data to the DPP platform, and they represent a level of maturity: a structured file handover for the first run, an interface for scaling. The target process should be settled early; it does not have to be automated on day one.

One point blocks projects unnecessarily: a Digital Product Passport does not have to be finished when it is created. Data record, product identity and data carrier are separate building blocks, so you can create the identity, print the QR code and add the content later. Two moments need to be kept apart: your working state may have gaps, your compliance state may not.

Key point: The question is not "do we have the value?", but who maintains it, when and where. Everything else follows from that.

Data carriers, suppliers and production

The data carrier, the physical access point to the Digital Product Passport on the product, looks like a detail and is the part where most projects get stuck in practice. Two types dominate: the QR code as a visible, durably readable access point, and the NFC tag, which can be read without line of sight and therefore works as well in production, retail and service as it does for the end customer. Which one fits depends on the material, the point of use and the requirements of the product group.

The physical constraints are underestimated. A care label is the obvious place in textiles, but it gets cut off, and a poorly printed QR code can be unreadable after a few wash cycles. On upholstered furniture a visible QR code is a visual intrusion, and some pieces have no accessible underside. All solvable, but not in the week before production starts.

The biggest process pitfall is a different one. A generic QR code pointing to an overview page needs little coordination in the production process. As soon as the QR code refers to a specific product, it has to be guaranteed that the right QR code ends up on the right item or the right batch. That changes supplier processes, calls for training and additionally requires new inspection steps, across every plant and manufacturing partner involved.

Key point: As soon as the QR code becomes product-specific, you need new inspection steps in production. Without them the evidence falls over.

Who is involved in the organisation

For many companies the Digital Product Passport is the first project in a long time that touches almost every function at once. Daniel Vogelpohl, who leads the Customer Success team at Narravero, hears the same thing from customers again and again: "This is the very first time that all of us have had to sit down at one table and actually work on one topic together." That is exactly where projects without clear ownership fail. So it starts with a people decision: one person takes on the topic, steers it through and is the point of contact internally and externally. Internally this role is often called Head of DPP, regardless of which department it sits in. It needs a mandate that holds across functions, and a sponsor at leadership level who resolves priority conflicts with the other programmes in the portfolio.

These are contributors, not full-time positions; most of them contribute at specific points. Governance here does not mean more meetings, but a defined path from an open question to a documented decision: an operational round at a short cadence, a steering slot for escalations.

Key point: What matters is not team size, but a mandate that holds across functions.

Four pitfalls that cost lead time

None of them is a content mistake; all four are questions of sequence.

1. Waiting for the final legal act. Assess exposure, prioritise the product group, define the target picture, name the owners, take stock of your data sources: the delegated act sharpens this work, it does not replace it.
2. Waiting until the data is complete. The most common blocker, and factually wrong. Starting with the data you have and making the gaps visible on purpose gets you further than a data programme in front of the project.
3. Treating the data carrier as a printing topic. As soon as the QR code becomes product-specific, it is a production and supplier topic with inspection steps of its own. Clarify that only after the data model and you lose a full procurement cycle.
4. Leaving communication until last. Plenty of products carry QR codes that lead to landing pages or nowhere at all. Daniel Vogelpohl calls this QR blindness: whoever scans no longer expects to find anything useful behind it. What helps is an early decision on what sits behind the QR code: the declaration of conformity for retail, the repair information for service, the matching accessory for the end customer. That content comes from the same sources as the mandatory information. Settle it only after go-live and you push the data collection through suppliers and approvals a second time.

All four have the same root cause: the Digital Product Passport is planned as evidence, not as product data infrastructure. Starting compliance-driven is the right call here; the mandatory part provides the structure. Leave it at that, and you defer potential that the same data carrier brings with it anyway.

Key point: None of the four costs budget, they cost lead time. They arise wherever the DPP is planned as evidence and nothing more.

Implementation with Narravero

Narravero runs an end-to-end DPP platform. More than 200 corporate customers across twelve industries use it, it serves 300 million DPP accesses per month, EU-hosted and GDPR-compliant.

We treat the Digital Product Passport not as a piece of evidence to be filed, but as product data infrastructure that compliance, service and customer contact all build on. A dedicated Customer Success team supports the project from classifying the product groups through data model, passport template and identity strategy to data carrier, production, system integration and operation. What stays with you are the decisions only you can take: portfolio prioritisation, ownership, target picture.

Thomas Rödding, founder and CEO of Narravero, is personally involved as Co-Chair of CEN-CENELEC JTC 24 and as Vice Chairman in German standardisation (DIN/DKE), the bodies that shape the technical framework for the Digital Product Passport in Europe.

Book a demo →

Key point: Uncertainty does not disappear by waiting. It becomes workable as soon as the first product runs through the process.

Frequently asked questions about implementing a Digital Product Passport

How long does it take to implement a Digital Product Passport?

For a first product group, six months from the exposure assessment to go-live is a realistic frame, provided ownership is settled and you start with the data you have. The limiting factor is rarely the software; it is production lead time and the alignment with suppliers.

Where does a DPP project start?

With five decisions that require no legal act: assess exposure, prioritise the product group, define the target picture, name the owners and take stock of your data sources. Those points then determine which system and which partner fit your project.

Who should own the Digital Product Passport internally?

One person with a mandate that holds across functions. In many projects this role is called Head of DPP internally. Without it, ownership is spread across compliance, IT and product, and priority conflicts with other programmes stay unresolved.

Does a Digital Product Passport have to be complete when it is created?

No. Data record, product identity and data carrier are separate building blocks, so you can create the identity, print the data carrier and add the content step by step. What has to be kept apart is the working state and the compliance state: once the requirements apply to your product group, the prescribed information has to be complete.

Which systems have to be connected for a DPP?

In practice ERP, PIM, PLM, quality and sustainability data, production data and supplier information, often supplemented by spreadsheets and document stores. A file handover is enough for the first run; connecting through an interface is a question of scaling.

Does the EU registry store all product data?

No. The registry for Digital Product Passports holds key information and a reference. The complete data stays in the company's DPP platform, from which it is served when the data carrier is opened.

Should we wait until the delegated act for our product group is final?

No. The act sets mandatory fields, granularity and deadlines bindingly and may shift details, but it does not replace the groundwork: assess exposure, prioritise the product group, define the target picture, name the owners, take stock of your data sources. Start that only after publication and you lose exactly the time that production lead time will need later.

When does the Digital Battery Passport obligation apply?

From 18 February 2027 for electric vehicle batteries, industrial batteries with a capacity above two kilowatt hours and batteries for light means of transport placed on the EU market. The date is fixed in the Batteries Regulation (EU) 2023/1542 and does not depend on any outstanding legal act.