The DPP Registry and Resolver Explained

Two distinct pieces of infrastructure sit behind a passport, and they are routinely conflated. One is a central registry operated at EU level. The other is a resolver operated by or for the economic operator. They serve different audiences and answer different questions.

Getting the distinction right matters because it determines what you build, what you register, and what happens when somebody scans a product on a loading dock in Rotterdam.

What the registry is for

Regulation (EU) 2024/1781 provides for a central registry storing identifiers and a defined set of data about passports placed on the market. Its users are customs authorities and market surveillance bodies, not consumers.

Think of it as an index of existence and accountability: which passports exist, for which products, associated with which economic operator. It exists so that a customs officer at a border can check whether an in-scope product arriving in a container has a passport at all, without needing to visit a manufacturer’s website.

What a resolver actually decides

A resolver receives a request for an identifier and decides what to return. That decision has three inputs, and the fact that there are three is the whole point.

Because the resolver is a routing layer rather than a store, it can point at content held anywhere — your own systems, a supplier’s, a certification body’s. What it owns is the decision, not the data.

Why one universal response fails

The most common early design serves a single page to every scan. It is simple, it demonstrates well, and it breaks on contact with real users.

A consumer scanning a jacket wants care and repair information in their language. A recycler scanning the same jacket wants fibre composition and whether the coating contains anything hazardous. A market surveillance officer wants the evidence chain behind every claim. Serving all three the same page means either exposing treatment data to everyone or withholding it from the recycler who needs it to work safely.

The relationship between the two

The clean mental model is that the registry answers whether a passport exists and who is accountable, while the resolver answers what the passport says to you specifically.

• Registry — central, EU-operated, used by customs and market surveillance, holds identifiers and operator data.
• Resolver — operated by or for the economic operator, used by everyone who scans, holds routing rules rather than content.
• Carrier — the physical marking that produces the identifier both of them key on.
• Passport content — wherever the operator keeps it, reachable through the resolver rather than through the registry.

Design consequences worth planning for

Three implications follow directly and are cheaper to design in than to retrofit.

The first is that the identifier must be stable for the life of the product and beyond it. It appears in the registry, on the carrier and in every resolver rule, so changing it means reissuing physical goods already in the field.

The second is that the resolver has to keep working when your website does not. A passport that fails because a marketing site was redeployed is a compliance failure caused by an unrelated team, which argues for keeping resolution independent of the corporate web estate.

The third is longevity. A passport is expected to remain reachable for the product’s service life, which for construction products or industrial batteries can exceed a decade. Any resolver design that depends on a proprietary format or a single vendor’s continued existence is taking a risk the regulation explicitly anticipates.