The maintenance manager at a machine builder keeps a digital nameplate for every machine: manufacturer, type, serial number, year of build, technical data, certificates, declaration of conformity. Not as a PDF in a folder, but as a structured record any system can read. He set it up for maintenance. Without meaning to, he has already written half a Digital Product Passport.
What is still missing is manageable: a code that sits on the product, a seal an inspector can check without asking, and a public address where every scanner finds the passport. This article shows what the nameplate and the structure behind it already deliver, what they do not produce, and how the two become a passport without anyone maintaining data twice.
What the Administration Shell is
The structure behind the digital nameplate is called the Asset Administration Shell, AAS for short. It is the industrial standard for a product’s digital twin: a standardised, machine-readable description, organised into building blocks, each describing one aspect, the nameplate, the carbon footprint, the technical data. It was developed by the Industrial Digital Twin Association, it is standardised internationally as IEC 63278, and the large German industry associations back it.
This is not a critique of the AAS. It does something genuinely hard well, and this post is about how well it fits with something built beside it.
Same idea, different output
The AAS and the EU Digital Product Passport chase the same idea: structure product data, make it machine-readable, pass it along the supply chain. They arrive at that idea from different directions, and they produce different outputs.
The interesting part is how close the two actually sit.
The European Commission has not treated the AAS as a rival. It references its building blocks as a technical foundation for DPP data structures, notably the digital nameplate and the carbon footprint. That is a strong signal about where the convergence is heading.
The digital nameplate is already half a passport
Look at what the digital nameplate already carries: manufacturer and product designation, serial number, production date, article number, base technical data, certifications, and declarations of conformity. That list is close to the minimum a product passport has to expose. A manufacturer who has maintained a digital nameplate has, without setting out to, already done roughly half the work of a Digital Product Passport.
What the shell does not produce on its own
Here is the honest gap. The data in the shell is necessary for a passport. It is not sufficient. On its own, the AAS does not produce four things the EU regulation asks for in the end:
- an address every scanner finds: the GS1 Digital Link, the web standard that makes a scan land on the right passport;
- a seal anyone can check: a signature an authority or an auditor checks themselves, rather than taking your word for it;
- the QR code on the product that a consumer scans;
- the marking on the packaging that the PPWR packaging regulation will require.
These four are the published passport. They are the difference between well-structured industrial data and something a regulator, a recycler and a consumer can actually pick up and use.
Where Transpareo fits: as the published passport, not a second twin
Those four things are precisely what Transpareo adds, and the arrangement is complementary by design. The shell stays the single source. Its data flows into Transpareo over the interface, and from it comes the passport as the EU requires it: signed, at an address every scanner finds, reachable by QR and ready for the register. The version history is shown by the Transpareo Time Machine, a checking tool that verifies every version in the reader’s browser. It is released as open source under GPL v3, so the check does not depend on trusting Transpareo.
No second data-maintenance system. No second model to keep in sync. No double work.
Your nameplate stays where it lives; the passport is generated from it.
All of this is available today, without waiting for the mandate. When the DPP obligation arrives for your segment, the remaining step is the entry in the EU register.
The bridge is the opportunity
That AAS and DPP are converging is the part worth watching, and it is underway right now, with an EU that names the shell’s building blocks as the technical basis. The bridge from the nameplate in the shell to a published, signed, QR-linked passport is an opening for the AAS community, not a competing system trying to replace it. Why the published passport builds on open dictionaries in the first place is explained in our post on EN 18223.
So a genuine question to the people running an AAS in production: how does your shell connect, or how do you plan to connect it, to your DPP obligations? Which building blocks do you expect to map cleanly, and where do you see the seams? We would rather hear how you are thinking about it than assume.
Questions on this article
Does a digital nameplate satisfy the DPP on its own?
No, and the gap is narrow rather than deep. The nameplate carries manufacturer and product designation, serial number, production date, article number, base technical data, certifications and declarations of conformity, which is close to the minimum a passport has to expose. What it does not carry is the published passport, that is an address every scanner finds, a seal an authority can check without asking you, a QR code on the product and the packaging marking the PPWR will require. The data in the shell is necessary for a passport; it is not sufficient.
Do we have to maintain the data twice?
No. The shell stays the single source and its data flows into Transpareo over the interface. The passport is generated from it, so there is no second model to keep in sync and no second place where someone types a voltage. When a building block in the shell changes, the next passport version is generated from the changed data rather than re-entered.
Which building blocks of the shell map onto a passport most cleanly?
The digital nameplate maps almost one to one, and the Commission references this block, together with the carbon footprint block, as a technical foundation for DPP data structures. In AAS terms the passport header itself is a block of its own, the DppMetadata submodel (IDTA 02099), whose uniqueProductIdentifier is your shell’s globalAssetId. Beyond those, mapping is a question of which fields the rule for your product group asks for, and that varies by product group rather than by shell.
Do we need a GTIN for the identifier?
No. The ESPR asks for a unique product identifier and a data carrier on the product, its packaging or its accompanying documents (Art. 10 and Art. 12) and names no numbering scheme, and the Batteries Regulation points at the ISO/IEC 15459 series rather than a particular number (Art. 77(3)). With a GTIN the identifier in Transpareo becomes a GS1 Digital Link that other systems understand too; without one the passport carries a unique Transpareo identifier and the QR code leads to it just the same. The IEC 61406 ID link that AAS already uses is an approved identifier scheme as well (EN 18219).
Why does the passport need a seal when our shell already has access control?
Access control decides who may read a value. A signature decides whether a value can still be trusted after it has left your systems. A market surveillance officer, a recycler or a customer’s auditor reads the passport without any relationship to you, and the signature is what lets them check it themselves instead of taking your word for it. Every Transpareo version carries two independent signatures, from the issuer and from us, and the Transpareo Time Machine checks them on the reader’s own device; it is open source under GPL v3, so the check does not depend on trusting us. You can hold the issuer key yourself through your own signing service.
Can Transpareo register the passport in the EU register for us?
No, and no service provider can. The central EU DPP register has been operational since 20 July 2026 under Implementing Regulation (EU) 2026/1778, with a test environment and technical documentation, and the specification of its interface is still evolving. Only the economic operator that places the product on the market may make the entry, which for batteries is written into Art. 77(10) of the Batteries Regulation. What we do is prepare what the entry asks for, the product identifier, the operator identifier, the passport address and the fingerprint, so the entry itself stays a short act you perform yourself. Our reading of the register regulation is in the register is now law.
Which standards does the published passport have to meet?
The DPP system of CEN/CLC JTC 24 is a family of European Standards, and Implementing Decision (EU) 2026/1736 cites six of them in the Official Journal, EN 18216, EN 18219, EN 18220, EN 18221, EN 18222 and EN 18223. Whoever complies with a cited standard enjoys the presumption of conformity for the passport’s identifier, data carrier, storage and interfaces. That is precisely the part a building block of the shell leaves to the surrounding system, which is why the two fit together rather than compete.
