can I use my existing product database for the product passport

Yes, as a source — but not as the passport itself

An existing product database can usually serve as a source for the data that ends up in a digital product passport, but the database itself is not a product passport. The product passport is a specific data format that is linked to a unique carrier (usually a QR code) per product or product model, with fixed requirements for structure, accessibility and coupling with other systems such as the EU registry. The information that is already in an ERP system, PIM system or Excel list — materials, dimensions, article numbers, supplier, composition — is exactly the kind of data that will have to go into a passport later. That data does not therefore need to be collected again, but it does need to be transferred to the correct format and linked to the correct carrier.

Which data this works for, and which it does not

Data that is fixed per product or product model — such as material composition, origin, dimensions, warranty information or maintenance instructions — lend themselves well to reuse from an existing database. This data is part of what Article 9 of the ESPR (Regulation (EU) 2024/1781) describes as the core of the digital product passport: information that must be accessible per product via a data carrier. What an existing database often does not provide is the technical structure prescribed by Article 10 of the ESPR: a unique product identification number, a link with the registry, and a format that can be read uniformly by market participants, competent authorities and consumers. An internal database is usually designed for the company's own operations — inventory management, order processing — and not for external, standardised reading as required by Article 11 of the ESPR for the technical functioning of the passport. That is the difference between "the data is already there" and "the passport is already there": the first is often true, the second rarely is.

When this becomes relevant

The question of whether an existing database is suitable becomes concrete only once the obligation for furniture comes into effect, and that moment is not yet fixed. As also explained on the page on when the product passport becomes mandatory for furniture the delegated act for furniture has not yet been published; it is only then that it will determine exactly which data is mandatory and what format it should have. Until then, there is no legal obligation to maintain a passport, but that does not mean that waiting is the only option. What is already established until then is the general structure of the ESPR itself — Articles 9, 10 and 11 — which sets out the framework within which the delegated act for furniture will be developed.

How to approach this in practice

The first step is to check which data already exists and where: material composition, origin, dimensions, and any existing certificates or test reports. Much of that information is often scattered across different systems — an ERP for inventory, a PIM for product information, loose documents for certificates. A second step is to assess whether that data is consistent and up-to-date at product model level, because the passport requires unambiguous information per product, not per order or per batch. A third step is to check what data is missing; these are often precisely the data specifically requested for the passport, such as repair or disassembly information, which is usually not standard in a sales or inventory system. For anyone who wants to get started with this now, even without the exact requirements being fixed, the page on describes what you can do now while the rules are not yet final a number of preparatory steps that can be taken without risk. For an overview of the approach in sequence, from data collection to placing the data carrier, the page on the digital product passport step by step a logical follow-up.

A key point with collections that have many variants — colours, upholstery, leg types — is that an existing database often manages those variants as separate SKUs without a shared foundation. The passport specifically calls for a clear link between what is shared within a collection and what differs per variant, something that receives dedicated attention on the page about creating passports for a collection with many colour and fabric variants.

The legal basis: Articles 9, 10 and 11 of the ESPR

Article 9 of the ESPR (Regulation (EU) 2024/1781) establishes that a product with a digital passport must be provided with a data carrier that makes information about that product accessible. Article 10 describes the substantive requirements that such information must meet, including the link to a unique identification number and the registration register. Article 11 addresses technical operation: how the passport must be readable and exchangeable between different parties in the supply chain. Together, these articles establish that a product passport is not merely a database of product information, but a specifically structured layer on top of it — built on data that often already exists, but supplemented and structured according to requirements that will be established per product group.

Anyone who now wishes to check whether their own furniture will be subject to this obligation can do so on the page about whether the digital product passport applies to specific furniture, and anyone who first wants to understand what a product passport substantively is will find that on the page about what a digital product passport for furniture is. The most practical step now is: to inventory and organise existing product data per product model, so that supplementation later is limited to what is truly still missing.