DPP Registry: How to Register Your Battery Passports, Step by Step

Last updated: November 1, 2026

On October 30, 2026, the European Commission quietly published the documents that turn the EU DPP Registry from a promise into a process: the registration API, the sign-in rules for automated systems, the rules for protecting restricted data, and, for the first time, the official data model for battery passports. If you sell EV, light means of transport (LMT) or industrial batteries in the EU, these are the instructions you'll follow before February 18, 2027.

We read all of them, built against them, and ran a live battery passport through the Commission's own validation files. This guide turns that work into a plain, step-by-step process. It covers what the Registry is, who has to register, how to enroll your company, what a QSeal is and how to get one, what your battery passport must contain at each access level, how submission works, and the mistakes that will make the Registry reject your batteries.

If you need the wider picture first, start with our EU battery passport compliance guide, which covers scope, data and deadlines. For the Registry's launch in July and what it means beyond batteries, see the DPP Registry is live. This article is the practical part: how to actually get your battery passports registered.

What Changed on October 30, 2026

The Commission's DPP resources page now holds seven documents. Translated into what each one means for a brand:

Until now, a brand preparing a battery passport had the regulation's annexes, the industry's BatteryPass data model and a lot of educated guessing. Now the Registry says exactly what it will check. That's the real change: the target stopped moving.

The DPP Registry in One Minute

The DPP Registry is an index, not a database of passports. Implementing Regulation (EU) 2026/1778, which governs it, and every guide published since keep the two apart.

What the Registry stores. For each battery: its unique product identifier, which is a web address, its granularity (for batteries, one passport per item), and optionally a batch identifier and a model identifier. Each registration sits under a product group (BATTERIES) and a sub-group: EV for electric vehicle batteries, IND for industrial batteries and LMT for light means of transport batteries such as e-bike and e-scooter packs. In return, the Registry gives each passport its own registry identifier.

What the Registry doesn't store. The passport itself. Your battery's composition, carbon footprint, performance and history stay on your passport server, or your service provider's. The API guide is explicit: when you register, the Registry reads the passport at its address and validates it against the rules, then "does not persist the fetched DPP payload content."

Why that matters. Two consequences follow, and both shape everything below:

1. The passport must be online and correct before you register. The Registry fetches it at registration time. If the address doesn't answer, the battery is rejected with UPI_NOT_RESOLVABLE. If the content doesn't match the data model, it's rejected as non-compliant.
2. Hosting is the hard part. Registering is a short message. Hosting a passport that answers the Registry in the right format, shows the right data to the right reader and stays online for the battery's whole life is the real work.

Who Has to Register

The economic operator who places the battery on the EU market registers its passport. For most batteries that's the manufacturer. For batteries made outside the EU, it's the importer, or the manufacturer if it enrolls itself. The Commission's helpdesk confirmed to us in October that the entity placing the product on the EU market carries the registration and the obligations that come with it.

Manufacturers outside the EU can enroll themselves, provided they have a qualified electronic seal from a trust service provider on an EU trusted list. An EORI number on its own doesn't replace the seal.

Battery packs inside a product. If you sell e-bikes, you place the bike on the market, and the LMT battery in it is a battery placed on the market too. Whoever is the economic operator for that battery handles its passport, and when you source packs from a supplier, your contract should say which of you that is.

Repurposed and remanufactured batteries. A battery prepared for repurposing or remanufacturing gets a new passport, linked to the original, under the operator who places it back on the market (Article 77 of the Battery Regulation).

Service providers. The economic operator stays legally responsible, but the Registry's design leaves room for a provider to do the work: automated sign-in through Service Accounts, and a self-hosting guide that describes one provider hosting passports for several economic operators on the same domain. We cover both in steps 4 and 5. If you're choosing a provider, our DPP service provider guide lists what to ask.

Before You Start: What You Need

Most of the delay in registering won't come from the Registry. It will come from the things you need before you can use it. Check these first:

If you only do one thing this month, order the seal. Everything else can run in parallel, but nothing can be registered without a verified organization.

Step 1: Enroll Your Organization

Enrollment is how the Registry learns who you are. It happens once per company, separately in each environment.

1. Create EU Login accounts. Every person who will work in the Registry needs an EU Login account. The acceptance (test) environment at registry.acc.product-passport.ec.europa.eu uses its own accounts, separate from production at registry.product-passport.ec.europa.eu.

2. Fill in the enrollment form. You enter your organization's legal details. They must match the seal certificate you'll sign with: the organization name, the country, and the organization identifier the certificate carries. A mismatch is the most common reason for a rejected enrollment.

3. Download and seal the declaration. The Registry generates a declaration as a PDF. You sign it with your qualified electronic seal (or, for a sole trader, a qualified electronic signature) using a PAdES signature (baseline B, T, LT or LTA). The key must sit on a qualified signature device or with a remote signing service. A plain software certificate file (.p12) is rejected.

4. Upload it and wait for verification. The Registry checks the seal and the details, then marks your organization as verified. Until then, every registration attempt is refused, whether it comes from the web interface or the API.

5. Do it again in the test environment. The helpdesk confirmed that the acceptance environment needs the same real qualified seal. There's no simplified test seal, so plan to enroll twice with the same certificate.

What a QSeal Is, and How to Get One

"QSeal" is short for qualified electronic seal, a type of digital seal defined by the EU's eIDAS Regulation. Think of it as a company's official stamp in digital form: a signature that belongs to the organization rather than to a person, issued by a provider the EU has checked and listed.

Where to get one. From a qualified trust service provider (QTSP) on an EU trusted list. Many countries have several. Look for "qualified certificate for electronic seal" in the provider's catalog.

What the provider will ask for. Proof that your company exists (a registry extract), proof that the person ordering is authorized to act for it, and an identity check of that person. Some providers do this by video, others in person.

Device or remote. A qualified seal lives either on a hardware device (a smart card or token) or with a remote signing service that holds the key for you. Both work for the Registry. Remote signing is easier if several people or systems need to sign.

Cost. Prices vary by provider and country, usually in the low hundreds of euros a year. It's a small line item. The time it takes is the bigger risk, so order it early.

What it's used for. For the Registry, only the enrollment declaration. Your day-to-day registrations use EU Login (for people) or a Service Account key (for systems), not the seal.

Step 2: Make Every Battery's Passport Reachable

What you register for each battery is its unique product identifier (UPI). The API guide says the UPI "shall be in a URL format" and that the Registry "uses the UPI exactly as submitted as the initial URL of the DPP resource." In plain terms: the identifier is a web address, and the Registry will visit it.

Use one address per battery. Battery passports are item level: every battery has its own passport, and its own address. The cleanest way to build that address is a GS1 Digital Link, which combines the product's GTIN and the battery's serial number: https://your-domain.com/01/{GTIN}/21/{serial}. The same address goes into the QR code on the battery, so the person scanning and the Registry reading land on the same passport. Our free GS1 Digital Link generator shows how these links are built, and the GTIN check digit calculator catches bad GTINs before they're printed.

Answer people and machines differently. A phone that scans the code should see a readable passport page. The Registry asking for data should get the passport in the Registry's format. The self-hosting guide names JSON as the baseline format, so a request that asks for JSON should get JSON, while a browser gets the page. The GS1 resolver standard already works this way, and the Registry follows redirects while it resolves the address.

Keep the address stable for the battery's whole life. The Registry treats the address as the passport's permanent home. Use a domain you control, don't put a campaign tracker or a version number in it, and make sure it will still answer in ten years. If you might change platforms, a domain of your own matters more than the platform you pick.

It must be live before you register. Because the Registry reads the passport during registration, publish first and register second. A battery whose address returns an error, a login page or an empty page is rejected.

Step 3: Get the Passport Content Right

This is where the October 30 files change the most. Until now, "what goes in a battery passport" was answered by the regulation's annexes and the industry's BatteryPass model. Now the Registry has published its own model, and that's the one it validates against.

The layers

The Registry's model is built in three layers, each with its own version number:

1. Core: what every Digital Product Passport has, whatever the product. The passport's identifier, the product's identifier, granularity, status, when it was last updated, and which specifications it follows.
2. Batteries: what every battery passport has. Manufacturer, battery category, chemistry, weight, voltages, hazardous substances, critical raw materials, recycled and renewable content, the EU declaration of conformity, waste information and more.
3. Sub-group: what's specific to EV, industrial or LMT batteries. For LMT packs, for example, the expected lifetime in cycles, the cycle-life test, round-trip efficiency and the charge rate used in testing.

Every piece is versioned (the battery files published on October 30 are version 1.0.0), and the version is part of the specification address your passport declares. When the Commission changes a rule, the version tells you whether it breaks existing passports (a major change) or only adds something optional (a minor one).

The four access levels

The Battery Regulation says some passport data is public and some is only for people with a reason to see it. The Registry's model turns that into four separate views:

Restricted 3 is the one brands most often underestimate. These values change over the battery's life, usually reported by its battery management system, so they need a way to be updated per battery, not typed in once per model.

Where passports fail validation

When we ran battery passports built on the industry's BatteryPass model through the Registry's files, they failed all four access levels on the first try. Not because the data was wrong, but because the Registry expects it in its own shape. These are the differences that matter, and the ones to check in your own passports:

• Units come from a fixed list. Kilograms, grams, volts, watts, ampere-hours, ohms, percent, degrees Celsius, hours and a handful more, each written the Registry's way. A free-text "kg" or "A/Ah" fails.
• Many values come from fixed lists too. Battery category, chemistry (lithium-ion NMC, LFP and so on), battery status (original, repurposed, reused, remanufactured, waste) and the 34 critical raw materials all have to use the Registry's own terms. A material typed as "Natural graphite" or a status written as "re-used" fails.
• Country of manufacture is a three-letter ISO code. "DEU", not "Germany" or "Made in Germany". The city or region goes in a separate field.
• The manufacturing date is a month. Year and month (2026-10), as the regulation asks, not a full date.
• Texts carry their language. Free texts such as the extinguishing agent, the cycle-life test description or the waste information are written with a language tag, so the same field can hold several languages.
• Waste information is ten separate texts. The role of end users in preventing waste and in separate collection, where to hand batteries in, take-back points, facilities for reuse, repurposing and treatment, safety instructions for waste batteries, what the label symbols mean, and how the battery's substances affect the environment and health. A single link to a recycling page doesn't fill them.
• A model identifier needs a batch number. If you send a model identifier, the batch number becomes required too. Plan batch numbers per battery, not only per product.
• Voltages come with a temperature range. Minimum, nominal and maximum voltage each carry the temperature range they apply to.
• Decimals matter. Some industry tools store internal resistance as a whole number of ohms. An e-bike cell measures in hundredths of an ohm, so a whole number can't hold the real value.
• Contact details are links. The manufacturer's email is a mailto: address, and the website a full URL.

None of this is hard once you know it. All of it causes rejections if you don't, and remember that a single non-compliant battery in a batch fails the whole batch.

How to check before you submit

The Commission published the validation files themselves, including examples of passports that pass. Anyone can run a passport through them. Do it on a real battery from each of your sub-groups, at each access level, before you go anywhere near the Registry. A good passport platform runs this check for you every time data changes, so problems show up while you're editing, not as a rejected submission.

Step 4: Protect the Restricted Data

Three of the four views aren't public, but the Registry still needs to read all four to validate your passport. The self-hosting guide explains how that works, and it's worth understanding even if your provider handles it.

The first visit is anonymous. The Registry opens your passport's address without signing in, exactly as a person scanning would. Your server answers with the public view.

The second visit carries a token. The Registry then comes back to the same address with a short-lived access token issued by the Commission's authentication service. The token says who the Registry is acting for: a verified organization, by its organization identifier. If that matches the passport's owner, your server answers with the public and restricted views together.

Your server decides. The rules are strict and sensible. A request without a token gets the public view. A request with a broken, expired or forged token is refused, never quietly downgraded to the public view. A valid token for the wrong organization is refused without saying whose passport it is. Restricted answers are never cached by shared caches.

Shared hosting is allowed. The guide includes the case of a provider hosting passports for several economic operators on one domain. The provider checks each token against the owner of the specific passport requested, so one brand's token never unlocks another brand's batteries. This is how most brands will actually host: through a passport platform, not their own servers.

What this means for you: when you enroll, note your verified organization identifier from the Registry. Whoever hosts your passports needs it to recognize the Registry's requests on your behalf.

Step 5: Choose How to Submit

There are three ways to register, and you can mix them.

The web interface. A person signs in with EU Login and registers passports through forms. It's fine for testing and for a handful of batteries.

File upload. The web interface also accepts a file of up to 100 passports at a time, using the template the Registry provides.

The API. A system registers passports automatically, in batches, and follows each result. For item-level battery passports, where every battery produced needs its own registration, this is the only option that scales. It's also the only one that can register batteries as they come off the line, rather than in a monthly cleanup.

Service Accounts: how automated systems sign in

A Service Account is a non-human sign-in "bound to a verified Economic Operator," in the guide's words. The setup:

1. A brand administrator creates the Service Account in the Registry. An organization can have up to five.
2. The system that will submit generates a key pair. The private key stays with that system; only the public key is uploaded to the Registry. The Registry accepts EC keys on the P-256, P-384 and P-521 curves, and rejects anything that contains private key material.
3. The administrator registers the public key as a credential and gives the account the "Register DPPs" role. Credentials are valid for one year by default, up to two years, and each account can have two active credentials at once so keys can be swapped without downtime.
4. The system signs in with its key, gets a short-lived access token, and calls the API.

Two details make this work well with a service provider. The private key never has to leave the system that uses it, and the brand can revoke a credential in the Registry at any time. So a brand can let its passport platform submit on its behalf, while keeping control of who can do it.

Step 6: Submit and Read the Result

Registration is a two-part conversation: you submit, then you check what happened.

One submission, one sub-group, up to 100 batteries. Each submission names the product group and sub-group once, then lists between 1 and 100 batteries, each with its address, granularity and, where you have them, batch and model identifiers. EV, industrial and LMT batteries go in separate submissions.

All or nothing. The API guide is direct about it: "if any submitted item is non-compliant, none of the items in that submission are registered." Batching 100 batteries saves requests, but one bad passport holds back 99 good ones. Validate before you send, and when a batch fails, fix the culprit and resubmit.

Accepted isn't registered. The Registry answers a submission straight away with "accepted for processing" and a task number. That only means the request arrived in good shape. The real answer comes later.

Follow the task. The task moves from pending to processing to completed (or to error, if processing itself broke down). A completed task carries the business result: succeeded, or failed. It also reports how many batteries were submitted, compliant and non-compliant, and per battery, what went wrong. The guide recommends checking at growing intervals (after 1, 1, 2, 3, 5, 8 seconds and so on, capped at a minute) rather than hammering the server.

Retries don't create duplicates. Every submission carries an idempotency key, a label that identifies one logical submission. If the connection drops and you send the same submission again with the same key, the Registry returns the original task instead of registering twice. A new or corrected submission gets a new key.

Keep the evidence. Store each task number, its result and the registry identifiers returned per battery. If an authority asks when a battery was registered, or a customer asks why a passport is missing, you'll want the answer in one place.

Step 7: Keep It Registered

Registration isn't a one-time event, because a battery's life isn't.

Data changes over time. Restricted 3 values change as the battery ages. Status changes when a battery is repurposed, remanufactured or becomes waste. The passport at the address you registered is what everyone reads, so keep it current. Whether a change also needs a new registration depends on what changed: a new passport (for a repurposed battery, say) does, a routine update of state of health doesn't.

Specifications move. The data model is versioned. Watch for new versions, especially major ones, and plan how your passports move to them.

Keys expire. Service Account credentials last one to two years. Put the expiry date in a calendar, add the second credential before the first runs out, and switch over without a gap.

Passports outlive products. A battery passport has to stay available for the battery's life, which can run well beyond the years you sell the model. If you change platforms, your addresses, and therefore your registrations, need to keep working. Ask any provider how you'd leave before you sign.

The Timeline So Far

Other product groups follow as their rules are adopted under ESPR, each with its own product group in the same Registry. Batteries go first because the Battery Regulation set the date years ago.

Five Mistakes That Will Cost You Weeks

1. Waiting to order the seal. Nothing can be registered without a verified organization, and verification needs a qualified seal. It's cheap and the identity checks take time. Order it now.

2. Treating the BatteryPass model as the finish line. It's an excellent starting point, and most of the data carries over. But the Registry validates against its own model, and the differences (units, fixed lists, country codes, ten waste texts, batch numbers) are exactly what makes a first attempt fail. Convert and check against the Registry's files.

3. One bad battery in every batch. Because submissions are all-or-nothing, a single missing value fails 100 batteries. Validate each passport before it joins a batch, and keep batches homogeneous.

4. Forgetting Restricted 3. The per-battery values (status, capacity fade, resistance, remaining cycles) need a source, usually the battery management system or end-of-line testing, and a way to update them. Decide where they come from before February.

5. Addresses you can't keep. A registration points at an address. If that address lives on a vendor's domain, or contains anything that might change, you've tied your compliance to it for the life of every battery. Use your own domain where you can.

What About Textiles, Electronics and Everything Else?

The DPP Registry isn't a battery system. It's the Registry for every Digital Product Passport the EU will require: textiles, iron and steel, electronics, furniture and more, as each product group's rules are adopted. Batteries are simply first.

Everything in this guide carries over. The enrollment and seal are per company, not per product, so a brand that enrolls for batteries is ready for the rest. The core layer of the data model is shared by every product group. The access-level approach, the address-per-passport principle and the submission process are the same. A brand that gets batteries right in 2027 has done most of the work for whatever comes next.

If you sell other products alongside batteries, now is a good time to give them the same foundation: clean identifiers, a QR code that opens a useful product page, and product data that lives in one place. The free DPP readiness checker shows where each product category stands, and the ESPR DPP requirements checklist tracks which rules apply now.

Build It or Use a Platform

Everything above is buildable. The specifications are public, and a capable engineering team can implement them. The question is whether it's the best use of that team in the months before a hard deadline, and in the years of upkeep that follow.

Doing it yourself means owning all of it: conversion to the Registry's data model and its versions, validation, four access levels, token checks on every restricted request, batched submissions and their results, key rotation, and hosting that stays online for decades. Using a passport platform means enrolling your company, giving the platform what it needs, and spending your time on the data only you have.

This is how we built Veribl. Battery passports are created per battery in the BatteryPass data model and published in the Registry's own format at the battery's QR code address, split into the four access levels. The EU registry check runs on every product and every battery as you edit, in plain words, so a missing waste text shows up long before a submission does. Restricted data goes only to the Registry's signed requests for your own organization, and to the repairers and recyclers you give access. When your organization is verified, you connect your Registry account once and submit your batteries from the same place, then see each battery's result.

We test this publicly. A live e-bike battery passport hosted on Veribl conforms to the Registry's batteries model at all four access levels, validated against the Commission's own files, alongside our results for BatteryPass-Ready, UN Transparency Protocol, Asset Administration Shell and GS1 Digital Link. The details, and the steps to re-run each test yourself, are in our DPP Trust Center.

A 100-Day Plan to February 18, 2027

Days 1 to 15: start the slow things.

• Name the economic operator for each battery you place on the market, and the person who owns the process.
• Order the qualified electronic seal.
• Create EU Login accounts for the people who'll use the Registry, in both environments.
• List every battery model by sub-group: EV, industrial, LMT.

Days 16 to 45: get the data in shape.

• Decide the address format for each battery and check your GTINs and serial numbers.
• Request missing data from cell and pack suppliers: composition, test results, carbon footprint, and the values for each access level.
• Write the ten waste information texts once; they rarely change between models.
• Decide where the per-battery Restricted 3 values will come from.

Days 46 to 75: publish and check.

• Enroll in the acceptance environment as soon as the seal arrives.
• Publish passports for a few real batteries from each sub-group.
• Check every one against the Registry's files at all four access levels, and fix what fails.
• Scan the QR codes with ordinary phones and make sure people get a readable page.

Days 76 to 100: register.

• Set up a Service Account and connect your passport system.
• Submit small batches in the acceptance environment, read the results, fix, resubmit.
• Enroll in production and register your first live batteries.
• Write down the routine: who registers new batteries, how often, and what happens when one fails.

The Short Version

The DPP Registry stopped being a moving target on October 30, 2026. The rules for batteries are public, the API is documented, and the validation files are there for anyone to run. What's left is the work: a seal, an enrollment, a passport per battery in the Registry's format, protected restricted data, and a reliable way to submit.

None of it is exotic. Most of it takes longer than it looks. Start with the seal this week, check one real battery against the Registry's files this month, and you'll meet February 18 with time to spare.

This article is for general informational purposes and does not constitute legal advice. It reflects the Commission's documents as published on October 30, 2026; check the official DPP resources page for later versions and consult qualified counsel for your products.