Your engineers have entered the nameplate data into the Administration Shell once: manufacturer and product designation, serial number, production date, article number, base technical data, certifications, declaration of conformity. Cleanly structured, readable by any system. That is genuine, valuable work, and most of the industry has not done it yet. If you are already there: congratulations, you are halfway.
The question is what still stands between that record and a passport a customs officer scans and an authority accepts. The industry likes to say that nameplate plus Administration Shell “automatically fulfil” the Digital Product Passport. That is a bit optimistic, not dishonest. The data is the necessary foundation. Turning it into a published passport takes a few more steps. The good news: there are exactly seven of them, they are manageable, only two of them stay with you, and each maps to a European Standard. Here is the checklist.
The standards at a glance
So you know what you are working towards: the CEN/CLC JTC 24 DPP system is a set of eight European Standards, including EN 18219 (identifiers), EN 18220 (data carriers), EN 18239 (access rights), EN 18223 (data model), EN 18221 (storage), and EN 18246 (authentication). You do not need to memorise them. The checklist below tells you which ones the nameplate in the shell does not cover on its own.
The seven steps
-
Mark the record as a passport. A DPP starts with a few header fields that say it is one: a passport ID, a status, the version of the data model, and the unique product identifier. These header fields are exactly what EN 18223 defines, and without them a register sees excellent product data, but no passport.
-
Print a data carrier and identifier. Your product needs a scannable QR code that actually leads to the passport. The IEC 61406 ID link AAS uses is approved for this (EN 18219), as is the GS1 Digital Link. Approved is not the same as printed: the code has to be on the physical product.
-
Add a verifiable signature. A signature lets an authority or an auditor check the passport themselves, instead of taking your word for it (EN 18246). It does not come automatically from the shell, but it only needs setting up once.
-
Tier the access rights. Consumers, authorised partners, and authorities are each allowed to see different amounts of data (EN 18239). The shell leaves this to the surrounding system. Someone has to define the tiers once.
-
Register with the EU register. Once the mandate applies to your product, register the passport with the EU. A one-off, external step.
-
Make it readable for people. The shell speaks machine to machine. Someone scanning the QR code wants a passport to read, not a heap of data. A display such as the Transpareo Time Machine takes care of exactly that.
-
Store it for the long term. The passport should outlive the sale by years (EN 18221). Once set up, retention just keeps running.
Where Transpareo takes the work off your hands
Two steps stay with you: step 2, because the code has to reach the physical product, and step 5, because the register entry is the economic operator’s own act by law. The other five are what Transpareo handles for you, without anything being maintained twice. Your nameplate in the shell stays as it is, and the data comes across through Transpareo’s application programming interface (API). Transpareo does not read the AAS directly, so you decide once which building block goes into which passport field. Transpareo turns the data into the finished, signed, register-ready passport. Concretely, Transpareo produces the header fields, signs every version, displays it via the open-source (GPLv3) Transpareo Time Machine, and keeps it unchanged for ten years. Why the passport builds on open dictionaries in doing so is explained in our post on EN 18223, and how AAS and the DPP fit together more broadly in our first AAS post.
The good news to finish on
Structure your data once, cleanly, in the shell, and a good provider turns the rest into routine rather than manual work.
That is the real value of “automatic”: not that nothing is left to do, but that what is left becomes easy.
Questions on this article
Does a Digital Nameplate plus AAS really fulfil the DPP automatically?
Not automatically, but the hard part is done. A maintained digital nameplate gives you manufacturer and product designation, serial number, production date, article number, base technical data, certifications and declarations of conformity, which is the substance a passport publishes. What is missing is the publication itself, and the checklist above names it as seven steps. In AAS terms the passport’s header fields have a building block of their own, by the way, the DppMetadata submodel (IDTA 02099), whose uniqueProductIdentifier is your shell’s globalAssetId. Calling that automatic is optimistic rather than dishonest.
Do we have to comply with all of the standards?
Not with all of them, and compliance with a standard is never the only route. Implementing Decision (EU) 2026/1736 cites six of the CEN/CLC standards in the Official Journal - EN 18216, EN 18219, EN 18220, EN 18221, EN 18222 and EN 18223 - and whoever complies with a cited standard enjoys the presumption of conformity for the passport’s identifier, data carrier, storage and interfaces. You may meet the requirement another way, and then the burden of showing that you did is yours.
Step five is the register entry. Can Transpareo make it for us?
No, and that is a rule rather than a gap in the product. The EU DPP register has been operational since 20 July 2026 under Implementing Regulation (EU) 2026/1778. According to the register’s user guide no passport can yet be registered there successfully, and the technical specification of its programming interface is still pending. Only the economic operator placing the product on the market may register it; for batteries Art. 77(10) of the Batteries Regulation says so in as many words. Transpareo prepares what the entry asks for, the product identifier, the operator identifier, the passport address and the fingerprint, and you make the entry once the interface is settled. More in the register is now law.
Which of the seven steps stay with us?
Two of them. Printing the data carrier is physical work no software does for you, because the code has to reach the product, its packaging or its accompanying documents. And the register entry is yours by law. The other five, the header fields, the signature, the access tiers, the readable display and the long-term retention, are what Transpareo produces from data you already maintain in the shell.
May we keep the IEC 61406 ID link, or do we need a GS1 Digital Link?
Both are approved. EN 18219 admits the IEC 61406 ID link that AAS already uses as well as the GS1 Digital Link, so a plant that already marks with IEC 61406 keeps its marking. The practical difference is reach, because a GS1 Digital Link also resolves in systems that already speak GS1, which matters more in retail than in machinery. Where there is no GTIN at all, the passport carries a unique Transpareo identifier and the QR code leads to it just the same.
Who verifies the signature, and what happens when we correct a value later?
Anyone who reads the passport verifies it. Every version carries two independent signatures, from the issuer and from Transpareo, and the Transpareo Time Machine checks them in the reader’s browser rather than on our servers; it is published as open source under GPL v3, so a verifier does not have to trust us. A later correction never overwrites the old version. It becomes a new signed version on top, and the earlier states stay retrievable, which is the whole point of signing - a quiet edit is not possible.
How long does the passport have to stay available?
Longer than most supplier contracts. EN 18221 covers the storage side, and the period comes from the rule for your product group - a battery passport exists until the battery has been recycled (Art. 77(8) of the Batteries Regulation), and the ESPR requires the information to remain available even after insolvency, liquidation or the operator ceasing activity in the Union (Art. 11). Once your passports are registered with the EU register, every version is written to a separate write-protected archive for ten years that neither you nor we can change afterwards. Ask every provider what happens after a cancellation; our provider checklist names the other questions worth asking.
Can we do any of this before the mandate reaches our product group?
All of it except the register entry. The passport, the identifier, the QR code, the signature, the access tiers and the rendering do not wait for a delegated act; only the entry is tied to the mandate for your product group, and when that arrives is in the industries reference. Building the passport while the data requirements are still moving means that when the act names its fields, you map them onto data you already hold instead of starting a project.
