Implementing a Digital Product Passport: where to start

Five things you can tackle straight away

The Digital Product Passport is a structured, machine readable data set about a product, accessible through a data carrier attached to that product and becoming mandatory product group by product group under the ESPR. What a passport has to contain in detail is set for each product group by its own delegated act. Which product groups are affected at all, and on what timeline, is covered on our overview page on the Digital Product Passport.

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

Understandable, and still the wrong conclusion. You can tackle these five things now, and none of them has to wait for the final delegated act. It sharpens the detail later, it does not replace the groundwork:

1. Assess your exposure. Which of your product groups are likely to be covered, and from when?
2. Prioritise a product group. Where do you start, and why that one?
3. Formulate a target picture. What should someone see when they open the DPP?
4. Name the people responsible. Who carries the topic, and who contributes?
5. Take stock of your data sources. Where does the information sit today, and who maintains it?

For the first two points you need no software and no budget, just two meetings with the right people. The rest of this article shows how that turns into a project.

Key point: Five things do not have to wait for the delegated act. Bringing them forward wins you exactly the time you will be short of later.

Digital Product Passport implementation: the six-phase model

Six phases, in this order. It looks like a lot and in practice it is not: you only ever work on one phase at a time, and the first three are mostly about clarification rather than effort.

1. Get oriented. Work out which of your product groups are affected, when it becomes serious and how urgent the topic is internally. What you end up with is a direction, not yet a project plan.
2. Set the target picture. Working backwards from the finished scan experience, decide which information is likely to become mandatory, which extras you want to add, who will access the passport and at which level it is issued.
3. Set up the project. Fix the first product group, name the people responsible, get a first picture of your data 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. Go into operation. Bring the data carrier, the DPP platform and the registry entry together, and define who is responsible for the DPP inside the organisation after go-live as well.
6. Learn and scale. Once the first passport is live, review it separately for data, production and usage, close the gaps and roll the established process out to your next product groups.

Roles and data ownership run through all six phases, which is why they are not a phase of their own. The most important date is the kick-off in phase three: not an introductory meeting but the start of the work. Once it is clear which product group you begin with and who is committed to contributing, the hardest part is behind you.

Key point: You only ever work on one phase at a time. The kick-off decides whether this becomes a project or stays a meeting.

The target picture: four questions before any system question

The question that structures everything else is this: who needs which information, for which product, to what end? That turns into four decisions.

1. Which information is likely to become mandatory for this product group?
2. Which extras do you want to offer beyond that, such as service content, spare parts or certificates?
3. Which audiences will access the passport, and what does each of them see?
4. At which level is the passport issued: model, batch or individual item?

Point four determines the product identity, meaning the level at which a passport is issued. It has the widest consequences because it reaches into the production process. Model level is enough when all items are identical, for example an electronics product in an unchanged configuration. Batch level is right when supplier, material or composition change from batch to batch, which is the norm in textile production. Item level is what you need wherever service events, repairs or component replacements are recorded over time, for example batteries subject to the Battery Passport. One qualification belongs with the rule of thumb: you must not be coarser than prescribed, and planning more finely can make operational sense, for service and traceability among other things, but what counts for the passport and its registration is the level the delegated act sets for your product group.

In practice the target picture is rarely sharp at the outset. Daniel Vogelpohl, who heads the Customer Success team at Narravero, puts it like this:

"I have yet to meet a customer who says: I have a completely clear vision, this is where I want to go, this is what I need to do and this is when I will be finished."

Daniel Vogelpohl, Head of Customer Success, Narravero

That is not a weakness of these projects. It is the normal state of a market where there are no established examples to copy yet. The interesting counter observation is that the more clearly a project is aimed at compliance, the sharper the target picture becomes. The mandatory part supplies the structure that the voluntary content then attaches to.

A narrow learning scope or a first rollout wave?

There are two defensible ways to size your start. They lead into the same delivery work but differ in risk.

Key point: Granularity is the target picture decision with the widest reach, because it feeds straight into the production process.

Time to shelf: why production lead time is your real deadline

The date in the regulation is not your date. Your date 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 Battery Passport under the Batteries Regulation (EU) 2023/1542 is the clearest example. The obligation applies from 18 February 2027. Anyone starting in autumn 2026 has just under five months on paper. In practice it is less, because decisions on labelling, marking and supplier processes are taken before production starts, and packaging designs, tooling and procurement cycles all hang off them. This is exactly what we are seeing in battery projects right now: companies have to settle immediately how the identifier reaches product and packaging, without the time to think it through properly.

From that follows a very simple recommendation: start with two to four example products before the regulation applies to your product group. The point is not the product. The point is the blind spots nobody had on the list, and a process that has run through once.

The workload is the same either way. The only question is whether it is spread out or arrives all at once, at the moment the deadline is already running. Which deadlines apply to which product group is covered in our article on Digital Product Passport deadlines.

Key point: Plan backwards from production lead time, not from the date the obligation applies. The difference is often several months.

Taking stock: transparency comes before integration

The first data job is transparency, not integration. Three questions per required piece of information are enough to begin with: what do we have, where does it sit, who owns it?

The result is a plain table with four columns: required information, available yes or partly or no, source, ownership. It is unspectacular and still surfaces more in the first session than any system analysis. Typical locations are ERP, PIM, PLM, sustainability and quality data, production data and supplier information. And, very often, spreadsheets and document stores.

Daniel Vogelpohl sums up the current state in one line: "Excel is the magic word at the moment." That is not a criticism, it is a starting position. What matters is not how professional the source looks, but whether someone is named who maintains the value.

Which brings us to the real core question of the data work, and it is not "do we have the value?". It is: who maintains it, when and where? For a battery, data points come together from different sources with different update frequencies. Without named ownership the passport is correct on go-live day and wrong three months later.

For handing data over to the DPP platform there are two routes, and they are a maturity path rather than alternatives: a file via Excel or CSV to get started, an interface for scaling. Not everything has to be automated on day one. The target process should still be clear early, otherwise you build twice.

And one point that blocks projects unnecessarily: a Digital Product Passport does not have to be finished when it is created. The data set, the product identity and the data carrier are separate building blocks. You can create the identity, print the QR code and add content as it becomes available. Two moments are worth keeping apart: the working state may have gaps, the compliance state may not. From the point at which the requirements for your product group apply, the prescribed information has to be complete. The QR code is the access, not the identity.

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

Suppliers, data carriers and the right QR code on the right product

The data carrier, meaning the physical access point to the passport on the product, looks like a detail and is the part that most often gets stuck in practice. Two kinds of data carrier 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 in production, retail and service just as well as it does for the end customer. Which data carrier suits your product depends on the material, on where it is used and on the requirements of your product group.

What tends to be underestimated are the physical constraints. In textiles a care label is the obvious place, but it gets cut off unless there is a reason not to, and a poorly printed QR code can become unreadable after a few wash cycles. On upholstered furniture a visible QR code is an aesthetic intrusion, and some furniture pieces have no accessible underside. These questions can all be solved, just not in the week before production starts.

The biggest process obstacle, though, is a different one. A generic QR code pointing at an overview page needs no real coordination in production. As soon as the QR code refers to one specific product, you have to be sure the right QR code ends up on the right individual item or the right batch. That changes supplier processes, calls for training and additionally requires new verification processes.

Key point: As soon as the QR code becomes product specific, you need new verification processes in production. Without them the evidence falls apart.

Who is needed in the organisation

The DPP is often described as the first topic in a long while that concerns many functions at the same time. Customers often put it as the very first time almost every department genuinely sits at one table and works on one subject together. That is also the reason DPP projects often stall when responsibility is unclear.

So the starting point is a people decision: one person takes on the topic, steers it through and is the point of contact internally and externally. That role might be called Head of DPP internally, regardless of which department it sits in. In mid-sized companies it usually sits close to the management board, in larger organisations there is an additional sponsor at leadership level.

Worth being clear about: these are contributors, not full time roles. Most of them contribute at specific points and do not sit in every meeting. How many people it comes to in the end varies a great deal from company to company and depends on portfolio, sites and organisational form.

Governance here does not mean more meetings. It means a defined path from an open question to a documented decision. An operational round at a short cadence and one steering slot for open points is usually enough.

Key point: What matters is not team size but that one person visibly carries the responsibility.

Four pitfalls that cost you time

None of these is a technical mistake. All four are questions of sequence. Once you know them, none of them costs you more than a deliberate decision.

1. Waiting for the final delegated act. Assessing exposure, prioritising a product group, formulating a target picture, naming the people responsible, taking stock of your data sources: the delegated act sharpens this work, it does not replace it. It can be brought forward.
2. Waiting until the data is complete. This is the most common blocker and it is factually wrong. Starting with the data you have and making the gaps visible on purpose gets you further than a data programme that has to be finished first.
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 verification processes of its own. Clarifying that only after the data model costs you a full procurement cycle.
4. Leaving communication until the end. Plenty of products today carry QR codes that lead to landing pages or nowhere at all. Daniel Vogelpohl calls it QR blindness: "People have learnt that there is no really valuable information behind the QR code on a product." You have to work against that actively, with end customers just as much as with departments, retail partners and suppliers.

An honest qualification belongs with that last point. Where there is real value behind the scan, for example a certificate that is needed for a process anyway, access numbers are high. Where a product sits unpromoted on a shelf and the benefit is not obvious, they are not. The passport alone does not create usage yet.

Key point: None of the four costs budget, they cost lead time. Which is why they only surface once things get tight.

DPP projects in numbers

Key point: The Battery Passport is the earliest fixed deadline and further product groups get their own. Planning happens against production lead time.

Implementation with Narravero

Narravero runs an end-to-end DPP platform. More than 200 enterprise clients across over twelve industries use it, it processes 300 million DPP accesses per month, and it is EU hosted and GDPR compliant.

In a project that means one thing above all: you do not walk this path on your own. A dedicated Customer Success team works alongside you, from the first classification of your product groups through data model and mapping, passport template and identity strategy, to data carrier, production, system integration and operation. We bring with us what has already gone wrong in other projects, and that saves you the detours.

What stays with you are the decisions only you can make: which product group first, who carries the topic, what target picture you are aiming at. Everything else takes shape together. And you do not have to wait for the last detailed requirement to begin.

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 shaping 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 assessing exposure to go-live is a realistic frame, provided responsibilities are clear and you start with the data you already have. The limiting factor is rarely the software. It is production lead time and the coordination with suppliers.

Where does a DPP project start?

With five things that require no delegated act: assessing your exposure, prioritising a product group, formulating a target picture, naming the people responsible and taking stock of your data sources. These then determine which system and which partner fit your plans. You do not have to develop the target picture on your own, and experience from comparable projects helps precisely at this point.

Who should own the Digital Product Passport internally?

One person with a clear mandate who steers the topic and is available to everyone involved. In many projects this role is called Head of DPP internally. Without it, responsibility spreads across compliance, IT and product, and decisions simply sit there.

How large does a Digital Product Passport project team need to be?

There is no standard size. It varies a great deal from company to company and depends on portfolio, sites and organisational form. What matters is not the number of contributors but that one person visibly carries the responsibility and that compliance, product data, IT and production are involved.

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

No. The data set, the product identity and the data carrier are separate building blocks, so you can create the identity, print the data carrier and add content step by step. What matters is the difference between a working state and a compliance state: once the requirements for your product group apply, the mandatory information has to be complete.

Does every product need its own Digital Product Passport?

That depends on granularity. Model level is enough when all items are identical. If supplier, material or composition change from batch to batch, batch level is right. Item level applies wherever service events or component replacements are recorded over time, for example batteries subject to the Battery Passport.

Is there a volume threshold above which a Digital Product Passport becomes mandatory?

No. There is no threshold based on company size or unit numbers of the kind found in supply chain legislation. The obligation arises product group by product group through delegated acts, and individual acts may provide relief for microenterprises.

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 to start with. Connecting via an interface is a question of scaling, not of getting started.

Does the EU registry store all product data?

No. The registry for Digital Product Passports holds key details and a reference. The complete data stays in your own DPP platform, from which it is served when the data carrier is scanned.

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

No. The delegated act sets mandatory fields, granularity and deadlines and can shift details, but it does not replace the preparatory work: assessing exposure, prioritising a product group, formulating a target picture, naming the people responsible and taking stock of your data sources. Starting only after publication costs you exactly the time production lead time will later demand.

When does the 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 set in the Batteries Regulation (EU) 2023/1542 itself and does not depend on any pending act.

How do we make sure the right QR code ends up on the right product?

By making the check part of the production process. As soon as a data carrier points to one specific item rather than to a general page, you need a defined point in the workflow where someone verifies that an identity is present on the individual item or batch and that it is the correct one. Where production is outsourced, that check belongs in the supplier agreement.