The moment a Digital Product Passport becomes concrete, the IT department asks one question before all others: which of our systems does the platform need to touch? It is the right question, because behind it sit credentials, firewall exceptions and a security concept someone has to sign off.
Our answer is short: none of them. Every system that contributes data to the passport stands on the source side and stays there. Transpareo is purely the recipient at the end of the chain; the data streams run one way, towards the platform. This article traces those streams: what each system delivers, which rules apply to every stream, and what comes back as a receipt.
What each system contributes to the passport
The data in a passport rarely comes from one system. In practice it is spread across a handful of system classes, each contributing only a few fields:
- ERP - article identity, materials, suppliers and origin, order and batch references, quantities. Stable master data that rarely changes.
- MES - production history, serial and batch assignment, quality evidence, traceability. Event data, tied to a point in time.
- APS - production schedules and resource assignment. Rarely relevant to the passport directly; what matters usually arrives via the MES.
- PLM - composition, bills of materials, repairability, spare parts, design revisions. Measured against what the Ecodesign Regulation asks for, the densest source.
- PIM - descriptions, images, care and usage instructions, language variants. The consumer-facing content.
- IoT - condition and usage data from the use phase. Only called for in certain product groups, batteries for instance.
- CRM - the service and repair history of individual customers. Personal data by nature, which is why it does not belong in a public passport.
The Administration Shell sits above the systems, not beside them
One distinction matters more than all the others: the Asset Administration Shell does not stand beside ERP, MES and PIM but above them. It creates no data; it wraps existing data in interoperable submodels. For a connection to Transpareo that means an AAS is a convenient delivery format, not a necessary one. If you run one, the data package is derived from its submodels; if you do not, the same fields arrive by another route. Why we still consider the Administration Shell an excellent foundation is covered in our article on the AAS.
Five rules that hold for every stream
Direction. Every arrow points to the platform. No source system is ever queried by Transpareo, and Transpareo holds no credentials for ERP, MES, PIM or PLM. There is no connection into your systems that would need securing, because there is no connection at all.
Trigger. The push is always initiated on the source side - by the manufacturer, their middleware or a contracted service provider. The platform waits; it does not fetch.
Purpose limitation. What is transmitted is exactly the subset the passport requires, not the source system’s data set. The passport needs only a few fields from each system; everything else stays where it is.
Release. Selection, scope and timing of every package are decided on the source side. Transpareo cannot receive more than was delivered.
Permissions. What may happen to delivered data on the platform is governed by named access credentials: least privilege, and whatever is not expressly allowed stays forbidden. These rules act on the platform side only, never back on the source.
Only receipts flow back
There is no doing entirely without a return channel, but it carries no data, only answers: the DPP URL or GS1 Digital Link, the version ID, the publication status and validation messages. For the source side these responses are valuable, because the passport reference can be stored right on the article in the ERP or PIM. They are not access. They are the receipt for a delivery that arrived.
Three patterns that hold up in practice
- Straight from the leading system. The ERP or PLM pushes through a connector. Simple, and sensible where one data source clearly dominates.
- Through an aggregation layer. Middleware or an iPaaS merges ERP, MES and PIM fields and delivers one package. The standard case as soon as several sources are involved.
- Through AAS submodels. The Administration Shell is already in place, and the package is derived from its submodels. Advantageous in Industry 4.0 environments.
Which pattern suits which system landscape, and how such a project runs in two weeks rather than three months, is written up in our ERP integration playbook.
What Transpareo deliberately is not
A second system of record. The platform holds the passport record and its immutable version history, not the manufacturer’s operational data. Whatever gets corrected in the ERP reaches the passport through a new delivery - as a new, traceable version, not a silent change to the stock. How that version chain is signed and made verifiable for anyone is covered in our article on signatures and certificates.
That leaves your security review with very little to examine, and that is precisely the intent. There are no credentials for you to hand over, no inbound firewall opening, no third-party system with read rights in your ERP. The real project work shifts to where it belongs: deciding which fields go into the passport - not who gets to log in where.