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.
Questions on this article
Does Transpareo need access to our ERP or any other system?
No. Every system that contributes data stands on the source side and stays there, 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. That leaves your security review with no credentials to hand over, no inbound opening to arrange and no third-party system with read rights in your ERP to assess.
Who triggers a delivery, and how often?
The source side does, always. The push is initiated by the manufacturer, their middleware or a contracted service provider; the platform waits and never fetches. Selection, scope and timing of every package are decided at source, which is also why Transpareo cannot receive more than was delivered. How often you push is your call - stable master data rarely changes, while production events arrive as they happen.
Do we need an Asset Administration Shell for this?
No. The Administration Shell does not stand beside ERP, MES and PIM but above them, and it creates no data of its own; it wraps existing data in interoperable submodels. That makes it 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, straight from the leading system or through an aggregation layer.
Which system should we start with?
Measured against what the Ecodesign Regulation asks for, the PLM is the densest single source - composition, bills of materials, repairability, spare parts and design revisions all sit there. The ERP adds article identity, materials, suppliers and origin, the PIM the consumer-facing texts and images, the MES the production and traceability events. Most passports need only a few fields from each system. Start where most of your mandatory fields already live and add the rest as you go.
Does customer data from the CRM end up in the passport?
No. The service and repair history of individual customers is personal data by nature, which is why it does not belong in a public passport. The CRM is the one system class in this list that stays out entirely. Repair and lifecycle events can still be represented, but as events on the product rather than on a named person.
What comes back from the platform?
Receipts, not data. The return channel carries the DPP address or GS1 Digital Link, the version ID, the publication status and validation messages. Those are worth storing, because the passport reference can then sit right on the article in your ERP or PIM. They are not access; they are the receipt for a delivery that arrived.
What happens when a value is corrected in the ERP?
The correction reaches the passport through a new delivery and becomes a new, traceable version, not a silent change to the existing one. Every earlier version stays retrievable and stays verifiable, which is what makes the history worth anything in an inspection. How that version chain is signed and made verifiable for anyone is covered in signatures and certificates in the DPP.
Does Transpareo become a second system of record?
No, and deliberately not. The platform holds the passport record and its immutable version history, not your operational data; your own systems stay authoritative for everything they own. That also keeps the project work where it belongs - deciding which fields go into the passport, rather than who gets to log in where.
