what happens to my product passports if the hosting party stops operating
The responsibility lies with the manufacturer, not with the hosting party
The obligation to keep passport data available rests with the manufacturer or importer who places the product on the market, not with the company that provides the hosting. A hosting party such as matrapas.eu carries out that obligation on assignment, but the ultimate responsibility does not shift with it. If a hosting party ceases operations, that does not mean the obligation to keep the passport available disappears — it remains with the party that placed the product on the market. What does change is who provides the technology behind it at that point in time.
For whom this applies, and for which situation it does not
This topic concerns the continuity of the data itself: does the information behind the QR code remain accessible even if something changes about the service provider that hosts the data. That is a different question from what happens if the manufacturing or importing company itself ceases operations — that situation is addressed in what happens to the product passport if the company behind the product ceases operations. Nor is this about how long a passport must remain available in total; that is covered in the retention period of the product passport. This page is limited to the practical question of what happens if the technical supplier of the passport — the hosting party — drops out, while the company behind the product continues to exist.
What is already established, and what is not
When the obligation for a digital product passport for mattresses takes effect precisely is not yet fixed: the ESPR regulation itself is in force, but the delegated act that makes this concrete for mattresses is expected within the 2025-2030 work plan, and a date will be stated here as soon as that act is published. What is already established is the principle from the ESPR itself: Article 10 sets requirements for the accessibility and durability of the digital product passport, and Article 13 provides for passports to be entered in a central European register. That register exists independently of the party hosting the underlying data — it is a reference system, not the storage facility for all content itself. What the register will maintain exactly and what must be included in it is described in the European product passport register.
How this is approached in practice
For a manufacturer or importer working with a hosting party, the first step is to know what has been contractually agreed for the event that the hosting party ceases operations: is a transfer of data documented, and to whom will that data be transferred. Next, it is important to know in what format the data will be transferred — a dataset that is only readable within one supplier's system is less valuable than a dataset that can be transferred to another party. This connects to the question of whether a passport is linked to an external system: those managing their product data in an ERP or inventory system, as described in linking the product passport to your own system, has its own source of data that does not disappear if the hosting party ceases operations — the link ensures that the underlying information is retained elsewhere even if the presentation runs through a different party.
Subsequently, it is relevant what happens to the QR code and the link behind it. If a hosting party ceases operations and the data moves to another location, the existing QR code on the product must continue to point to valid information — not to a dead link. In practice, this means the underlying URL is often retained (for example via a redirect to the new system) so that a new code does not need to be applied to each product. Those wondering how that link between physical code and digital data works exactly will find background in how the QR code ends up on a mattress. When switching between hosting parties, the key is to ensure that the product's identification code and the associated data link remain intact, even as the underlying infrastructure changes.
Finally, it is practical to ask in advance how a hosting party handles its own business termination: is there a procedure that comes into effect, is a manufacturer warned in advance, and is there a period in which data can still be retrieved before a system is phased out. Such agreements determine in practice how much risk lies with the failure of one specific supplier.
Where this is based on: Article 10 and Article 13 of the ESPR
Article 10 of the ESPR (Regulation (EU) 2024/1781) sets the requirements for the digital product passport, including the accessibility of data for the period it must remain available — a requirement that attaches to the passport itself, not to any single specific technical provider. Article 13 of the same regulation governs the register of digital product passports, in which passports are entered so that they are findable and verifiable, regardless of which party provides the underlying hosting. Together, these articles place the responsibility for the continued availability of the data with the party that creates the passport, and not with any arbitrary link in its technical implementation.
Anyone currently choosing or considering a hosting party can use this as a checklist: ask about the data export options, about what happens to the QR link in the event of a potential switch, and about the procedure in the event of business termination of the hosting party itself — and record those agreements before the first passports leave the door.
Where this is based on
- Regulation (EU) 2024/1781 (ESPR), Article 10 (requirements for the digital product passport)
- Regulation (EU) 2024/1781 (ESPR), Article 13 (register of digital product passports)
The regulation itself is on EUR-Lex. We provide references per statement; you do not have to take our word for it.
What you concretely must do
What is expected of you
Ensuring the passport remains available, even if the service provider fails
Article 10 of the ESPR (Regulation (EU) 2024/1781) sets requirements for the digital product passport, including that data must remain accessible to the parties entitled to it — think of the consumer, the supervisory authority and market participants further down the chain. Whoever has the passport hosted by an external party remains responsible for this. For a company with 10 to 100 employees, this means in practice that the choice of a hosting party is not only a cost consideration, but also a question of continuity: what happens to the data if that party goes bankrupt, is taken over, or simply decides to stop providing this service. This is not a question that should be answered afterwards, but something that should be part of the agreement with the hosting party in advance.
Keeping the passport findable through the register
Article 13 of the ESPR (Regulation (EU) 2024/1781) governs the register of digital product passports, in which the basic data and the location of each passport are entered. That register is intended as a backstop: even if an individual website or hosting service changes address or provider, the passport must remain findable there. For a manufacturer or importer, this means that the registration in the register must be kept up to date when there is a change in hosting — a move to another provider must not result in the passport becoming unfindable to the outside world. Read more about what exactly must be entered there at what the register of digital product passports is and what you enter in it.
Knowing what happens to the data when the business terminates
A related situation is one in which not the hosting party, but your own company stops — through sale, merger or bankruptcy. This is a slightly different issue than the failure of a service provider, but the core is comparable: the data must remain available to those entitled to it, regardless of what happens to the original party. This subject is dealt with separately in what happens to the product passport if your company stops, because the question "who remains accountable" then takes on a different meaning than when switching hosting provider.
Where things go wrong in practice
A mattress manufacturer opts for a cheap hosting provider without asking what happens if that provider goes bankrupt. A year later, the service disappears without notice, and the QR codes on thousands of already sold mattresses lead nowhere.
An importer has the product passport built by an IT freelancer who stores the data on their own servers. When the collaboration ends, it turns out that nobody has access to an export file of the underlying data — only the freelancer had the password.
A company switches hosting provider because the old one is winding down the service, but forgets to notify the register of the new location. The QR code on the product still works, but the location listed in the register points to a dead link.
A bed specialist retailer assumes that the manufacturer "will have arranged something" for the long term, without ever inquiring or contractually establishing who is responsible for what if the manufacturer's hosting provider stops.
A manufacturer never tests what happens if the hosting provider terminates the service, and discovers too late that the contractual terms say nothing about data transfer upon termination — resulting in negotiations from a weak position, under time pressure.
What you can record
- The agreement with the hosting provider, with an explicit provision on what happens when the service is terminated: transfer of all underlying data, in which format, and within which timeframe.
- An export function for the raw passport data, independent of the display on the hosting provider's website — so that the data remains usable even without that specific service.
- A current registration in the register of digital product passports, with the correct location, which is updated whenever anything changes in the hosting. See what the register of digital product passports is and what you enter in it for its contents.
- Arrangements for the connection with your own systems, so that the passport data does not exist exclusively with the hosting provider but is also traceable from your own ERP or inventory system — more on this at linking the product passport to your own system.
- A list of the unique identification codes per product, maintained independently of the hosting provider, so that a possible switch to another provider does not result in loss of the link between product and passport. See how to give each product a unique identification code.
- A contact person or procedure for when the QR code or label no longer works, including what to do if the location behind the code changes due to a switch to another hosting provider — see also what to do if the QR code of the mattress is damaged.
- A retention period agreement that aligns with the period in which the passport must remain available, so that the continuity of hosting is geared to it — background on this at how long a product passport must remain available.
This is not legal advice. This page provides general information about the legislation this platform concerns. We do not know your situation. If you are in doubt about your own case, consult a lawyer or the competent supervisory authority.
Written with AI based on the sources above, reviewed by a human on 2026-09-05. Is something not correct? Let us know — corrections are given priority.