How long must a digital product passport remain available?

What you must concretely do

What is expected of you

Availability during the product's lifespan

Article 10 of the ESPR (Regulation (EU) 2024/1781) governs the requirements for the digital product passport, and it follows from this that the data must remain available as long as there is a reason for it — at least as long as the product is in use, and in practice often for some time afterwards as well, for example for recycling or liability questions. For aluminium semi-finished products this means something different than for a smartphone: a profile that is incorporated into a facade or a construction can last for decades. The passport must still be there when someone demolishes the building and wants to know what material is in it. For a company with 10 to 100 employees, this means above all that the availability of the passport is not a one-time action, but an obligation that continues long after the sale.

Who remains responsible

The obligation to maintain the passport lies with the party that created or had the passport created — usually the manufacturer or importer. This also applies if the aluminium reaches the end user through intermediaries or processors. In practical terms, this means that a company must not only arrange something at the moment of production, but must also have a way to continue bearing that responsibility — or to transfer it — if the company itself changes ownership, merges, or divests activities. What exactly happens if a company ceases to exist is a question that deserves separate attention; see what happens to the digital product passport if my company stops operating.

Findability via the register

Article 13 of the ESPR describes the register of digital product passports, in which (metadata of) passports are recorded so that supervisory authorities and other parties can retrieve them. Availability of the passport itself is therefore inseparable from the question of whether it remains findable via that register. For a company, this means that registration in the register is not something you do once and then forget — if the passport moves to a different host, or if the link changes, that must also be correct in the register. For more on what must be included in that register, see what is the register of digital product passports and what must I enter in it.

Accessibility, even without an active intermediary

Availability does not only mean that the data exists somewhere, but that someone with a QR code or identification code can actually access it. This places demands on the technology behind the passport: a link that no longer works after a server migration is in practice just as much of a problem as data that has been deleted. For a company of this size, this is usually not a matter for lawyers but for IT decisions: who hosts the passport, how robust is that hosting, and what happens if the platform you are working with itself changes or stops.

Where things go wrong in practice

A first situation that often occurs: a company hosts the passport itself on its own server, and years later — when nobody is actively looking at it anymore — a domain name expires or a system is replaced without the old links being carried over. The QR code on the aluminium then points to nothing.

A second situation: a company is taken over or merged into another company, and nobody has previously agreed on who will maintain the existing passports. The buyer of the aluminium then has a product with a passport that factually exists, but of which nobody is the owner anymore.

A third situation arises with long product lifespan: a profile that has been in a building for twenty years must be demolished and someone scans the QR code. If the platform on which the passport was stored has since ceased operations, or the host has not retained the data long enough, there is nothing to be found — even though the product is still there.

A fourth situation: the passport is adjusted once after publication (for example because there was an error in the material composition), but the old version is simply overwritten without it being clear which version applied at which time. In case of questions about liability, that is a difficult point. How to make changes without loss of history is described at how do I update data in a product passport that is already published.

A fifth situation: a company assumes that it is sufficient if the passport is "on the internet", without considering whether someone at a scrapyard without reception can also access it. That touches on the question that is addressed separately at must someone also be able to view the product passport without internet connection.

What you can document now

• An agreement with the hosting party (or with alupas.eu) about the duration for which the passport remains available, and what happens if that period expires or if the platform changes ownership.
• An internal instruction on who within the company is responsible for maintaining published passports, also after a reorganisation or takeover.
• An overview of which products have a longer service life than average (for example profiles in building constructions), so that this is taken into account when selecting a hosting party.
• A documented procedure for what happens to existing passports in case of sale, merger or closure of the company — with a reference to the agreements on this matter described elsewhere.
• A check that the identification code of each product is consistently recorded, so that a passport can be linked to the correct product even after years; see also how do I assign a unique identification code to each product.
• A note of the date and version with every modification of a published passport, so that a history remains visible instead of only the latest version.
• Documentation on how the QR code on the product itself is resistant to wear or damage over the service life of the aluminium, which touches on the question addressed at what happens if the QR code on my aluminium becomes illegible.