How to Enrol and Register in the EU DPP Registry: A Step-by-Step Guide for Economic Operators

Our earlier guide covered what the DPP Registry Implementing Regulation requires — the legal framework, the responsibilities, the retention rules. This article covers the other half: the actual mechanics. What screens you will see, what fields you must fill in, what the Commission checks when it validates your identity, and every error the system can throw back at you.

For battery manufacturers and importers working toward the February 2027 mandate, the work splits cleanly in two. Identity is yours. Enrolling your organisation and obtaining qualified electronic credentials is a legal act that only your legal representative can perform — no platform can do it for you. Registration is machinery. Generating conformant identifiers, hosting resolvable passport data, computing version hashes, submitting to the registry API and tracking the identifiers that come back is exactly the kind of work software should absorb — and in PassportIQ, it does.

The Four-Stage Operator Journey

The registry models onboarding as a linear journey. You cannot skip stages, and each one gates the next.

Stage 1: EU Login

Navigating to the registry redirects you straight to the EU Login sign-in page. EU Login is the Commission's single sign-on service across EU institutions, with multifactor authentication built in. If you already have an account — from EPREL, or any other Commission system — you can use it.

One practical note: you may want to create a new EU Login account tied to a role-based corporate address rather than an individual's personal work email. The account becomes the root of your organisation's registry administration, and personnel changes are easier to survive when the identity is not attached to one employee's mailbox.

Stage 2: Enrolling Your Organisation

After first login you land on a Welcome page with a single action: Enrol New Organisation. The first decision is your legal nature, and it is consequential — switching type after entering data wipes the form and gives you a fresh one.

Organisation information fields

Both entity types share the same address block. Character limits are enforced in the form, with a live counter on each field.

Choosing your identifier type

The identifier is what binds your registry presence to a real, checkable legal identity. The permitted types differ by entity type, and the Commission states a preference in each case.

Stage 3: The Seven-Step Verification Process

This is the heart of the process and the part that takes real calendar time. The mechanism is a round-trip document exchange: the Commission generates and seals a PDF declaration containing your data, your legal representative countersigns it offline with qualified credentials, and you upload it back for automated validation.

QES and QSeal: what you actually need to buy

The registry does not issue credentials. You must obtain them from a Qualified Trust Service Provider — an accredited organisation authorised to issue qualified certificates under the eIDAS Regulation (Regulation (EU) No 910/2014). A QTSP accredited in any Member State is recognised in all of them, and the EU maintains a public Trusted List Browser of qualified providers.

Whichever you use, the resulting file must conform to a PAdES Baseline signature profile — B, T, LT, or LTA level. This is not a detail you can leave to chance: signing with a generic PDF tool that does not embed a trusted timestamp or long-term validation data produces a file the registry will reject.

What the registry validates

The submitted document must contain exactly two signatures: the Commission's institutional seal and your organisation's countersignature or counterseal. The validation checks integrity, validity, and authenticity of the file, the signature or seal, their associated certificates, and the information they contain.

The rejection catalogue

The guide documents the full set of verification errors. They fall into four families, and knowing them in advance is the difference between a one-week and a one-month onboarding.

When a request fails, the registry offers three routes forward: Upload PDF Declaration (you have a corrected file ready), Restart Verification (the legal representative's details need changing), or Organisation Information (the underlying company data was wrong). Error reports can be exported as CSV.

Stage 4: Registering a DPP

Before walking through the mechanics, one conceptual point the guide is emphatic about — and that reshapes how you should think about your architecture.

Granularity: item level only

The registry supports three levels of registration — Model, Batch, and Item. For batteries, only item level is available, and it is pre-selected as the agreed level for the product group.

Item-level granularity is the operationally demanding choice: every single battery placed on the market needs its own registration record. For any manufacturer shipping at volume, this makes automated, API-driven registration a practical necessity rather than a convenience.

The two submission methods

The Unique Product Identifier

The UPI is the mandatory field, and its constraints matter more than their brevity suggests. It must be a URL conforming to JTC 24 standards, maximum 50 characters, and it must resolve to where you host the DPP data. Registration attempts against a URL the registry cannot fetch fail with NOT_RESOLVABLE_UPI.

The practical consequence: your passport hosting must be live, public, and stable before you register. You cannot register first and stand up hosting later.

On success, the registry issues a Unique Registration Identifier (URI) — the identifier of the central record, which binds back to your DPP data through the UPI. Every request also receives a correlation ID for tracking in the Activity Dashboard.

Submission and validation errors

That last one is a quiet warning about hosting design. If your passport URL chains through redirects, downgrades from HTTPS at any hop, or returns a very large payload, the registry may simply refuse it.

How PassportIQ Automates Registration

Every constraint in the preceding sections is a requirement PassportIQ's registry integration already satisfies. Rather than presenting you with the registry's online form, the platform constructs and submits the registration record itself.

What gets submitted

When a battery unit is created, PassportIQ assembles the registration payload from data already in the passport — no separate data entry:

Why the hash matters

The registry expects a hash of the registered passport version. PassportIQ computes this over the substantive, data-backed fields — identifiers, chemistry, capacity, carbon footprint, recycled content, due diligence URL, hazardous substances — using a canonical JSON serialisation so the result is stable and reproducible.

Crucially, dynamic telemetry is excluded. State of charge, capacity fade and power fade stream continuously from the BMS and are not part of the registered record; including them would change the hash on every reading and generate constant, meaningless re-registrations. The timestamp of last update is excluded for the same reason. The hash therefore changes only when something substantive about the battery changes — which is exactly when the registry should hear from you.

Registration and update lifecycle

• On creation — the passport is submitted to the registry, and the returned registration identifier, timestamp and hash are persisted against the unit
• On substantive change — the record is updated in place; the registration identifier is stable across updates, so the central record is never orphaned
• On failure — submission is non-fatal and retried, so a transient registry outage never blocks passport creation or breaks a QR code

The Test Environment

The Commission runs a sandbox at registry.acc.product-passport.ec.europa.eu, distinguishable by a "MOCK" logo in the header (production identifies itself as such in the footer). Several constraints are worth knowing before you plan a pilot:

• You need a different EU Login account from your production one
• Nothing created in test migrates to production, and objects may be deleted by a data cleaning routine
• The verification process is identical to production — you must verify with valid organisation data and real signatures or seals

That last point is the important one. The sandbox will not accept a fake seal, so it does not let you rehearse verification for free. It is useful for learning the registration flow, not for shortcutting the QTSP procurement you need anyway.

What This Means If You Ship Batteries

Reading the operational guide against the February 2027 mandate, four conclusions follow.

Verification is the one thing only you can do. Obtaining a QSeal or QES from a QTSP, aligning your certificate contents with your enrolment data, and having your legal representative countersign is a legal act bound to your organisation's identity. No platform can perform it for you, it depends on an external provider's timelines rather than your own, and it may take more than one attempt. It is the single item genuinely on your critical path — start it now.

Your hosting is a compliance dependency, not an implementation detail. The UPI must resolve, permanently. The response must be well-behaved — no redirect chains, no protocol downgrades, no oversized payloads. If your passport URLs break, registrations fail and existing central records point at nothing. This is the strongest argument against hosting passport data on general-purpose infrastructure that was never designed to guarantee a decade of stable resolution.

Item-level registration at volume is an automation problem. One record per battery, 100 per batch file, all-or-nothing rejection semantics. Manual submission through the registry's online form is viable for a pilot and nothing beyond it.

Validate before you submit. Because a single bad record fails an entire batch, schema validation and UPI resolvability checks pay for themselves immediately. This is precisely what conformance testing is for — see our guide to BatteryPass-Ready conformance testing for how to find those gaps before the registry does.

Key Dates

Getting Help

The registry's Help Center links user documentation, the DPP FAQ, and the test environment. For platform or technical issues, the Commission operates a helpdesk Monday to Friday, 08:00–20:00 CET, at EC-HELPDESK-DPP@ec.europa.eu or +32 22960431.

The Bottom Line

The DPP Registry has moved from regulation to running software, and the operating manual is now public. What it reveals is a system where the compliance burden is front-loaded onto identity, not data: you must prove who you are, with qualified cryptographic credentials, before the registry will accept a single passport.

For battery manufacturers and importers, that makes the priority unusually clear. Get your organisation verified — it is the only part of this process that cannot be automated, and it moves on a third party's timeline rather than yours. Everything downstream of it, from conformant identifiers to permanently resolvable hosting to registry submission and versioned updates, is engineering that already exists and runs on your behalf. With eighteen months to the mandate, the operators who move on verification now are the ones who will have nothing left to build when it arrives.