The digital product passport: three regimes, three timelines, one record

Trade fairs have announced the digital product passport for years. Creating a field called “DPP” in your system on that basis gains nothing: there is not one passport but three regimes with three timelines and three tables of contents. For a recycler or parts trader the only useful question is which one covers their part — and which data they have to capture for it today.

Three regimes, kept apart

What already applies: the battery

The battery is the only component with a fixed date. The battery passport under Article 77 of Regulation (EU) 2023/1542 becomes reachable via QR code from 18 February 2027; it covers batteries for light means of transport, industrial batteries above 2 kWh and electric vehicle batteries. Since 18 August 2024, Article 14 has required the battery management system to hold data on state of health and expected lifetime — exactly the data that makes a resale evidenced rather than asserted. How to read and record it is covered in State of health: what the percentage does not say.

What a business should do now

1. Identity before content. Every passport hangs on an unambiguous identifier. Whoever normalises OE numbers today and keeps vehicles by VIN already has the bracket; whoever keeps free text migrates twice later.
2. Separate item from type. A part type has an OE number, an individual item has a serial number. Passport data hangs on both — in stock the two levels must stay apart.
3. Store evidence, not verdicts. Inspection record, measured value, date, inspector. Any required indicator can later be built from evidence; no evidence can be built from an indicator.
4. Record origin as you go. Donor vehicle, removal date, processing steps. That is the data which cannot be reconstructed afterwards.
5. No speculative DPP field. While the mandatory content for your product group is undecided, an empty passport field is an invitation to fill it with assumptions.

Where tapinomahub fits into that record

The platform issues no product passport and is not the right place to. It supplies the building blocks that later travel into any passport: GET /parts/oe/normalize and GET /parts/oe/{oeNumber} turn a typed string into a confirmed part identity with name, vehicle assignment and replacement chain, GET /vin/{vin}/vehicle supplies origin with type, production period and type keys, POST /vision/part/quality a condition grade with individual criteria, and POST /vision/identifiers/redact keeps instance identifiers out of public images for as long as they do not belong in the passport.

Limits

• The frame stands, the content does not. Which fields a product group must fill arrives in delegated acts. A mandatory field built today may carry the wrong name tomorrow.
• A passport is not a selling point. It is an obligation and a data structure, not an assurance of quality.
• Access rights are part of the job. Not every entry is public; serial numbers and diagnostic data need an access level before they are captured.
• National implementation comes on top. The German side of end-of-life treatment is described in The German end-of-life vehicle ordinance: duties for owners and dismantlers and stays decisive for daily operations.

The honest summary: for batteries the clock is running, for vehicles a separate regime applies with a staged start, and for everything else the product group decides. Whoever keeps identity, origin and inspection evidence clean until then is prepared — whatever the fields end up being called.

This article is general professional guidance and does not replace legal advice. The applicable statute and the conditions imposed by your competent authority prevail.