At the 4th ZVEI Forum DPP4.0 in Frankfurt on 29 January 2026, a nice idea was presented: Digital Nameplate plus Asset Administration Shell (AAS) should “automatically fulfil” the Digital Product Passport (DPP). That is good news, because it means a large part of the work is already done. If you maintain a Digital Nameplate submodel, you have already structured manufacturer and product designation, serial number, production date, article number, base technical data, certifications, and declarations of conformity - exactly what a DPP needs in the end. That is genuine, valuable work, and most of the industry has not done it yet. If you are already there: congratulations, you are halfway.
“Automatically” is a bit optimistic, not dishonest. Structured submodel data is the necessary foundation for a DPP. Turning it into a published passport a regulator accepts and a consumer can scan takes a few more steps. The good news: there are exactly six of them, they are manageable, 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 an AAS submodel does not cover on its own.
The six steps
-
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 GS1 Digital Link. Approved is not the same as printed: the code has to be on the physical product.
-
Add a verifiable signature. A cryptographic signature lets an authority or an auditor verify the passport independently, instead of taking your word for it (EN 18246). It does not come automatically from the submodel, 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). AAS leaves this to the surrounding system - someone has to define the tiers once.
-
Register with the EU registry. Once the mandate applies to your product, register the passport with the EU. A one-off, external step.
-
Make it readable for people. AAS speaks machine to machine. Someone scanning the QR code wants a passport to read, not a data dump. A renderer 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
Steps 2 through 6 are exactly what Transpareo handles for you, without anything being maintained twice. Your AAS submodel stays as it is, the data flows across once, and Transpareo turns it into the finished, signed, register-ready passport. Concretely, Transpareo signs every version, renders it via the open-source (GPLv3) Transpareo Time Machine, and keeps it tamper-evident for ten years. For how that open semantics comes together, see our post on EN 18223, and for how AAS and the DPP fit together more broadly, see our first AAS post.
The good news to finish on
Structure your data once, cleanly, in your AAS, and a good output-layer partner 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.