How long must a digital product passport remain available?

What you concretely must do

What is expected of you

The passport remains accessible as long as the obligation applies

Article 10 of the ESPR (Regulation (EU) 2024/1781) establishes that the digital product passport must remain available, but the precise duration for mattresses is not specified in the regulation itself. The ESPR is a framework regulation: the concrete requirements per product group come in a delegated act, and only then will it be specified how long a mattress passport must remain accessible after sale. For mattress manufacturers and importers, this means above all that account must be taken now of the fact that the passport is not something you create and can then forget about — it is an obligation that continues after sale, for a period that is not yet determined but is likely to be specified in the delegated act for mattresses.

For a company with 10 to 100 employees, this means that the hosting choice is not something for the short term. A system that stops after a few years or whose continuity is not guaranteed does not fit with an obligation that can run for years per product.

The data must remain current and accessible, not only "stored somewhere"

Remaining available means more than just "not going offline". Article 10 sets requirements for accessibility of the data for the entire period that the passport must exist. For a mattress manufacturer, this means that the QR code on the product, or the label on which it is affixed, must remain intact and scannable — and that the underlying data must remain accessible, even if there are changes to the product, the supplier or the company's own operations in the meantime. What to do if that label is damaged anyway is described on the page about what to do if the QR code is damaged.

The passport is also registered, separately from where it is hosted

Article 13 of the ESPR regulates the register of digital product passports: a central place where (metadata of) passports are recorded. That registration runs parallel to the requirement that the passport itself remains accessible. For a company, this means that two things must be kept in mind: the passport that must remain accessible via the QR code, and the registration that exists alongside it. What exactly must be entered in that register and how that relates to the passport itself is explained on the page about the European register.

The obligation survives changes in the company

Because the retention period (once determined) is likely to be longer than some business changes, it is conceivable that a mattress passport must still be accessible while the company that created it no longer exists in its current form — through acquisition, closure, or change of hosting provider. What happens to it when a company stops is described on the page about what happens to the product passport if your company stops.

Where things go wrong in practice

The hosting provider is chosen on price, not on continuity. A cheap solution that stops after a few years or changes ownership is a risk if the underlying obligation runs for years. Companies often only discover this when the first complaint comes in about a non-working QR code.

No backup is kept of the source data. If a platform stops or the connection with the ERP system is lost, the data is sometimes not found anywhere else. What to consider in this regard is on the page about backups of passport data.

The QR code is only stuck on existing stock afterwards, without the link to the correct passport being properly recorded. For mattresses that were already produced before the obligation came into force, this is a realistic scenario — see the explanation about sticking QR codes on existing stock. If it is not clearly recorded which code belongs to which product, the availability of the passport in practice cannot be guaranteed.

It is assumed that one passport is sufficient, whereas a mattress can consist of multiple components with their own requirements. If a mattress has, for example, a separate cover or filling with its own passport requirement, it is unclear which passport has which lifespan. How they work together is described on the page about multiple passports for a product.

In a takeover or merger, it is forgotten that the passports under the old company name continue to exist. The buyer of the company often only thinks about inventory and customer base, not about the hundreds or thousands of digital passports that have to continue running somewhere.

What you can record

• An overview of which hosting party manages which passport, including contract duration and notice periods, so that continuity does not depend on the memory of one employee.
• A backup agreement for the source data, separate from the platform on which the passport runs — see the page about backups of passport data.
• A link between the passport and your own inventory or ERP system, so that data is not kept twice and remains more easily up to date; more about this on the page about linking to your own system.
• A documented procedure for what happens to the passports in the event of business closure, takeover or merger.
• A list of which products are equipped with which unique identification code, so that in case of problems with a QR code, it is quickly clear which passport belongs to it — see the page about unique identification codes.
• Documentation of when and how each passport was created, with which data from manufacturer or importer, so that in a later inspection it is clear that the passport is not there by chance but has been deliberately compiled and maintained.