Where your passport data actually lives, now the registry is running

The short answer

The European Commission announced the launch of the Digital Product Passport Registry on 20 July 2026, together with a testing environment. The rules it runs on are in Commission Implementing Regulation (EU) 2026/1778, adopted on 16 July 2026 and in force from 6 August 2026.

What went live is an index. The Commission's own description is that the registry "acts as the indexing service for all Digital Product Passports of products placed on the EU market", holding unique identifiers, registration data and high level metadata rather than the full detailed product information. The launch announcement puts the same point the other way round: product data is stored in a decentralised manner, and what an operator registers is the identifier and the metadata that go with it.

So the answer to the question most people are actually asking is no. The Commission does not now hold your product data, your supplier documents or your test reports. It holds a record that a passport exists, who registered it, what it is about and where a backup copy can be found.

That is the smaller half of what changed. The larger half is that a set of arguments about how this system works are no longer open. The instrument names the parties, sets the verification, defines the vocabulary layer and states in its own recitals what a passing automated check does not establish. Those are the parts worth your time.

The two dates, and why published explanations disagree

Several published explanations of the registry print 19 July 2026 as the day it opened. The Commission's own announcement says 20 July 2026.

Both dates are real and they belong to different things. The framework behind the registry, the Ecodesign for Sustainable Products Regulation, set the Commission a date by which it had to have the registry set up, and that date is 19 July 2026. It is a duty on the Commission. It is not a date on which anything happened to a business, and it is not the launch. The launch is the Commission's announcement the following day.

The distinction is worth holding onto because it is the shape of almost every date error in this subject. A date in an instrument is usually a duty on somebody, and the somebody is frequently not you. Which dates in this system attach to a business, and which do not, is kept row by row on the status record rather than asserted here.

What is registered, provision by provision

Registration happens through a secure user interface or through an API, and the instrument treats the two as equivalent routes rather than as a basic option and an advanced one. Article 8(6) offers both. Article 8(10) says the registration identifier comes back through whichever of the two you used.

What the registry stores about a registration, under Article 8(8) and 8(9), is a short list:

• a unique persistent registration identifier, generated by the registry and issued back to the registrant
• the unique identifiers, where relevant
• the commodity code for the product, where relevant
• a reference to the digital product passport service provider, where relevant
• registrant information, including the date and time of registration and the integrity of the passport, held as evidence of the registration event

Registration happens at model, batch or item level according to whichever act governs the product. Where a product falls under two sets of rules asking for different levels, Article 8(3) resolves it in one direction: the passport is registered at the most granular level required. Article 8(4) and 8(5) then require an item level record to link its batch and model identifiers where those designs exist, and a batch record to link its model. The registry assumes a ladder rather than a choice, which is a different thing from settling how many passports a range actually needs.

Two retention periods sit underneath all of this. Article 9(4) makes a proof of registration available for 90 calendar days from the date it is generated, and it can be generated again. Article 10(3) deletes registration data automatically 10 years after registration where Union law sets no specific availability period, and aligns the retention with that period where it does. Neither is a deadline for anybody. Both are properties of the instrument, and both are worth knowing before a supplier describes either as permanent.

What stays with you, and where the copies are

The instrument and the framework together put your product information in three places, and only one of them belongs to the Commission.

Two consequences follow that are easy to miss.

The first is that the pointer is load bearing. The registry stores a reference to the service provider, and Article 8(7)(e) has the Commission confirm that the backup link is valid at the point of registration. That is where the instrument places the check, and we did not find a provision requiring it to be repeated later. What keeps the thing at the other end reachable years afterwards is a procurement question rather than a registry function, and changing that provider is a supplier decision rather than a transfer of who answers for the record.

The second is that responsibility does not move with the hosting. Article 19(1) and 19(2) put accuracy and completeness on the verified economic operator at the time of registration and require the information to be kept accurate, complete and up to date at all times. Article 19(5) makes that operator the controller of the data it submits. Article 19(4) allows a third party to perform registration actions on your behalf and says in the same sentence that you remain fully responsible.

Read Article 19(4) closely, because it does something slightly surprising. The verification route it sends that third party down is Article 5, which is the process written for value chain actors, rather than Article 4, which is the process for economic operators. A vendor registering on your behalf is being verified as a participant in your value chain, not as a stand-in for you. Whether you can get an account at all, and what a legal entity has to buy in order to do so, is the verified economic operator question and it is prior to everything on this page.

The semantic repository, and what Article 12 actually requires of it

Article 12 sets up something that gets a sentence in most coverage and deserves more. The Commission establishes and maintains a semantic repository as the authoritative machine readable source for the data models, semantic definitions and vocabularies that apply to passports across every product group. Article 12(7) makes access to it, and to its APIs, free of charge. Article 12(5) requires a search service. Article 12(6) requires publicly documented APIs in common data formats.

Article 12(2) sets out what it has to contain, and one limb of it is more interesting than the rest. Alongside the data models, the metadata and the multilingual labels, the repository must carry:

That is a specification for linking a value to the thing that supports it, and for linking one passport to another, at the level of shared vocabulary rather than at the level of one vendor's schema. Anybody who has tried to reconcile a certificate against a field will recognise what is being described. It is the difference between a passport that asserts a number and a passport where the number can be followed back to something. Whether the delegated acts eventually make use of that limb is not settled, and the estate's method for handling a question in that state is set out in how we know.

For a business the practical reading of Article 12 is narrow and useful. The vocabulary your fields will have to speak is published, free, searchable and reachable by machine. It is not a place your data goes. It is a place the meanings live. Whether your existing product data can speak it, and what happens where a product group's catalogue has not been defined yet, is worked through at what the EU's published definitions ask of your product data.

The people the instrument names

The definition that repays the most attention is in Article 2, and it is not about products at all:

Article 5 gives those actors their own verification route, on the same terms as economic operators: an electronic identification means or a qualified electronic signature for a sole trader, a qualified electronic seal or a qualified attestation of attributes for a legal entity, with verified status running until the underlying means expires and in no case beyond three years. Article 5(3) then limits access to verified actors and says they may perform actions in the registry "where specified in the relevant Union law". Article 20 gives them responsibilities of their own for what they submit.

Article 6a completes the picture by allowing a registered passport to be transferred to another verified economic operator or to a verified value chain actor taking over the obligations attached to it, from the date indicated for the transfer. Recital 10 explains what that is for: an actor that did not pass verification, and organisational changes such as a merger, a split, a sale of part of a business or a cessation of activities.

The system now has a mechanism for a passport to change hands along with the duty attached to it, and it has an identity layer for the people who repair and recycle. Whether any of that produces an outcome is a separate question with a separate answer, and the continuation block below points at it.

What a passing check means, and the regulation says it itself

Article 8(7) has the Commission read the submitted content and automatically confirm five things: semantic conformity against the applicable act, coherence of mandatory data against the passport values where relevant, conformity with the required granularity level, validity of the commodity code within the permitted range where relevant and validity of the backup link hosted by a service provider where relevant.

Recital 16 then says, in the Commission's own words, what those checks are not:

The framework says the same thing from a different direction. Under the Ecodesign framework the communication of a registration identifier is not to be deemed proof of compliance.

So a registered passport means a submission was well formed, populated and correctly levelled, and that the commodity code and the backup link were in range. It means nothing about the fibre content being right, nothing about a claim being substantiated and nothing about the product complying with anything. That distinction becomes commercially sharp the moment a buyer asks for evidence rather than a record.

The plain answers

What else the registry keeps

One thing the architecture above understates. Alongside the record about your product, the registry runs a log system under Article 14 that records access, modifications, administrative actions and data exchanges on three separate retention clocks, and Article 18 stores personal data about the named users behind them. Article 14(4) makes those logs available to national and customs authorities in the case of suspected incidents and for audits and random checks. What the registry records about you sets that out, because it is a second record with a different reader.

What is still open

Three things are genuinely unresolved, and it is worth separating them from things that merely have not been read.

Who sees what. The instrument builds the access machinery. Member States appoint a designated national administrator as the single contact point for managing access rights under Article 7, and that administrator can delegate to national authorities. The registry supports customs authorities verifying electronically that an imported product has a valid registered passport and a commodity code, and market surveillance authorities getting access to registered passports for specific purposes. That customs function is written in the framework and only half switched on, which is set out at what actually happens to a passport at the EU border. What the instrument does not do is settle the tiering of access to passport content itself, which the framework leaves to further acts. When Member States have to have appointed their administrator is a date on a duty, so it sits on the status record rather than here.

Correction. Article 10(1) requires any change to registration data, including creation, modification and deletion, to be logged and reflected in the status of the registration. That establishes that changes happen and are traced. It does not lay down a procedure for correcting or withdrawing a registration, and we did not find one in the enacting terms. Nor did we find an enumerated vocabulary of registration statuses, although Article 1(2)(g) lists statuses as one of the matters the arrangements cover. Who owns the problem when a published value turns out to be wrong is answered separately, and the answer does not come from this instrument.

Standards. The Commission's announcement records that eight harmonised standards underpinning the interoperability of the system were developed with CEN and CENELEC and that six of the eight are available and published. Published is not the same as cited in the Official Journal, and only a cited reference carries a presumption of conformity.

What to do with this

Very little immediately, and that is the honest answer for most readers. The registry creates no obligation of its own. The obligations that will eventually route through it belong to product acts, and the first hard deadline named in the Commission's launch announcement belongs to certain large batteries rather than to anything else.

Four things are worth doing, and none of them is a purchase.

1. Establish where your passport data would actually be hosted, and by whom, before anybody discusses registration. The registry stores a pointer to it. It does not store it.
2. Read Article 19 before signing anything with a vendor who offers to handle registration. The sentence that matters is the one saying you remain fully responsible.
3. Look at the semantic repository against your existing product data now, while nothing depends on it. It is free, it is documented and the question of whether your fields map cleanly onto published definitions is answerable today and cheaper to answer today.
4. Keep the distinction between a registered passport and a compliant product in the vocabulary your own team uses. The regulator declined to blur it. There is no reason for anybody downstream of the regulator to do it for them.

Sources

• Commission Implementing Regulation (EU) 2026/1778 establishing the Digital Product Passport registry
  Relevant provisions reviewed

  Carries almost every proposition on this page. Read at article and recital level in August 2026: Articles 2, 3, 4, 5, 6, 6a, 7, 8, 9, 10, 12, 19, 20, 21 and recitals 10 and 16. Article numbers are cited because the enacting terms were read, not inferred from a summary.

  View official source

• European Commission announcement that the Digital Product Passport registry is operational
  Reviewed in full

  The launch date, the decentralised storage statement, the semantic repository being free and the standards count. Read at its own address.

• Digital Product Passport Registry
  Reviewed in full

  The indexing service description, what is stored against what is not and the customs and market surveillance functions. Read at its own address.

  View official source

• Ecodesign for Sustainable Products Regulation (EU) 2024/1781, consolidated text
  Relevant provisions reviewed

  The framework the registry serves. Used for four propositions: the set-up date being a duty on the Commission, the backup copy requirement, the availability requirement surviving insolvency and the registration identifier not being proof of compliance.

  View official source